Imprinter fails apparently randomly

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

Stephen

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?

Thanks so much for your helpful thoughts.

  1. All invoices are dowmloaded pdfs—nothing is scanned by me. I simply import into DT and the result is a pdf + text “kind”.

  2. I have tried - since your idea - checking by opening with both Preview and PDF Expert (my default pdf viewer) and neither show the imprint.

  3. 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.

Stephen

Thanks for your kind words :slight_smile:

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 :wink: My son is standing next to me going “Daaaaaad”, so please add them yourself at your pleasure :smiley:

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. :pray:

Stephen

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).

Oh, and you’re most welcome :slight_smile:

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! :grin: 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!

Thank to you both…again.

Stephen

Here you go:

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)

Thank you. However, the only potential problem is that the original files are not expressly “locked” but merely “read only”.

Stephen

Ah, I’d just edited my post to ask that - hold my beer.

Here goes …

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().

1 Like
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?

Screenshot 2020-08-19 at 14.43.25

1 Like

Yes - exactly that!

Thank you both very much: :beers: all round, I think! I shalll experiment a little…

Stephen

Not only did you beat me to it, but I’m also wondering how to express this in JavaScript. Probably not worth the pain.

I’d wager that you’re safe to assume that, since all processes are run by him (Mail, import, Hazel, DT)

:+1:

Stephen

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 :smiley: 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 :slight_smile:

Stephen, glad to help - pls post whether this works for you too :slight_smile: (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!

Stephen

1 Like

I’ll just happily continue to value your posts here in this forum :slight_smile: 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 :relieved: What fun :+1: