Organize menu does not work when selecting record in search list

OK. I’ve just tried it but it worked. I’ll give it a more thorough test tomorrow.

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.

I just checked and we do already filter tags. Could you provide a screenshot that shows what you’re referring to?

Could you show me a screenshot of the Info popover for the document?

I’m not very keen on sharing screenshots, but from top to bottom:

X                      Info

Thumbnail Document B

URL (empty)

TagName

Comments (empty)

Kind        PDF document
Size        60 KB
Annotations Add Annotation

Locations   Group Z
            Global Inbox

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?

I’m not very keen on sharing screenshots, but from top to bottom:

You can always start a support ticket and send us screen captures / screencasts.

@Solar-Glare When you go to the Tags group of the database in question, do the icons of Group Z and all other tags differ? What does the Info popover say for Group Z?

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 :grinning:) I presume.

The info popover reports:

...
Kind      Group
...
Locations Tags

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.

Ha! :slightly_smiling_face: Do you remember if you added the group manually inside the Tags group or if it was moved there during a sync but shouldn’t have? Just exploring possible reasons why it is so.

To remedy the situation move the group out from there or add another Z tag to the document and then delete the Group Z.

Now the question remains why that should keep the Organize popover from appearing :thinking: I’ll have a look at the code now with all the additional information.

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!

1 Like

Where do I apply for the bug bounty? :grinning:

Just kidding of course, but my biggest question is how the groups even got there. I’ll try and review the backup of my global inbox and see whether these groups were present before February 10th.

That’s an interesting question. Could have been a malfunction in an earlier version of DEVONthink To Go or happened during a sync :slightly_smiling_face:

Could you try and paste x-devonthinktogo://fix into Safari and press Enter? This should force-update some important properties including the flag that tells a tag that it is a tag.

Where do I apply for the bug bounty? :grinning:

It will help you in your next life :pray:t2: :slightly_smiling_face:

1 Like

Done. Some updates were performed. Had to restart DTTG3 though, as I was still in the tags group and that seemed to stall DTTG3.

Restarted, performed x-devonthinktogo://fix again, but it didn’t fix the groups in the tags. As far as I can tell nothing changed.

Fair enough :grinning:

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?

When you look at the Info popover of these moved items, is this reflected under Locations? Means: the connection to the previous other parent is lost?

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 :smiley:

Same answer as above

Could you please open a support ticket with step-by-step how to reproduce the issue including what you’re moving from where to where and what the state of replicants is before and after? Still trying to imagine what is happening on your device :slight_smile:

Well, to be honest I wouldn’t know what steps to write down to reproduce it. I really don’t know how the groups-in-tags got there in the first place. The bug with the organize-button more or less happened to point me toward these groups, as I wasn’t aware they were there.

I’ve cleaned things up by removing each group one by one and checked whether they behaved like replicants. Most did, but as I recall moving a group parent higher up in the tree (I tried to speed up things after a while) appeared to delete the originals as well. I.e. in that case, the groups in the database were also removed.

All in all my tags are now back the way they should be: just tags. So there’s really not that much for me to test or try at this moment.

It might be the groups were a remnant of previous DT2 behavior perhaps, as is described in this topic and on which I commented:

I’ll keep a lookout for new groups-in-tags in the future, but I presume it’s a ‘ghost from the past’.

I’ll keep a lookout for new groups-in-tags in the future, but I presume it’s a ‘ghost from the past’.

That’s what I think too. Thank you for watching out!