When I right-click and select “copy link” on an e-mail, I get (something like) this:
x-devonthink-item://%3CCE12711E-E84B-4EC8-9E82-632A7E67D5EB%40example.com%3E
which decodes to
x-devonthink-item://<CE12711E-E84B-4EC8-9E82-632A7E67D5EB@example.com>
Doing the same on another record (non-email), I get
x-devonthink-item://418ABA00-D5FA-4B78-AE31-13FF9FFA40B0
i.e. an URL, not a URL-encoded string.
I suppose that this is intentional, since getRecordWithUuid works just fine with the e-mail thingy. But what is the intention?
In case of emails it’s the message ID (e.g. to easily check whether an email has been already imported).
1 Like
As an e-mail’s Message-ID is meant to be unique, it’s a not unreasonable UUID for DEVONthink to inherit/exploit/utilise for e-mails when they’re imported – and, in fact, I’m exploiting this unique and reproducible attribution of Message-ID to DEVONthink UUID to my advantage in my “separate attachments from e-mail” script.
Same goes for DEVONthink item links, which are based on the DEVONthink UUID.
The UUID and DEVONthink item links are preserved across imports of original and modified messages, as long as the Message-ID stays the same, even if an original imported copy of a message is deleted (and even if other items are already linked to that UUID and/or item link!).
This predictable behaviour by DEVONthink doesn’t only benefit the inherent e-mail import functionality, but is exploitable more generally, as I am doing.
Sean
