Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug Report] Remove Opaque Tag Matching #749

Closed
AdultSun opened this issue Jan 20, 2024 · 0 comments · Fixed by #759
Closed

[Bug Report] Remove Opaque Tag Matching #749

AdultSun opened this issue Jan 20, 2024 · 0 comments · Fixed by #759
Labels
help wanted Extra attention is needed

Comments

@AdultSun
Copy link
Contributor

Describe the bug
May not be considered a bug exactly, but for most users it appears like one. Matching local tags with Stash-Box tags should only use Stash-Box names, Stash-Box aliases, or (in the future) StashIDs. Currently, Stash-Boxes will also use the names of previously merged or renamed tags to match with local tags as well.

IIRC, tags included in draft submissions were originally matched to tags in Stash-Box based on exact names, merged tags, and renamed tags. At this time, aliases served no mechanical function and simply represented a list of alternate tag names. Eventually their functionality was expanded and added to the logic flow, superseding everything except exact name matches. Currently, the process of matching a local tag in a draft submission to a tag in a Stash-Box looks something like this:

  1. Look for matches to the exact name of a Stash-Box tag (case insensitive)
  2. Look for matches to the exact alias of a Stash-Box tag (case insensitive)
  3. Look for matches to a merged tag under an existing Stash-Box tag
  4. Look for matches to the previous name of a renamed Stash-Box tag
  5. If no matches are found in the above steps, display at the top of the draft form as "unmatched data"

I could be mistaken about no. 4 or it might be swapped in priority with no. 3, but this is the basic situation.

This matching process is completely opaque to the user, meaning any time it reaches steps 3 or 4 it looks like a mistake. It also means that there is no way to remove a tag name/alias from matching with draft submissions once it enters the system as a tag's primary name. The only option is to redirect the alias to somewhere else by changing a name, reassigning the alias, or creating a new tag. There is no way to allow that alias to remain "unmatched" in draft submissions because it will always be recognized as either a merged tag or a previous name. Unfortunately, the opaque nature of this functionality also means that most users don't realize what their options are to resolve these issues because they don't understand what's happening behind the scenes.

To Reproduce
Steps to reproduce the behavior:

  1. Merge Tag A into Tag B, without preserving Tag A as an alias
  2. Submit a draft to create a scene containing Tag A
  3. The draft should now contain Tag B despite Tag A's absence as an alias

Expected behavior
The functionality of steps no. 3 and 4 should be disabled and removed from Stash-Box. Local tags in draft submissions that don't match a current name or alias should be left unmatched. We already have the ability to manually adjust which draft submitted tags should match with which Stash-Box tags, so there's no reason to allow Stash-Box to guess the best match anymore. This will become even less relevant once StashIDs are added to local tags in Stash -- avoiding the current over-reliance on names and aliases as well -- but there's no need to wait for StashID matching before removing the merged/renamed tag matching.

Ideally, the logic flow would look something like this:

  1. Look for matches to the saved StashID from this Stash-Box's endpoint (not possible yet)
  2. Look for matches to the exact name of a Stash-Box tag (case insensitive)
  3. Look for matches to the exact alias of a Stash-Box tag (case insensitive)
  4. If no matches are found in the above steps, display at the top of the draft form as "unmatched data"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant