Detect Items Only In Tags

I’ve mentioned this before here, but I want to raise it again, as this issue keeps biting me (badly)…

In DT, it is rather easy to create an item that only exists “within” a tag. This happens to me when I’ve clicked on a tag to browse some stuff, then (stupidly) right-click and choose “New Rich Text” or similar while still looking at the tag. Yes, I shouldn’t do this, but it’s far too easy to do. I’m sure I’m not the only one.

Trouble is, this is a time-bomb. In most cases, its safe to delete a tag since the tagged items will still exist in the database (in some group or other). Except, of course, when you have one of those items that accidentally only exists in the tag. Result: lost data when you innocently delete the tag.

Worse, there is no way I can find to easily detect this. So we have a situation that is easy to get into, hard to detect, and can result in lost data. In my book, that’s a prefect storm.

So, I have a suggestion. There is already a search/smart group term “Item is/is not Tagged”. How about adding a new one “Item is/is not Grouped”? (Or, in search syntax, “item:grouped”). If I understand the tag/group model correctly, this should be trivial, since its almost identical to the tagged test.

With this simple addition, its easy to create a search/smart group that detects items that are tagged but not grouped (“item:tagged item:!grouped”). Which is exactly the set of items that are in danger of being deleted with a tag.

Have you checked the root of the database?
If you create a file in a Tag group, it should create a replicant in the database’s root.

I just tried that … no sign of the item in the root of the database.

However, it did create the item in the database Inbox. Which seems to be new behavior, but will help avoid the problem. :slight_smile:

Hmm… I’ll have to check this as we may have changed the default location in these situations.

And actually the behavior has been in 3.x for some time as we wanted to combat the exact situation where people make files in a tag group.

… and I really like that 3.x does this, it makes the tags and groups much more robust.

There are still a few holes though. For example, I can right-click on an item in a tag, choose “Duplicate To…” and then choose a destination tag from the “recents” list, which creates a brand-new item that’s only in the target tag (nothing appears in the Inbox in this case, I checked).

I’d still like the “Grouped” search option I mentioned though, since (a) this can catch the edge case like the above and (b) it helps to cleanup 2.x databases where it was far easier to create these “tag only” items.

I checked this yesterday and it worked as expected. How did you exactly create the document? A screenshot might be useful…

…just like in this case, tags shouldn’t be even part of the recents list.

Ok I sat down and carefully went through all ways I could find that seem to create an item that only exists in a tag. I found three ways to do this, two of which look like they could be bugs. Rather than just show screen shots, I did all the testing in a small database, which is attached. See the README document in the database root for information on the test procedure I used, and my analysis of the results. Hope this helps.

Isolation (27.0 KB)

Thank you for the test!

The next release will fix these issues.