Update 2021-07-06: the multiple replicants described here must have been caused by something else. Smart Rules in DEVONthink will not replicate items multiple times. You can ignore this posting, but I don’t want to delete it in case someone in the future searches for similar things and the information is useful.
Suppose that I want to create a Smart Rule that replicates documents to a specific group according to certain criteria. Suppose also that this smart rule is meant to be triggered automatically when new files are imported or created (i.e., it’s not merely an on-demand rule). And suppose that the documents to be replicated may already have replicants in other groups as well, which means that the smart rule condition can’t use “item is replicated” as a way to exclude items that already have been replicated.
How can the Smart Rule be written such that the rule does not match documents that have already been replicated to the destination group? In other words, how can I avoid replicating the same documents over and over?
The possible rule conditions in DEVONthink 3.7.2 do not include a way to test against a document being in a given group, so the rule conditions can’t directly have a test for “item is not already in group such-and-such”. That would have been the most direct way to implement this rule. Lacking this, the only alternatives that come to mind are:
- Use labels: set a label when documents are replicated, so that the smart rule can test “label is not such-and-such”. This is problematic if your labels are being used for other things.
- Use tags: create a tag to represent “has been replicated to that special group I’m using” and tag the replicated items with it, so that the smart rule can test “tag is not such-and such”.
- Use a custom metadata field: add something to the metadata field, so that the smart rule can then test the value to exclude items that have already been processed by that smart rule.
#2 is my current approach, though I feel it’s unfortunate to have to pollute the tag hierarchy with special cases like this. So I wonder: is there a better approach?