Ahh, I see what you’re seeing now. And yeah, I’d opt for RegEx too.
Thanks a lot, renaming works just fine now.
The smart rule does not trigger on import though…
How are you getting the file into DEVONthink?
Using the solution this thread is mostly about.
Devonthink - Import & Delete + Folder Actions.
I’ve tried pretty much every other relevant trigger and none seems to be working.
Folder actions and AppleScripts do not trigger smart rules.
You’d be better off indexing a specific folder, say on your Desktop, into DEVONthink, then targeting this group with the smart rule.
Printing a PDF to the indexed folder on the Desktop
File Opens in Preview with the modified name
The file with the modified name in DEVONthink
And lastly… the smart rule
Thank you so much for looking into this so thoroughly.
For many reasons, I’d rather have the files falling into the database.
At this point I am considering editing the original DEVONthink AppleScript and have it rename and open the file itself, bypassing DEVONthink before import.
-- DEVONthink - Import & Delete.applescript -- Created by Christian Grunenberg on Fri Mar 26 2010. -- Copyright (c) 2010-2014. All rights reserved. on adding folder items to this_folder after receiving added_items try if (count of added_items) is greater than 0 then tell application id "DNtp" to launch repeat with theItem in added_items try set thePath to theItem as text if thePath does not end with ".download:" and thePath does not end with ".crdownload:" then tell application id "DNtp" set theRecord to import thePath to incoming group if exists theRecord then tell application "Finder" to delete theItem end tell end if end try end repeat end if end try end adding folder items to
I think this means you want to import the files. If so, that’s exactly what the Move into database action on my smart rule does.
Correct me if I am wrong, indexing a desktop folder like that means that it stays out of the database folder tree whilst being connected to it. Correct?
In essence, yes. It links to the item outside the database instead of copying it into the database’s internals.
The Move into database action will move the file from the Finder into the database’s internals, allowing you to keep the external folder empty and ready to receive new content, i.e., as a watched folder.
PS: Indexing is discussed in the Help > Documentation > In & Out > Importing & Indexing, especially the Indexing and the file system section. Pay special attention to the Indexing and the filesystem section so you understand how actions in DEVONthink can affect files in the file system.
Hm, Jim, I’ve been interested in this as well. I set up RTWS-PDFwriter to print to
“/Users/Shared/PDFwriter/” as indicated by Rod, and indexed this into DT, and added the rule that you created above.
In the rule’s “Search in:” input, I just navigated and pointed to (via Default Folder) the indexed folder with my username inside /Users/Shared/PDFwriter/
I can see the pdfs being added to the folder, and indexed into DT, but the rule is not triggering…
(username blanked in the img below)
- Is anything reported in the Log window?
- Does the rule work if you drag and drop a file onto the it?
That’s great then. I was a little bit concerned about leaving the files somewhere else on my hard drive. As it moves the PDFs in the database I’ll implement your workflow as soon as possible. Thank you for the detailed explanation.
Jim, nothing in the Log.
How do you drag and drop a file onto a rule? I can’t seem to be able to do it.
Two issues I think:
Permissions, maybe? Indexing the “username” folder inside “/Users/Shared/PDFwriter/” but files printed to it don’t show up in Devonthink
If I move the pdfs to some non-indexed group inside Devonthink, and modify the rule to look into this group, setting the kind as “PDF/PS” doesn’t work with my “PDF+Text” files, and I don’t know how to set the kind to “PDF+Text” - but if I set the kind to just “Any document” it works ok.
- The Shared user folder has always been known to be fiddly with permissions. Did you set the permissions on that folder to include Read & Write for the account you’re logged into?
- There isn’t a setting for PDF+Text as the type is PDF/PS, regardless if there’s a text layer or not.
What’s your rule look like?
My rule is exactly as yours. If I change the kind to “Any document” it works.
I just set permissions to RW for me and Administrators, but still not working.
The little print app sends the job to a print spool inside HD/private/var, that’s where the pdfwriter/username folder is located (and appears as an alias inside Shared)
Also: I see that for a pdf Script Debugger (DT Dictionary) tells me there is a property TYPE (always “PDF document”) and a property KIND, which is either “PDF+Text” or “PDF Document”.
In the rule editor, KIND can only be “PDF/PS”
And in DT’s list view, the column KIND shows either “PDF+Text” or “PDF document”
That is a bit confusing. The table matches the AS properties, but the smart rule is calling a TYPE a KIND?
Here’s what works for me - a mix of several things above.
- set up RTWS-PDFwriter to print to “/Users/Shared/PDFwriter/username"
- Attach an action to that folder - in my case Christian’s “DEVONthink - Import, OCR & Delete.scpt”
- The new pdf is in Inbox, now use Jim’s (AKA Bluefrog) smart rule to strip the initial “job_” from the pdf name. BUT! - I added a clause that “Name” “begins with” “job_” - just to make sure
Strangely, NOW a “Kind” = “PDF/PS” works fine. Ah the vagaries of a digital life.
Minor caveat - it takes 5-10 secs for the renamed pdf to reappear in Inbox. Folder Actions.
I am having problems with this too.
Once “/Users/Shared/PDFwriter/username” is indexed, DEVONthink only sees its status as the exact moment when it was indexed, though sees no more updates after that. I.e. doesn’t see new files added to the folder.
I think the issue is in fact that it’s a shared folder. A solution could be to have the folder action to move the files in another indexed folder (located somewhere else). Yet the level of fiddling needed to make this work, potentially creates a tremendous amount of issues down the line.
Funny enough, someone here complained about me calling this a workaround…
Hope you guys can help.
It certainly takes that long because of the unnecessary OCR…