I am using DT 3.5.2 on a MacBook Pro running macOS 10.15.6 (with the latest supplemental OS update). PDF invoices are imported into DT, converted to PDF + text and when I have paid the invoice I use the imprinter to print “Paid” plus the current date on the first page of the invoice. Recently that has failed to work with some (but not all) imported invoices.
There is no entry in the log after a failure and I cannot see, on the face of it, any key difference between invoices on which the imprinter works and those on which it simply refuses to do so.I reboot my machine daily and have also tried re-launching DT when the imrpinter fails, to no avail.
I can add only that it worked for an invoice paid on 14 August but failed on invoices paid on 5 August and today (19 August).
Any ideas for tracking down the source of the problem would be much appreciated.
Stephen, no key difference presumably means that the invoices are optically similar? I was just wondering whether there was any possibility the imprint was being placed under an image. What is the source of the invoices (scanner, provided as pdf by 3rd party, etc.)?
Have you tried opening a document with an (apparently) failed imprint with a different viewer (e.g. preview) to check that the imprint isn’t being displayed there, either?
I’ve just tested imprinting a pdf in locked state, but that is possible; I noted, however, that imprinting changed the modification date - has the modification date on the documents which (apparently) failed to imprint been changed?
All invoices are dowmloaded pdfs—nothing is scanned by me. I simply import into DT and the result is a pdf + text “kind”.
I have tried - since your idea - checking by opening with both Preview and PDF Expert (my default pdf viewer) and neither show the imprint.
The thought about the changed modification date is very clever: thanks! The answer is “no” - the modification date on the failed imprinter files does not change…however often I attempt to apply the imprinter. (Obviously the modification date on the file where there imprinter did work does have a changed modification date.)
Thanks again for your thoughts. At least they enable me to provide more useful information which may possibly be helpful in tracking down the problem.
DT doesn’t obviously respect PDF permissions (in fact in my experience only Acrobat does, which makes them pointless), but nonetheless it might be worth comparing the document properties (in PDF Expert File/Properties and in Preview Tools/Show Inspector) to see whether there is a discernible difference between those which you successfully imprinted and those which failed. Also, in DT, select “Show in Finder” from the context menu, and in Finder select “Get Info” from the context menu and see again whether there is any difference between those files which worked and those which failed (especially regarding the status “Locked” and “Sharing and Permissions”)
Somewhere in those sentences I should have had the words “you could try” or similar My son is standing next to me going “Daaaaaad”, so please add them yourself at your pleasure
Thanks so much: I think you may have solved the problem (and I’m kicking myself for not thinking of it!).
Unfortunately I have only the latest file still in finder and DT (because once I’ve imported into DT I almost invariably delete in Finder). However, when I checked the properties in Finder I discovered the wretched thing was read only. Changing that to “read and write” and re-importing into DT solved the problem (i.e., the imprinter worked on the new version).
Of course, this now means I’m going to have check the properties of every invoice before importing into DT <sigh>. It’s strange, I’ve never come across these read only invoices (from gas, electricity, water, etc. companies here in the UK) before: they’ve previously all been amenable to the imprinter.
Thank you, again, for solving the problem so courteously and efficiently.
yes & no - all files in DT are also available in Finder (by selecting “Show in Finder” from the context menu of the file in DT; this will show you the file in the depths of the database. Whilst you should never alter files this way [because the changes won’t be reflected in the database], you can access the file attributes here; this is actually a wonderful thing about DT - it does not use a proprietary format for storing the files).
I think a smart rule and a script could change files from “read only” to “read & write” on import - I’ll have a think about that in the coming days (unless @chrillek comes along with a more efficient JS implementation in the meantime).
What a challenge. Apple’s JS support is peculiarly, to use a neutral term. In fact, file operations seem to work only in the context of currentApplication. Anyway, I’ll give it a try. However, I don’t think the smart rule would be able to detect if a file is read-only, so the script just has to set it to read/write regardless.
I’d kind of assumed this would work, but it doesn’t (@bluefrog: heeeeeeeelp!)
on performSmartRule(theRecords)
tell application id "DNtp"
repeat with theRecord in theRecords
set thePath to path of theRecord as string
tell application "Finder"
set locked of (thePath as POSIX file) to false
end tell
end repeat
end tell
end performSmartRule
I can make preview open a file that way, but apparently finder needs something more…
Goodness - talk about learning something new every day: you’ll gather I had no idea of that! Anyway I checked the properties of the older file which would not imprint but it was read and write. However, I know why: I was able to annotate it in pdf expert and saved a flattened version for DT.
I really don’t wanr you and @chrillek to go to trouble for me - although I rather suspect you both love a challenge! However Hazel deals with renaming and duplicating invoices (so I initially have a copy in Finder and automatically filed in DT) - which gives me time in future to check whether imprinter works on the imported file and, if not, savage the one still in Finder!
on performSmartRule(theRecords)
tell application id "DNtp"
repeat with theRecord in theRecords
set thePath to path of theRecord as string
tell application "Finder"
set locked of item (thePath as POSIX file) to false
end tell
end repeat
end tell
end performSmartRule
That unlocks items. If you set up a smart rule which runs that script on import (and/or on creation) on all documents, they will all have their “locked” status in the file attributes removed. That should do the trick (assuming the file is locked rather than being read only in the permissions? - then we need to set a different parameter)
function performSmartRule(records) {
var app= Application("DEVONthink 3");
app.includeStandardAdditions = true;
var ioApp = Application.currentApplication();
ioApp.includeStandardAdditions = true;
records.forEach(rec => {
let path = rec.path();
ioApp.doShellScript("chmod u+rw '" + path + "'")
})
}
This might be considered cheating because I reverted to shell scripting here. One could use the ownerPrivileges attribute, but that presumably only works with a file, while I have only a POSIX path. So I decided not to bother with the “proper” way.
Remark: The same can of course be done in AppleScript, but beware of the file name quoting for do shell: it has to be in single (!) quotes to prevent the shell from interpreting special characters like “*” (which I had in one of my test files).
2nd remark: For some unknown reason, the JavaScript does not work as external script for me, DT throws an error 1708. It works fine in script editor though.
3rd remark: the usage of ioApp is due to Apples botched implementation of JavaScript for Automation. File operations only work in the context of currentApplication().
on performSmartRule(theRecords)
tell application id "DNtp"
repeat with theRecord in theRecords
set thePath to path of theRecord as string
tell application "Finder"
set owner privileges of item (thePath as POSIX file) to read write
end tell
end repeat
end tell
end performSmartRule
That assumes you are the “owner” of the file; in the section in “Get Info” was it the entry after (Me) that was set to Read only?
I’ve tried it on files I have previously set to Michael (Me) Read only and they turn to “Read & Write”, so I think that should work.
@chrillek thanks for playing I really value your input, because I have so little clue of shell scripting, JS or actually any other script that comparing “ways of doing things” is going to be the only way to gain at leat some insight
Stephen, glad to help - pls post whether this works for you too (you should be able to set up an appropriate smart rule with an action to run an embedded script; but raise your hand any time if it doesn’t work out)
The amended smart rule, incoporating your script, works like a dream: big grins here and many thanks again for the help. I owe you…but my tech. knowledge may insufficient to repay in kind!
I’ll just happily continue to value your posts here in this forum The way I see it knowledge is there to be shared - that way we all benefit from one another. And I’ve learnt something along the way, too What fun