Is it possible to exclude groups from search scope of a smart rule?

TL;DR: Is there a way to exclude documents from the search scope of a smart rule that are a member of a specific group (the personal Inbox)?

We have a workflow where documents like paper mail is scanned to a personal pseudo-inbox (a nested group in the Inbox called “Inbox NAME“) and replicated to one or more (other) personal inbox(es).

The idea is that multiple people can all view incoming documents, but only one has to classify/archive one of the replicates. The others can trash the replicant after reviewing it, as long as one of the replicates is archived.

I am looking for ways to improve the workflow, e.g. by creating visual clues. I have achieved this with a smart rule that adds a colour label upon import and create certain tags. Of course the replicated file(s) are labeled identical as a property of a replicate.

Use case: if one person moves the file from their personal Inbox to any other group within that database except the trash, the label changes from colour A to colour B.

The only way I seem to be able to achieve this with smart rules, is by setting up a rule for every group within the root of the database. The rule is triggered before synchronization, as “Upon move” seems to work only without DTTG.

However, there are over 20 groups resulting in 20 smart rules. Using the database as a search scope seems to include the Inbox, and thus changes the label of not yet archived documents as well.

My question: Is there a way to exclude documents from the search scope of a smart rule that are a member of a specific group (the personal Inbox)?

Any other suggestions to improve the workflow?

It’s only possible to exclude items (e.g. documents or groups from searching), see Info inspector. Afterwards smart groups/rules won’t find them anymore but the search neither.

The good thing: it indeed excludes, and I learned something new :slight_smile:
The bad thing: I should have thought through my question better, as excluding the group also doesn’t change the label in the personal Inbox anymore :frowning:

I’ve just created a smart rules for every group in the root. Thanks nevertheless for the quick response!

Create custom meta data e.g. “DEVONthink_setup” and assign it to all groups you want to exclude.

Thanks, good idea! I tried it, but the search for documents in a smart rule seems to ignore the meta data of the group that contains the file.

Opposite of that, the suggestion of @cgrunenberg seems to exclude all results even if one of the replicates is outside the group that was excluded from the search.

Might I coin a feature request for a more granular search scope in the smart rule dialog window? I think the only way to achieve my question with one smart rule currently would be to group all folders in the root and use that group as a search scope.

Primarily it would be nice if it was possible to select multiple folders and/or exclude (special) folders in the search scope of smart rules. Secondary, it would be nice to influence the way search handles replicants in groups that are excluded from search.

Whether the development of this request is feasible and the result is understandable for most end-users is another question of course.

2 Likes

That’s correct, any exclusion is sufficient to exclude an item, additional replicants do not matter at the moment.

Sorry, what I had in mind was something like this (it needs a new group on root level which holds all your other groups):

  • Create custom meta data
  • Create a smart rule for the inbox which will set all inbox children to meta data = 1 (you’ll have to experiment with the trigger…)

2019-12-13_09-52-33

  • Move all your groups to a new group on root level (in order to create a new search scope which you can use in a second smart rule)

  • Create a smart rule for the new root level group which will set all children to meta data = 0 after moving them

2019-12-13_09-53-28

EDIT: If you just want to exclude the inbox from search scope creating a new group on root level should do it (no need for custom meta data…)