How can a Smart Rule replicate items to a group in a smart way?

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:

  1. 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.
  2. 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”.
  3. 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?

Whilst that’s true, keeping all the other rule conditions and including the “document is not already in group”-condition in a script as the rule action would be possible. All the other rule actions would also have to be contained in the script, of course, as they would be executed by the rule otherwise. Whilst the rule would now trigger more often than you actually want, it would not act any more often.

The rule won’t add additional replicants if there’s already one in the group.

You’re right – that’s another option.

This comes as a surprise, because I have definitely ended up with second replicants in the destination groups. So I set up a controlled experiment like this:

  1. created a group at the top level of my database (“testgroup”)
  2. created a new top-level tag ('testtag")
  3. created the following smart rule and put it first in the list of smart rules:

Next, I went into the “Saved materials” group and tagged a couple of PDF files with tag “testtag”. The files were added to group “testgroup” as expected. I next untagged one of the files, selected some other files but didn’t do anything (just to unselect the file in question), reselected the same file, tagged it again with “testtag”, and indeed it did not get replicated to “testgroup” a second time.

This is extremely puzzling because I’ve had to remove extra replicants by hand (that’s what prompted this question in the first place). I went back to one of the actual smart rules I’m using and removed the excess conditions, and ran it selectively on some example files, and sure enough, no extra replicants were created. So at this point, I don’t know what caused the extras. My best hypothesis now is that it’s possible they arose because the real smart rules are acting on indexed folders, and maybe there is some interaction with how the files in the external folders are manipulated by another program. I’ll have to keep monitoring the situation to see if it happens again.

Anyway, @cgrunenberg thank you for your reply. It’s great that smart rules are, uh, smart
like that :slight_smile:

1 Like