StashIDs for Tags

Hello all,

Recently I made a PR to allow users the ability to assign StashIDs to tags. This is step one in, what I believe to be, a larger project. I am looking for feedback or opinions on how to move forward.

PR for the code nerds: Feature: Tag StashID support by Gykes · Pull Request #6255 · stashapp/stash · GitHub

Current standing:

This allows users to assign a stash ID in 2 main ways

  1. At the creation or rescan of a tag
  2. External Plugins (StashId Tagger Plugin as an example)

I believe the current way of adding StashIDs to tags in this current PR is not intuitive and needs some for of tagger similar to the studio tagger. If you have pre-existing tags that you want to add IDs to then it is… painful.

Currently you have 3 options:

  1. Use scene tagger to reapply all your tags (Slow and painful)
  2. Use Identify and let it go to town on your library (I’m sweating just thinking about that)
  3. Use a plugin and manually apply StashIDs to all your tags (Slow and painful)

I believe the next stop for this would be to add a “Tag Tagger” to allow users to tag a lot smoother to align better with Studios.

Comments, questions, and concerns are welcomed :slight_smile:

hello, obscure bug finder here :waving_hand:

this might need changes upstream in stash-box before we can proceed with tagger interface. Ran into this when working on one of my projects. 1 2

stash-box returns absolute matches over alias matches, even if they’re deleted. You can replicate this with the following graphQL queries

deleted tag “Upshots” edit

query {
  findTag(name: "Upshots") {
    deleted
    id
    aliases
  }
}

this returns

{
  "data": {
    "findTag": {
      "deleted": true,
      "id": "b0b09f78-6e80-4ee8-9b38-dd5cac51ed6a",
      "aliases": []
    }
  }
}

replace that with findTagsOrAlias and you get a very different result
query:

query {
  findTagOrAlias(name: "Upshots") {
    deleted
    id
    aliases
  }
}

result

{
  "data": {
    "findTagOrAlias": {
      "deleted": false,
      "id": "25f9b324-f458-4683-a8ac-d91786eb45dc",
      "aliases": [
        "Below Shot",
        "Below View",
        "From Below",
        "Low Angle Shot",
        "Low View Angle",
        "Upshot",
        "Upshots"
      ]
    }
  }
}

I could take a look at the Stash-box code and figure out if that is a feature or a bug :sweat_smile:

Never looked at it and might need some guidance from Infinite on how they would like to handle it.

I’ve yet to do a proper review of the PR, but I think it’s likely a good start.

Related issue: [Feature] Add StashID's to Tags · Issue #2643 · stashapp/stash · GitHub

What I would eventually like to see is that tags will optionally point to multiple stash-box tags, with the option for scrape and submit stash-ids.

Unless users sync their local tags with those of their stash-boxes, there are going to be differences between the two. When scraping, you might want a single stash-box tag to be mapped to multiple local tags. Similarly, when submitting a draft, you might want a local tag mapped to one or more stash-box tags. These mappings are not necessarily the same and will be dependent on the stash-box instance.

For example, there are many variants of Cowgirl in stashdb. You might have a single local tag for that, but match any of the variants in stashdb to that single tag. When you submit a draft containing that tag, you likely only want to include only the Cowgirl tag, so that would be the submission link.

For the UI for adding stash ids to a tag, I think the simplest way forward is to add the option to link a tag to a stash-box tag in the tagger view when adding a tag to the scene. Similar to linking a performer, this will add the stash-id to the tag.

I also think it’s past time to allow manually adding stash-ids to objects in the UI. I think the process with this will be something similar to scraping where the user can click something in the edit view to link to a stash-box item, which opens a dialog to search for said item in stash-box. It will then add the stash-id to the list.

All these things are worth PR’ing separately and aren’t needed for the initial feature PR.

2 Likes