[Bug]: Different Tag Box fields with the same name can be created, but added tags only appear in the topmost field

[samuellieberman]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

TagStudio Version

Alpha 9.3.0

Operating System & Version

Windows 11

Description

It is possible to create multiple tag box fields with the same name, such as multiple Meta Tags tag box fields, Content Tags tag box fields, or Tags tag box fields. However, any tags added to lower copies will not appear until you update your view of the entry, and when they do appear, they will always appear in the topmost tag box of the same name.

Expected Behavior

I expect that if you are able to create a tag box, you would be able to add tags to it, and that if you are not able to add tags to a tag box, that you would not be able to create it. Additionally, if we are not able to use two tag boxes of the same name, then I would expect us to be unable to use two text boxes of the same name, and two text lines of the same name.

CyanVoxel has discussed how he wants tag box fields to work multiple times in the past, in a comment:

Having multiples of the same field is intended behavior. However, I agree with the idea of being able to rename fields and/or restricting certain tags to certain types of tag fields. Both of these are on my roadmap, and I'll keep this issue open as a feature request for that.

And in the documentation for the planned Tag Categories system:

Replaces Tag Fields. Tags are able to be marked as a “category” which then displays as tag fields currently do, with any tags inheriting from that category being displayed underneath.

So it sounds to me that CyanVoxel wants users to be able to have multiple of the same field, but it also sounds like he doesn't want users to continue to be able to choose on an entry-by-entry basis which tag box a particular tag appears in. It also appears to me that the main purpose of these tag categories can already be mostly fulfilled by the display color of different tags.

Steps to Reproduce

1. Open a library with at least one entry in it.
2. Select an entry.
3. If it does not have one already, click Add Field and add a Content Tags field.
4. Click Add Field and add a second Content Tags field.

The topmost Content Tags field should behave as usual, whereas the Content Tags field below it should be unresponsive and any tags added to it should appear in the topmost Content Tags field after updating the view.

[samuellieberman]

#92 appears to be dealing with the same bug, though that issue describes it as being related to multiselection, however I am able to reproduce the issue without multiselection. Additionally, @Loran425 states that the issue should be resolved with the database migration, but the last two database schemas outlined in #190 still appear to relate tag fields to entries rather than solely to tags.

Personally, my primary concern is being able to keep working on my search functionality. But my own work depends on whether entries are meant to be able to have multiple tag boxes with the same name, and whether tag boxes with different names are meant to be able to share the same tags. It would be nice to get @CyanVoxel to weigh in on this, and to get the thoughts of @JoshuaMaddy from the db-migration branch.

[CyanVoxel]

#92 is indeed the same bug. An old update to the multiselection code included an incorrect assumption about there never being duplicate field types which leads to the undesirable behavior described.

Currently duplicate fields of all types are "allowed" to exist, however part of the new DB schema will restrict this to just non-tag field types. Tags themselves will be tied to entries themselves rather than fields, and any visual separation between themselves will be data-driven from the tags themselves rather than how they currently operate on top of fields.

With this functionality in mind, I'd say the intended search functionality would be to read from multiple tag fields of the same type as if they were a single field. As I think about it, it may be worth it to just create the future tag field limitation now and merge together any duplicate tag fields from existing libraries, that way it'll simplify your search process and help alleviate some of #92's current effects.