No you should not have both installed, at least not on the same account. But even then it’s not a good idea unless you’re setting per account permissions to hide one version.
Short answer: If you have transitioned to version 3, delete the 2.x application, and reboot the Mac.
I recently purchased DT3. I deleted 2 and rebooted; still no luck.
In the debug window in Script Editor, I am seeing this type of error:
tell application “Finder”
get POSIX file “/Users/aaronhand/Documents/Misison Viejo Elections.dtBase2/Files.noindex/rtfd/9/FW_ Records Request - CVRA lawsuit.rtfd”
→ error number -1728 from POSIX file “/Users/aaronhand/Documents/Misison Viejo Elections.dtBase2/Files.noindex/rtfd/9/FW_ Records Request - CVRA lawsuit.rtfd”
If I put a delay command into the script and navigate into that directory in the database package, I do see that a .rtfd document was created and exists in that location.
practically i think evaluating the needs from 300000 emails and it´s attachments is a crazy amount of work. i mentioned that problem to devonthink a long time ago, but it seems, mdbraber solve the problems of not indexed email attachments in devonthink for devonthink. so we all should thank mdbraber and not just write “you don´t need all…” what about other users that expect to find emails AND documents INSIDE devonthink. The most will not recognize that they attach 5mb Trash PDF files inside a eml INSIDE devonthink and get NO ADVANTAGE from it. So my big Question is. Maybe Bluefrog uses it only for Printing the E-Mails? Why we have an “special E-Mail Plugin und special E-Mail Import in devonthink” if you cannot find the same amount of Informations as you have in the Mail.app from Apple ?
@aaronhand you just need to give the Correct Rights inside “Full Drive Access” in “Security” of OSX for DevonThink 3, and run the Script. It can import the Files as described.
I use various email services, including Apple Mail
My intended purpose is email, not storage/archive
For storage/archive, I use Devonthink as my digital filing cabinet
Why we have an “special E-Mail Plugin und special E-Mail Import in devonthink"
Others may find these useful, but I prefer running a script for selected emails
I also use the script to save a copy of all sent email
I like this script and use it often. My workflow, however, would work better for me if the script would not create a new group, but leave the original mail and all its attachment in their original location. My knowledge of AppleScript was too spurious to do it myself - would you or anybody else be able to help me out? Thanks as always.
It would be a lot easier to help you if you posted the script here. Please enclose the code with three backticks like to
```
code
```
-- Import attachments of selected emails
tell application id "DNtp"
set theSelection to the selection
set tmpFolder to path to temporary items
set tmpPath to POSIX path of tmpFolder
with timeout of 14400 seconds
repeat with theRecord in theSelection
if type of theRecord is unknown and path of theRecord ends with ".eml" then
set theRTF to convert record theRecord to rich
set theURL to reference URL of theRecord
set newGroup to false
try
if type of theRTF is rtfd then
set thePath to path of theRTF
set theGroup to parent 1 of theRecord
set theName to name of theRecord
set theModificationDate to the modification date of theRecord
set theCreationDate to the creation date of theRecord
set theAdditionDate to the addition date of theRecord
tell text of theRTF
if exists attachment in attribute runs then
tell application "Finder"
set filelist to every file in ((POSIX file thePath) as alias)
repeat with theFile in filelist
set theAttachment to POSIX path of (theFile as string)
if theAttachment does not end with ".rtf" and theAttachment does not end with ".png" then
try
with timeout of 7200 seconds
-- Importing skips files inside the database package,
-- therefore let's move them to a temporary folder first
set theAttachment to move ((POSIX file theAttachment) as alias) to tmpFolder with replacing
set theAttachment to POSIX path of (theAttachment as string)
tell application id "DNtp"
if newGroup is false then
set newGroup to create record with {name:theName, type:group, modification date:theModificationDate, creation date:theCreationDate, addition date:theAdditionDate} in theGroup
end if
set importedFile to import theAttachment to newGroup
set URL of importedFile to theURL
set the modification date of importedFile to theModificationDate
set the creation date of importedFile to theCreationDate
set the addition date of importFile to theAdditionDate
end tell
end timeout
end try
end if
end repeat
end tell
if newGroup is not false then
tell application id "DNtp"
move record theRecord to newGroup
end tell
end if
end if
end tell
end if
on error msg
display dialog msg
end try
end if
One thing I find weird (but I’m not an AppleScript afficionado):
if newGroup is false then
set newGroup to create record with {name:theName, type:group, modification
date:theModificationDate, creation date:theCreationDate, addition
date:theAdditionDate} in theGroup
end if
set importedFile to import theAttachment to newGroup
and you have set newGroup to false at the top of your script. So why ask for it, if you already know that it’s false? OTH, if it were true, your code would fail mserably, because set importedFile to import theAttachment to newGroup would import your file to true.
As to your original question: You already know the group where the original record is located (or at least a group) because of
So get rid of all this newGroup stuff and simply
set importedFile to import theAttachment to theGroup
That is, if I understood you and the script correctly. Which might not be the case, given the coding style.
<rant>
AppleScript would be a lot easier to read without these useless the in variable names. And without flags (newGroup in this case) re-purposed as something else. Dynamic typing can be a nice thing, but in many cases it is just a PITA.
</rant>
That worked, thanks a bunch!
BTW - I didn’t write the script, I just copied from the beginning of this thread.
Don’t worry, it’s nothing personal - @chrillek is our resident JavaScript guru, and kinda despises AppleScript 
Good catch, though, @chrillek - I wonder whether the original author intended for the options to be false or /path/path/ rather than false/true.
While i can’t deny that, in this case it was more about the infatuation with putting the in front of nearly every variable name. And I’m aware that it’s not a language requirement or feature but rather a weird habit of many authors. Which doesn’t help with readability, i think.
While readability is of course a personal preference, this easily ensures that variable names are not identical to names of properties or commands.
Original author here. Not sure why I exactly included that, but I think it was just to be able to run the script without that part by setting newGroup. On using the with variables it’s exactly like @cgrunenberg says: it’s indeed ugly, but Applescript is weird / eccentric when it comes to reserved variable names and this is the easiest way to prevent accidentally naming something that is actually a reserved keyword.
I see.
And there are of course other examples of bad readability like Java’s endless method names.
By “original location” I’m guessing you mean the original .eml file
I often use this record if I don’t need access to the attachments
I’ve recently rewritten this script / approach. See Separate imported e-mail attachments for better search V2 for an updated version.
That’s a great solution for my long-lasting problem. One question though. Is it possible to modify the script so that the attachment(s) is/are renamed according to the Name of the email? Possibly after set importedFile to import theAttachment to newGroup command I sense that the name of the attachment could be modified accordingly. Since I have no experience with Apple Script, any help is appreciated.
Thanks for sharing.
try: set name of importedItem to name of theRecord after the line set URL of importedItem to recordReferenceURL
importedItem did not work as intended. I used importedFile instead and it works like a charm. Thank you.