DT 3.7.1 appears to have introduced an oddity in smart rules which file by creation year. I have a number of smart rules like this:
(Please ignore the embedded script: it does nothing more than ensure the file is writeable.)
Prior to DT 3.7.1 if the rule had previously created a “2021” group (for example) it would re-use that group for any new 2021 invoice. Now the rule creates another 2021 group in the existing 2021 group and files the new invoice in that.
Has something changed and am I, as a result, doing something wrong?
The details of my system are as follows:
Computer: MacBook Pro (16 inch 2019); 2.4 GHz 8-Core Intel Core i9; 32 GB RAM; Intel UHD Graphics 630 1536 MB
macOS: 11.3.1
I am running DEVONThink 3.7.1 and all databases are stored on my MacBook Pro.
Hi Stephen That’s weird - before I see if I can recreate what you are describing, does the cascading continue, i.e., does the next record go in /2021/2021/2021 and so on or does it stop after one level with all records going into /2021/2021?
If it does stop after one level it might be worth temporarily moving everything out of /2021/2021 and /2021, deleting /2021 and letting the rule set it up again - just to see whether it still shows the same behaviour.
Very good question! I’ve just checked - there is no cascading of 2021 groups after the first duplicate is created. I haven’t at the moment time to check with the suggestion in your last paragraph (which is a good one) but will do so later and report back.
I moved everything to the global inbox from /2021 (where I had moved things before deleting the unwanted /2021/2021 group) and then deleted /2021 (so that there was then no group of that name).
I applied the relevant smart rule to the first item in the global inbox and it moved it to /2021/2021 (i.e., re-creating the sub-group).
Application of the other smart rules to the global inbox resulted in documents being filed consistently in /2021/2021 (i.e, not in /2021 as I would have expected and wanted).
Ok, so at least it is not self-propagating, which is good. I haven’t had time to see whether I can verify what is going on, but the following should solve the problem whilst @cgrunenberg has a look to see whether what you describe might be a bug:
property thePath : "/bills/electricity/" -- /group/subgroup/subsubgroup/ enclosed in ""
property theDatabase : "test" -- name of the database enclosed in ""
on performSmartRule(theRecords)
tell application id "DNtp"
try
repeat with theRecord in theRecords
set theYear to creation date of theRecord
set theYear to year of theYear as string
set theLocation to thePath & theYear
create location theLocation in database theDatabase
set theDest to get record at theLocation in database theDatabase
move record theRecord to theDest
end repeat
on error error_message number error_number
if the error_number is not -128 then display alert "DEVONthink" message error_message as warning
end try
end tell
end performSmartRule
If you use that script instead of both the Move and File actions, it should work. Obviously, you need to change the path and name of the database in the property lines at the beginning of the script to whatever you need.
I have done basic testing and the script seems to do what it should; as always, please do some testing of your own before letting it mow the lawn and do the shopping.
It really is most kind of you to take the time to do that: many thanks. Please don’t be offended if I say that I’ll probably allow DT to do as it wishes for the time being—periodically cleaning up so long as things are not quite as I wish. The difficultty is that I have rather a lot of similar smart rules which file various invoices and statements in a similar fashion (but within different parent groups).
I feel guilty at letting you spend your weekend time on something I then decline to use.
Well don’t I love doing these little scripts, because I often have to figure out how to do bits of them. I save each one of them (haha, I’ve just realised I don’t have them in DT and really should index them) and use them to look up how to do x or y. Anyway, you neither asked me nor even implied I should sit down and script für you
Waiting for DT to solve this is an option, because it’s not self-propagating, so easy to clean up
Not a nuisance at all. (You’re not to blame for my poor work/life balance ).
This is a regression in smart rules and @cgrunenberg is aware of it. I have confirmed it does not occur in previous builds. Thanks for your patience, assistance, and understanding
It’s unfortunately a regression of version 3.7.1, the next release will fix this and should be available soon. In the meantime one workaround is to make Move/Replicate/Duplicate actions the last ones in the rule.
That’s weird - before I see if I can recreate what you are describing, does the cascading continue, i.e., does the next record go in /2021/2021/2021 and so on or does it stop after one level with all records going into /2021/2021?
I love doing these little scripts, because I often have to figure out how to do bits of them. I save each one of them (haha, I’ve just realised I don’t have them in DT and really should index them) and use them to look up how to do x or y. Anyway, you neither asked me nor even implied I should sit down and script für you 
).