stashapp
[Feature] Smart Tags (Organized Saved Filters)
Is your feature request related to a problem? Please describe. I try to be euphemistic here... Let's say I'd like more hair tags, Long Blond Hair (Female), Red Pigtail Hair (Female), etc. and put them under an Appearance tag as children tags. I can make normal tags now and link them directly to scenes, which is a lot of work and I have to do it again every time there are new Performers and Scenes. Or I can create saved filters for this but after a while it will be just a long, unusable list.
Describe the solution you'd like If I could make a Smart Tag with "Long Hair AND Blond Hair (Female)", etc. boolean criteria, it would solve both problems.
A Smart Tag would be like a normal tag, you can list and edit it on the Tags tab, you can put it into the parent-child tag hierarchy, you can add description, aliases and image to it, etc., but it is dynamic based on a boolean criteria, so you don't link it directly to scenes and performers, it's automatic if the criteria is true.
And, of course, this is just a minimal example, we could make more complex criterias, like "Long Hair AND (Blond Hair (Female) OR Red Hair (Female)) NOT Curly Hair", etc.
It's similar than the Smart Collections in DAM softwares like Lightroom or iMatch, only this would be in the parent-child tag hierarchy and not separated like in those programs.
Describe alternatives you've considered A better way to organize saved filters than a long list. But that would be a separated organizing area, this would be more "built-in".
I was just thinking of this concept and applied the same name, Smart Tags. Decided to query first, and voila, someone already created a FR.
What happens though in instances where you have an existing "normal" tag, and want to create a smart tag of the same name. For example, the tag petite and a smart tag named petite (filtered for a specified performer height). How do they co-exist? Should they co-exist? I mention this because I suspect users will want to create simple smart tags like this that are based on objective performer attributes, and having to give one of these tags an alternate name would be meh.
My solution would be that the filter exists within a tag, much like the aliases do.
Tag
Name
Aliases[]
Filters[]
Description
Parent tags
Sub tags
Ignore auto tag
Oh, so you could put into the filter's boolean expression anything, other tags and performer attributes alike? I was thinking only in connecting tags more, but that would be even better, yeah.
I agree it can be in a filter field inside the tag table, it'd be more built-in.