Smart Rule confusion

DEVONthink Automation
1

I’ve got a rule which I think says:

“When new content is moved into database ‘TestBed’ replicate the content to ‘TestTarget’”. How am I misconfiguring this rule?

Screen Shot 2020-08-04 at 7.53.36 AM
Screen Shot 2020-08-04 at 7.53.36 AM1262×562 153 KB

2

There are two issues:

  1. The query is not a valid one, use e.g. Kind is Any Content instead.

  2. The rule searches in one database but tries to replicate to another database. Replicating across databases isn’t possible.

1 Like
3

Actually, to me it seems to say:

  • search in the Inbox of database Testbed
  • for something containing an asterisk (why wouldn’t you just use “Kind is any document” here?)
  • if this something is moved into Database (I’m not sure into which database it is going to be moved)
  • replicate this item into the same Inbox it hast just been found in

There’s no reference to a Database named “TestReplicator” except in the name of the rule. I have no idea how to achieve what you want to do (possibly replicate an item that is moved into the database TestReplicator in the database TestTarget) but I’m fairly certain that this rule is not going to work the way you want it to.

4

Thank you both for your replies.

It might be easier if I give a more general description of what I would like to achieve.

I have a master database with several groups. DevonAgent runs several searchsets and populates these groups. There are several team-members who each have their own database, they are tasked with studying the documents in one or another of the groups populated in the master database. I would like to duplicate the content of a subset of these groups to the appropriate team-member’s database inbox.

Is this possible?

Thanks

5

You were trying to replicate the content before. That’s not possible across databases, as @cgrunenberg explained. Duplicating however (i.e. creating a copy of a record in another database) is no problem. There’s an action for that in the smart rules.

Note the differences between replication and duplication:

  • replication does not create a copy but a reference to the document. A change in any of the replicants will be applied to all of them (because there’s basically only one document).
  • duplication creates a copy. A change in one of the copies does not affect any of the other copies.
1 Like
6

Thanks @chrillek and @cgrunenberg: I’ve got a rule that is doing duplication to the second inbox. I really wish it were possible to support replication across databases but this will work.

cheers

1 Like
7

That would cause interesting problems: the file would be inaccessible in database B if A were closed. Or if B were copied from one device to another, but not A… I guess that such considerations led the team to decide replication across databases would lead to more trouble than it was worth. Must admit that I’ve wished for cross-database replication in the past though :roll_eyes:

8

Replicating across databases in not technologically feasible. It’s not just a decision we made but a byproduct of the core structure and implementation we use. So an implementation would likely require substantial changes under-the-hood.

9

Thanks for that addendum - I’m actually happy to hear it; keeping databases separate from one another has some obvious advantages* which, as far as I am concerned, outweigh the advantages of cross-database replicating. It took me a while to adjust my workflow to that reality, that’s all :slight_smile:

* well, ones which I imagine to be the technical case, anyway. Like having a good chance of limiting any catastrophes to one database rather than risking propagation. And, I assume, providing a secure technical basis for the server edition to only provide access to those databases intended by the master.

10

You’re welcome :slight_smile:

11

I rarely delete content from my DB, but I needed to delete some replicants in DTTG recently.

What I found somewhat annoying in that case was:

  • replicants aren’t colored in DTTG and can only be recognized by the icon (and the presence of multiple locations)
  • deleted replicants are send to the trash

Particularly the last one is somewhat impractical IMHO, as the idea behind ‘trash’ is to provide an option in those cases where a file is wrongfully deleted. But of course with a replicant this is somewhat irrelevant, as the original is still present.

12

DEVONthink on the Mac moves deleted replicants also to the trash actually.