there is a generic component here (modified date, removing extension, lowercasing everyhing)
the problem now is that it seems the smart rules are executed randomly and independently. creating smart rules that are mutually exclusive to each other seems tricky and error prone.
In hazel the order of the rules within a directory matter and you can cancel the execution of the directory. that makes quite a bit of sense as you are basically looking at rules as a function, in a way. in DT you cannot do that it seems but you also donât have if-else statements
Posting something that is not related does not really help. I do not even understand what your problem might be â did you try to define smart rules that do not do what you want? Then please show them. Do you not know how to define the smart rules that do what you want? Then please give a step by step description
what your input looks like
what you want your output to look like
As to the screen shot: Why would you do OCR on something that has a word count > 20, so presumably already a text layer? If you do not OCR these documents, why use the trigger On OCR? Why do you use Before Synchronization? Do your documents come from another DT installation?
There is an exception to the execution by order and thatâs interval triggers.
An interval starts at the moment the Smart Rule is saved, both for the first time and for every time it gets edited later.
So when you have two Smart Rules with the same interval trigger, say Every Hour, it is the Smart Rule you saved earlier that gets executed earlier, its position in the order notwithstanding.
i canât seem to make it work. they are definitely not applied top to bottom. my top rule has a cancel and yet the bottom one is applied. trigger is as shown above in the screenshot
edit: i think i just stumbled across a bug. i duplicated my rule and that seems to reset the triggers. didnât notice but that explains why i couldnât get the order to work cc @BLUEFROG
i do not know how to structure my smart rules. it is an architectural question i guess
i showed the input and output above. as described above, what i would like to do is something like this
generic step 1
generic step 2
if data contains bmw
do A
else if data contains audi
do B
else if data contains tesla
do C
end if
generic step 3
generic step 4
where do C could be anything. but lets keep it simple: i want to add tags and change the name.
screenshot, though specifics arenât relevant as you can see from my above reply:
i donât do OCR on it in the rule
might be the wrong trigger, i thought it would run the rule after the OCR
You have shown the required structure yourself. Place your rules in the order you showed in that post; donât use the Cancel action until the last generic step (or maybe you want the rules to cancel if the brand-specific rule triggers? Then include the Cancel action there, too). Because you canât do if else, each one of BMW, Audi, Tesla need their own rule. The on OCR trigger will only run if OCR is triggered manually (or by the OCR action in a rule, I think), but not by OCR triggered as part of the import process by the appropriate setting in the preferences. If you want to trigger your rule as the document arrives in your inbox, use on import (which will run after OCR has been performed, if OCR is set to run in the preferences). If you are collecting documents with DTTG and want to run your rules once the documents reach your Mac, use after synchronisation.
I use scripts for complex rule actions; so I would actually only write one rule for what you are doing, and script the actions. I only really do that because I donât like having that many rules (subjective) and canât in any way catalogue the rules (e.g. putting the rules you describe into a folder car rules).
That is not a bug, but intentional; new rules are set to on demand by default; that way they donât do anything until you have finished setting them up. Rules are powerful - you could, for example, easily and irreversibly rename every single document in your databases catâŚ
As @Blanc pointed out, you canât do if-then-else in rules directly, so one possibility would be to have different rules for each âif data containsâ step. An alternative (a better one, in my opinion) would be to use an AppleScript for that. Have it scan the plaintext of the document for the terms youâre interested in and then act accordingly. Iâd probably have the script run as the last step, so that it can do everything not possible or not simple with smart rules.
Another possibility would be to do the heavy lifting in Hazel (which you mentioned before, so you probably use it anyway). Thatâs what I do with my banc account statements: Thereâs one Hazel rule for every banc which sets the name of the document (including the account numbers, for example). At the end, all these relatively simple Hazel actions call the same JavaScript script which moves the documents to the appropriate DT databases and groups. This script can easily use the account no to identify the appropriate database/group combination or a tag or something else.
Having separate rules seems a bit error prone to me, especially since you have to reproduce the steps 1 through 4 for each of them. If thereâs an error in one of these steps, you have to correct it for every version of the rule.
i really dislike applescript and moved on from it. i wonât be creating new functionality with it, especially now that omnifocus is using omnijs.
the problem with hazel is that i wouldnât be able to use DTTG i assume? i would have to put the pdfs i find onto dropbox and kick hazel off. hazel and my dropbox folder are unfortunately unreliable as hazel doesnât seem to trigger correclty for new files at times. getting it straight into DTTG would be much easier.
actually, @Blanc makes it sound like steps 1 to 4 could be handled by ordering the rules correctly.
I understand that; but in general a duplicated rule will be one which you still want to edit (as you wouldnât typically need two completely identical rules). Itâs a safety mechanism which always applies. We can be of differing opinions as to whether it should apply without exception, but I donât think itâs a bug
that depends on your originals; sure, the more precisely you define the conditions, the less likely you are to have the rule act on files you donât want it acting on. But if your documents will never contain all three terms, you donât need to exclude anything.
DT will run the rules time and time again so long as the conditions are fulfilled. So, as in your originally posted rule, you need a condition which prohibits the rule from running again; you used a tag, but you could equally say âif name does not containâ or whatever defining feature you want. My rules act on the inbox and end up moving the document to a different group, so the rule will never act twice on that document.
use on import
correct; for example, when I import documents from my insurance company, an AppleScript will detect the policy number with an if/else routine, determine the group the document is to be filed to and the document name on that basis, rename the document, mark the document read and locked, move the document and display a notification.
I agree. Unfortunately, DTâs JavaScript integration is not up to par in the context of smart rules â less diplomatically: it it unusable.
The problem with smart rules in DT are that they do not work in DTTG, so thatâs pretty much the same situation.
You could put the PDFs wherever, preferably a local folder that Hazel is watching. I use a folder in iCloud Drive for that which works reasonably well. Also, the documents are moved from there into DT, so no residues, no space consumption.
I doubt that any smart rule will get you anything âstraight into DTTGâ, though
what i meant is that quite often i import into DTTG first and it gets synced to DT where the smart rule runs. with your approach i wonât be able to import into DTTG because i need hazel to run on the files. will have a look at idrive, maybe thats more stable. thanks
