I’ve got a whole bunch of PDFs in my global inbox that need to be moved to other group/databases.
I just searched for one in DTTG and clicked the ‘organize’ button (the icon resemblingb a document stack with arrow pointing downwards), but the organize menu didn’t display. If however I do not search for them, but simply select the same document in the global inbox, the organize menu is displayed.
Inspecting multiple documents, I’ve got the idea those with a tag are the ones where the organize menu doesn’t work if I found them by searching. Can anybody confirm?
As a sidenote: the group in the tags group is located under Locations, which is confusing to me if you’ve got tags and regular datase groups that are similar. Was this also the situation with DTTG2?
The organize button is not in the items list, but in the standard location (top menu of document viewer)
search file A, click file, view document, click organize button, move file (as expected)
search file B, click file, view document, click organize button, no menu (bug?)
To follow-up on my previous comment. I thought tags were involved, but moving a random non-tagged document was no issue after it was tagged and searched for (the menu displayed as expected).
So there seems to be some other property of files in the category B above that make that the organize menu is not displayed after selecting it from the search list.
Addition: this seems to be device independent for DTTG3, i.e, searching for the same file and selecting it also doesn’t show the menu on another iOS device. A random other file can be searched for, selected and moved by clicking on the organize button.
Addition2: as various of my records have an ISO 8601 prefix, it’s easy to manually look for file B by scrolling through my global inbox after sorting it on date of addition. If I select it that way, the organize menu is displayed after the button is pressed.
If it was up to me, that would be more logical as the tags are already displayed and clicking those tags might also bring a user to the corresponding tags group. Although you can select the tag to delete it, it doesn’t lead a user to the tags group now. But if the behavior didn’t change in DTTG3, then likely other users might find it annoying if you change it based on my input. An intermediate suggestion might be to split the tags location from the groups and name them as such.
I’m not very keen on sharing screenshots, but from top to bottom:
Thumbnail Document B
Kind PDF document
Size 60 KB
Annotations Add Annotation
Locations Group Z
Added <some date>
Created <same date>
Modified <same date>
Group Z links to a group that’s located under tags (so group Z apparently is a tag). When I click it, DTTG3 takes me to that group and when I then select for example the document above document B in that list, the organize button starts working again. If I switch back to document B but selecting it, the organize button also works.
So it’s only the situation where document B is found by searching, the organize button doesn’t work.
Addition: the tag (group Z) isn’t the same as TagName. But group Z and TagName are displayed together in DT. The database in DTTG3 was a fresh download from a completely new sync store that I created with DT. Same goes for a completely different iOS device, that was also synced with that new sync store.
Might it be some tags somehow end up in the locations section and not in the tags section?
Yes, good point. There’s a whole bunch of common group icons (icon resembling a stack of papers) that should be a tag icon (resembling a… tag ) I presume.
The info popover reports:
The group was added in 2020 but modified February 13th 2021. If I recall correctly, that was before I created a new sync store from DT and resynced DTTG3 from that new store. February 13th was the third day I used DTTG3 and might very well be the moment I bought a second license due the family sharing issue and setup a third device.
No problem, I understand. User error is very likely in such situations. That said, group Z wasn’t moved to the tags as far as I can remember. And it’s not just group Z. There’s a whole list of groups residing under the tags of the global inbox, but in none of my other databases. There’s even a group under tags that’s called ‘Tag’ I noticed just now.
It does bring up another question: I only recently discovered tags are considered ‘groups’ when it comes to the total item count. But why would it be possible to move regular groups to the tags? Shouldn’t the tags ‘group’ as a special group be reserved for tags?
I’ve just gone through some other modification dates of groups that are in the tags group, and most have been added, created and modified at the same time and date back to 2020 or earlier.
If these ‘tags’ are indeed related to the problem that is. I’ll look for documents under the other groups and report back if the popover doesn’t appear when I search for records in these groups.
Update: there aren’t that many, but it appears this is the case for at least two other documents that have a group location ‘Global Inbox’ and a group location of a group that is present under the tags. After I searched for and displaying them, the organize popover doesn’t work.
I was able to reproduce the issue here by modifying a tag/group programmatically. Fixing it now for version 3.0.4 and thinking about a way to fix these groups that falsely appear as regular groups but inside the Tags container. Thank you for investigating this obscure edge case!
I’ve reviewed a backup, and the ‘good’ news is, there are also groups present under the tags before February 10th. So this situation appears to be unrelated to DTTG3.
The bad news is, there are many of such ‘groups under tags’ in various databases. They appear to be replicates, as the UUID of the actual group is similar to the group under the tags. But, the info popover in DT doesn’t report them as replicants. Also any content in the group-under-tag isn’t reported as a replicant.
When I drag the group into the database (disregarding it’s aberrant status), the group is reported as a replicate.
Perhaps, but I think it’s up to you and the DT staff to decide whether you want to investigate why groups can even exist under tags. The organize popover issue seems to be a ‘result’ of that possibility.
Addition: once the ‘groups under tags’ situation is removed, it was again possible to open the organize popover for the files that were/are part of that group.
Addition2: I’ve moved several records in DT and now are faced with replicates that are no longer reported as replicates. Same UUID, same database, different groups, but not reported as replicate. When I try to replicate them, nomreplicate is created.
Tags, technically, are just groups inside the Tags group. In DEVONthink To Go they also get a flag so that Core Data can quickly identify them without traveling any group hierarchies. The flag is the only difference. We will have a look why the fix command doesn’t update the flags when you run it.
Did the “Organize popover doesn’t open” situation change with 3.0.4?
Whether the 3.0.4 update repaired the organize issue for the files in the groups nested within the tags is difficult to say, as I’ve manually repaired the groups-under-tags by deleting them one by one.
I wasn’t prepared you would have a fix that soon! Otherwise I would have left them in place to check, sorry about that