Using DT 3.5.1 I’ve discovered an unexpected behaviour related to a new feature in 3.5.
Select multiple groups in the sidebar
Select an item that has replicants in other groups (which are not selected in the sidebar)
Command-delete or right-click > move to trash
All copies of that item are moved to the trash
This same behaviour also occurs if I have “unified inboxes” selected in preferences, select the top-level “inbox” group, and move a replicated item to the trash. It is then removed entirely, from the inbox as well as its replicated location (in this case, replicated via group-as-tag assigned at capture in the sorter).
Both cases are unexpected behaviour. It’s led to quite a bit of data loss in my case: I emptied the trash without realizing this was occurring and lost a significant number of items. I have backups, thankfully, so all is well in my case—but this should be either rectified, changed, or made absolutely clear at the time of the action so other users also don’t have unintended data loss.
Thanks for the feedback! Removing only one replicant is only possible in case of a selected group, e.g. it’s not possible in case of smart groups, search results or multiple groups as the desired replicant is not known. However, in this case…
…it should be actually possible. The next release will fix this.
To be clear on the intended behaviour - say I have three groups: A, B, C. Groups A&C have a replicant of a document. If I select only groups A&B in the sidebar and move the replicated document to the trash, will DT also move the replicant in group C to the trash? This is currently what happens and is quite unexpected! If this is the intended behaviour, there should be a warning of some kind as it’s easy to delete items unintentionally.
That’s a bit disappointing. Can you explain why this is the intended behavior currently?
I think rather than an alert, a better solution would be to only move the replicants in Groups A and B to the trash and keep the one in Group C. Why would anything else be intended?
OK - but still, rather than give an alert, why not fix it to do what 99.9% of users would prefer (anticipate) it to do and which would be infinitely safer to avoid inadvertently deleting something important?
why not fix it to do what 99.9% of users would prefer (anticipate) it to do and which would be infinitely safer to avoid inadvertently deleting something important?
Indexing is not the default option for a reason. It should be carefully considered, including ramifications deleting indexed groups and files. And DEVONthink has no concept of what’s “important”.
If you issue warnings, people want a way to surpress the warnings.
If warnings are surpressed, people are unhappy they got no warning.
Then the snake continues eating its own tail.
I would say it is definitely NOT the “expected behavior” with replicants as you should be able to delete one replicant and all others stay unharmed. Or did I get it all wrong?
People might lose their files accidently. I find that is not nice. The pending deletion of such a replicated file should at least give a warning message.
Do you think you can implement a warning message without much refactoring? Or did you do that already? I have not tested this I have to admit.
The next release will show a different alert in this case (and other similar cases, e.g. smart groups or search results) if the items that are going to be trashed are replicated.
I only would like to know if there ever was a problem or did you fix something? Up to now Christian only wrote that you would show a different alert message. But then I even do not experience any problem.
I am in a state of confusion…
