Describe the solution you'd like
I had an idea on the Discord that the StashDB site should have a Changelog section, where you can track bulk changes to the database, and also with site/network additions. Perhaps also error correction too? Thus allowing users to know when to scrape/re-scrape certain network/sites/performers. Example below:-

14/05/2021 - Added PerfectGonzo Network
13/05/2021 - Linked X-Art Performer Aliases to Parent Performers
12/05/2021 - Added PornHub (MadeInCanarias)
12/05/2021 - Split Lucy Heart into multiple performers (Lucy Heart, Veronica Heart)

Something along those lines, open to debate though (particularly the splitting up of merged performers, though I argue this would be useful, people can check the changelog and see "okay, there was an issue with Lucy Heart, let me go to her profile in Stash and re-scrape those scenes")

Is your feature request related to a problem? Please describe.
There are Stashbox guidelines for uploading images, but how many users will review them before adding or modifying content? Most probably won't.

Describe the solution you'd like
Incorporate relevant guidelines into the relevant sections. For instance, when adding an image, include a link or text to the image guidelines. It would be a helpful reminder. It would also be a good idea to include an example of an ideal image.

We may want to include something like for whatever types of shots Stashbox prefers:

• 1/4 headshot
  Crop from mid-section, generally just below the the breast -- but not always as this will vary based on very large breast size -- to just above the head (leave a small amount of padding btw the top of head and edge of image). [sample of ideal pic here]
• 1/4 tight headshot
  Crop from the collar bone area or just above shoulders (crop just above the shoulder bone while showing the trapezius) to just above the head (leave a small amount of padding btw the top of head and edge of image). [sample of ideal pic here]
• 1/2 headshot
  Crop from the bellybutton (or precisely just above it) to just above the head (leave a small amount of padding btw the top of head and edge of image). [sample of ideal pic here]
• 3/4 headshot
  Crop from above the knee or mid-thigh to just above the head (leave a small amount of padding btw the top of head and edge of image). [sample of ideal pic here]

This is anal af, but it will produce consistent looking pics.

If we could host Logo's and images for the studios with support for maybe multiple / set one as default (rating based maybe?)
Then the stash clients could pull the image easily when needed.

This would also remove the manual legwork everyone needs to do to make it look nice, sharing the load of these logos would be good.
Also would be a way to share custom logos someone might make in different styles or looks like a shared unified color style.

EDIT:
These uploads should support SVG vector files as they are lossless and scale to any size and is really small... though limited to many different colors.
This way users could trace bad image files from sites and made clean and sharp vectors that scale to any size and need you want!

We're going to want a front end load balancer and reverse proxy so that we can deploy and test the API directly on http and via https. I would almost go as far as to suggest that the API should not operate in plaintext but that's up to @WithoutPants and @InfiniteTF to discuss how that'll work.

Is your feature request related to a problem?
Scenes can be added without any performers attached to them. This leads to a tsunami of new scenes without any performers attached to them.

Describe the solution you'd like
The scene creation wizard should disallow the creation scenes without any performers attached to them. If there are any studios that don't list performers, the democracy may add an exception on a per studio basis requiring a certain amount of votes, but those are fringe nonetheless.

Is your feature request related to a problem? Please describe.
Performer url's are in the database and in the graphql api but are not currently displayed or available to edit.

Describe the solution you'd like
On the performer page display a list of url's associated with the performer.
Update the edit performer pages and have a way to add a list of url's to the performer.

The graphql api will return a list of url's for the performer and will allow you to edit a performer and add a list of url's.
We just need a way of displaying and editing this information.

Is your feature request related to a problem?
Currently, it is not possible to search among the edits, except from using the basic filters. A simple text search would be useful to find edits of interest.

Describe the solution you'd like
Initially a simple free text search field that can search through edits in the title field, performer fields and studio field. In later versions, it would be nice to have more granular filters that we can save.

Describe alternatives you've considered
I've been using the favorite feature very primitively, I mark the studio of interest, look through the edits, then unfavorite the studio again.

Is your feature request related to a problem?
Currently it is not possible to view edits made to scenes belonging to a given studio. This would be a useful feature for moderation.

Describe the solution you'd like
There are three tabs on the studio page right now. 'Scenes', 'Links' and 'Edits'. I'd suggest to rename the 'Edits' tab into 'Studio edits', and add a 'Scene edits' tab that returns a feed with edits to the scenes within that studio.

if the SQLITE Renamer for Stash (rename on update) plugin is active the new Identify-function stops working.
Not sure if its a Problem at the plung in or the Identify-function

Hi guys! Your project is crazy awesome!

I'm new to Go and Gqlgen (an hobby, not a job) and I'm having a hard time with this: 99designs/gqlgen#866.

Basically: how to distinguish presence from nil (undefined vs null) in an Input type.

Gqlgen suggests to use mapstructure here: https://gqlgen.com/reference/changesets/.

How are you doing? Are you doing it?

Thanks for your amazing work! ❤️

Is your feature request related to a problem?
A lot of ambiguous performers (e.g. Maria) have bogus metadata attached to them, such as birthdate, eye color, images of disambiguated performers and so forth.

Describe the solution you'd like
Make it possible to mark performers as ambiguous. Once they are marked as ambiguous, all metadata fields will become locked, disallowing the addition of nonsensical metadata. Also, in the search results, the match should indicate that the performer is indeed ambiguous and should display the performer as Maria (Ambiguous).

Been trying to install this for the nth time today. I try to follow the instruction, but:

yarn install --frozen-lockfile
gets me only
yarn: error: no such option: --frozen-lockfile

That's the first issue
then when I go to /opt/stash-box and try to run
make generate
everything is fine, but as soon as I try to run

make ui build

I get

root@stashbox:/opt/stash-box# make ui build
cd frontend && yarn build
00h00m00s 0/0: : ERROR: [Errno 2] No such file or directory: 'build'
make: *** [Makefile:112: ui-only] Error 1

which now when I look at it seem like some sort of yarn problem?

To Reproduce
Steps to reproduce the behavior:

1. Install fresh copy of Ubuntu server
2. git clone shash-box
3. use the instruction and fail

Expected behavior
I would expect for the project to be built and, well, the instructions were unclear, so I don't really know what to expect and how to run it afterwards, but I assume the aforementioned errors are not the desired result.

Desktop (please complete the following information):

• OS: Ubuntu 20.04 running in a qemu vm

It might further improve the quality of uploaded pics by including cropperjs directly into the upload image section.

The cropperjs can be made to:

• Be locked into a 3:2 aspect ratio
• The cropper has a grid, and I'm sure it can be improved to suit the type of images Stashbox wants, such as a head guide that the uploader can use to fit their image into the guide like this:
• Depending on the type of headshot the user selects, 1/4 headshot, 1/2 headshot, etc referenced here #211, the above guide will change to suit the headshot style.

To support user preferences and different use cases for images, we should add image categorization.

• Resolution: 2/3, 16/9, etc.
• Crop: Bust, full body, three quarters, etc.
• Orientation: Front, side, back, etc.

Is your feature request related to a problem? Please describe.
This is not related to a problem but is rather a request for a feature that would greatly improve Stash's usability as a database tool. I am requesting a file renamer for the Stash utility.

Describe the solution you'd like
I would like to see a file renamer for Stash, ideally accessible from the scene list, or within the edit screen for individual scenes. This renamer would allow you to select the variables you want to use for renaming (i.e. scene name, performer, year, etc.) and then when you select "rename" it will rename the file in the windows explorer folder where the file is stored. Ideally, this would also create a subfolder with the same name and place the scene file in the subfolder. Think of TinyMediaManager's Rename and Cleanup feature.

Describe alternatives you've considered
We could do this manually, but for someone with a large collection, this would be extremely time-consuming and a rename/cleanup for files would be super helpful.

Problem

The current fingerprint submissions system is prone to bad data which involves manual labour to remove. This stems from the fingerprint submissions field being a simple counter which is incremented whenever a user matches it. Removing bad matches currently requires manually removing the entry.

Proposal

Fingerprints submissions should be related to the user that submitted them, and a user can only pair a fingerprint hash to a single scene. That is, if they re-submit the same hash to a different scene, then the original user/fingerprint/scene relationship will be removed in favour of the new one. The submissions field will then be a resolver of a count of total submissions in the database. From what I can tell, the existing submissions field isn't actually maintained.

Querying for scenes by fingerprint may return multiple candidates, and we should allow for this in the graphql schema and in the client tagger view. Obviously, the best match (ie the one with the highest submission count) should be displayed first, but other candidates should be available in case the first is not the correct match. If a user currently has a scene matched, then they should be able to unmatch it manually, as an alternative to matching it to another scene (in the event that an alternative scene does not exist).

Impacts

The one-scene-per-hash change will have impacts on the shared test account we currently have.

In order to maintain our existing fingerprint data, we will want to migrate it to link it with a specially created internal user.

Other considerations

I don't think that it's necessary to have a report or down-vote et al function for scene fingerprints. I believe that bad matches will tend toward the zero count, and good matches will inevitably tend upwards. When a user finds a bad match, they can unmatch on there system if necessary, and manually look for an alternative scene and match that as needed.

To reduce useless or bad data, we should consider automating the removal of single count fingerprints that are older than a configurable age. This will reduce storage overhead.

I'm not sure what use duration will be when moving toward this new mechanism. We should be using the "official" duration for match validation in the client. Submitting clips or compilations from a single scene should also be encouraged, so the duration may not necessarily match.

Implementation details

Database schema

In scene_fingerprints:

• deprecate duration and submissions
• remove updated_at
• add user_id uuid
• add indexes on user_id, scene_id and created_at

Graphql schema

• add unmatch boolean flag to FingerprintSubmission. When true, this will unmatch the scene from the fingerprint for the current user, if present.
• deprecate duration from Fingerprint and related objects - make it optional.
• add limit and offset to FingerprintQueryInput to designate the maximum number of matches to return and the offset. This means that a client can get the top match(es) and alternative matches as needed.
• findSceneByFingerprint should return QueryScenesResultType, or some intermediate type to prevent breaking changes. The main purpose is so the client can get the total number of matching scenes for a single fingerprint.
• likewise, findScenesBy[Full]Fingerprints should return an array of QueryScenesResultType, or some intermediate type to prevent breaking changes.
• fingerprints should probably be deprecated from Scene (and return an empty list) in favour of a query interface. The number of fingerprints could potentially get quite large.

Describe the bug
Whenever a mutation is sent to modify a value to NULL, the column is ignored and the old value is retained. This makes it impossible to set values to Unknown.

Scope

Creating performer disambiguation is currently a manual process dependent wholly on the editor. It adds extra layers of work that may or may not be performed. Can we automate this process?

Problem

Automatically scraping in new performers, creating one manually, or modifying an existing performer name, adds the possibility of duplicate name collisions -- an unavoidable problem. The solution is manually creating a disambiguation field. However, this presents some points of failure and extra work:

1. Performer creation or primary name modification
   A. The user should remember to query for the primary name to determine if it already exists. If yes, create/update the disambiguation field.
2. Primary name modification with an already existing disambiguation field
   A. Refer to step 1A
   B. If step A yields no results, remember to remove disambiguation
   C. The user should query the existing incumbent primary name. If there is only one other duplicate of the incumbent name, should the user remove disambiguation from that other performer since there will no longer be duplicate names? Who knows what a user will do.
3. Creating disambiguation
   A. How does a user decide what to use? What he thinks is relevant, may not actually be relevant
   B. Since this process is arbitrary, there is a lack of consistency throughout disambiguation fields
   C. The user may choose to disambiguate based on birth year, country, or any other existing attribute. If said attribute ever requires modification, future editors will have to remember to modify their reference in the disambiguation field as well

We could create guides/best practices for this, but we're adding complexity, and still relying on an editor to check a guide and implement what he's read, assuming he understood it.

Proposal

We can avoid all of this by implementing automatic disambiguation creation for every performer that is created or has their records modified.

Disambiguation variables

What information is generally relevant to a user who is querying a performer, and what information generally differentiates them from another performer with the same primary name (aside from an image)?

This is a proposed hierarchy of variables to use for disambiguation:

1. Performer aliases
   • Primary name (aliases) --> Svetlana (Sveta, Veronica, Maria Q)
   • Both indexxx.com and iafd.com use aliases as the main disambiguating factor. Why? I suspect users are more familiar with a performer's aliases than their birthdate or nationality. Often when querying, they could be querying an alias of the primary name.
   • Duplicate single name performers often share the same nationality (see this list of Svetlana's; how many are Russian? Plenty.), the combination of a performer's aliases are usually unique to that performer.
2. Birthdate and nationality
   • Primary name (b. yyyy-mm-dd, nationality) --> Svetlana (b. 1999-05-05, RU)
   • Failing a lack of any aliases available, use the birthdate and country fields together
   • When a death date is implemented it can be incorporated into the disambiguation
     • Primary name (birth year-date year, nationality) --> Svetlana (1999-2022, RU)
3. Failing birthdate AND nationality field, use either birthdate OR nationality (which ever field is available)
   • Primary name (b. yyyy-mm-dd) --> Svetlana (b. 1999-05-05)
   • Primary name (nationality) --> Svetlana (RU)
   • Nationality alone as a disambiguating variable isn't very good as mentioned above, but at this point the performer's metadata is thin. Performer's with similar first names tend to be from the same geographical regions. Performer's with Hungarian names tend to be Hungarian, Russian performer names tend to be from Russia, etc.
4. Failing that use ethnicity and gender
   • Primary name (ethnicity gender) --> Svetlana (White Female)
   • This isn't going to be very differentiating in most cases. If we use the list of Svetlana's as our example, most will all return White Female, with maybe a few Black Female or transgender outliers. Also, ethnicity can sometimes be an arbitrary field and may not be accurate (such as Latin, Mixed, etc).
5. Failing that, no disambiguation is generated
   • If a performer lacks metadata, no relevant disambiguation can be generated

In the future, if an alias + studio association is ever implemented, such as indexxx alias-studio association, we can use a performer's studio as a disambiguation factor, and decide where in the hierarchy it is used

Studios can have multiple logos and sizes: landscape, square, wordmarks, favicon, etc. Some logos also change over time. Please add the ability to upload more than one image per studio.

Bonus if the images can have labels, such as "landscape" for landscape logos and "square" for 1:1 aspect radio images.

Is your feature request related to a problem?
Currently it is not possible to show the pending edits you haven't voted on yet.

Describe the solution you'd like
Add a filter to display only the pending edits you have not voted on yet.

Is your feature request related to a problem?
In the current version, it is possible to submit scenes that have the same title, performers and description as existing scenes in stashbox. It is also possible to submit duplicates of pending scenes. Indeed, someone submitted the same scene as I had submitted a couple of hours before the other person. Ironically, my submission was down voted, because the later submission was accepted first, which led me to be wrongly accused of submitting a duplicate.

Describe the solution you'd like
On the first page of the scene submission wizard, return an error stating that there already exists a scene by the same name. The same should be true for submitting a duplicate draft, perhaps provide a link to the pending submission, so that you can vote it in.

Describe alternatives you've considered
The alternative is to let everyone check their submissions manually which is prone to human error.

Is your feature request related to a problem? Please describe.
Importing markers into stash at the moment is a bit of a hassle, it would be nice to be able to do this automatically from stash-box, this sort of crowd sourcing of metadata seems to be the exact purpose of stash-box

Describe the solution you'd like
share markers with an associated phash/oshash/scene_duration, that could then be imported on scrape from a stash instance

Describe alternatives you've considered
Scraping markers from various sites and creating corresponding markers via stash's graphql interface, this works but doing this via stash-box seems like a better solution and could benefit from crowd sourcing

We should be able to query urls on the site and if not found, it should have an option to request a scrape.
The Scraping system should be automatic with its own work queue for missing scenes. Ofc it should only scrape sites it supports.
Doing something like this, gives the users an alternative to find the scene they want if they found it somewhere else.
Also allows users to easily add scenes and all the metadata without manual input and mistakes which is safer in the end.

Describe the bug
Currently the list of genders is: Unknown, Female, Male, TransFemale, TransMale and intersex.
Non-binary does not exist in an option in stash-box but is an option in stash.

Additional context
Are there other genders we need to consider?
Might be worth asking for suggestions on what we should store

Describe the bug
When sorting by trending, scenes may show up on multiple pages.

To Reproduce
Steps to reproduce the behavior:

1. Go to a studio page, e.g. /studios/91792902-ba1e-4c5f-b7f5-c129e626ce8a?sort=trending
2. Make sure it is sorted by "Trending".
3. Some scenes may show up on multiple pages.

Expected behavior
The same scene should not appear on multiple pages.

Screenshots
If applicable, add screenshots to help explain your problem please ensure that your screenshots are SFW or at least appropriately censored.

Desktop (please complete the following information):

• OS: Arch Linux
• Browser: Google Chrome
• Version: 96

Is your feature request related to a problem? Please describe.

• Brunette and blonde are not gender neutral words. They're words using a feminine form (referring to women and girls distinctly).¹² Stashbox incorrectly uses the feminine form of said words to describe male, intersex, and unknown gender performers.
• White hair is missing

Describe the solution you'd like

• Change brunette to the gender neutral word brown
• Change blonde to the gender neutral word blond
• Add white hair (Stashbox already includes grey hair -- a mixture of white and existing hair that hasn't lost pigmentation -- and white hair is the next step in the process of "graying", when all hair has lost pigmentation or is artificially made white)

Additional context
This isn't coming from a place of wokeness or anything like that. It's simply a proper grammar thing since Stash uses the same set of words to describe men, women, intersex, etc.

I read it might be acceptable in some English language regions to use the feminine form for males too, but it's also acceptable to use the gender neutral form in those regions. Since it is correct to use the gender neutral form in all instances, I would default to the neutral form.

Is your feature request related to a problem?
It's hard to keep track of comments to your edits right now, you have to manually monitor your edits for comments and down votes.

Describe the solution you'd like
Add a notification system, notify when someone comments on your edit, when someone (down) votes your edit, and optionally when your edit gets accepted.

Describe alternatives you've considered
Manually monitoring the edits, which is tedious.

Right now, images are solely sorted by the image resolution. This is undesirable, the resolution of an image does not determine its quality. Some images may have a high resolution, but are in fact grainy. Also, the primary image may be unflattering or might not be the desired choice as performer card image.

This can be resolved by allowing users to upvote images and ordering them by the number of votes. The images that haven't received any votes remain ordered by resolution.

Is your feature request related to a problem? Please describe.
i have al lot of scenes from different sites with meaningless names (for example only a number) => a real pain to tag.

Describe the solution you'd like
On some studios there are real accurate duration times, if we could search for them it would make matching a lot easier.

here a litte example: site name + title = working

only site name = not working

Hello everyone! This is a long post, so hopefully I'm not overstepping my bounds here. I sent a rough pitch on how I thought tags could work to Stash (meaning the original developer) about a year ago. Basically, I shared the list of tags I use within my own personal, local database thinking it would be useful during development. Since work here seems to have become much less theoretical than those early days, I thought it could be worth sharing again.

(Also, my coding experience is extremely limited to the point of non-existence, so bear with me if I don't understand a lot of the more technical language or if I over-explain something.)

The premise I'm starting from is that for the tags contained in StashBox to be as useful and functional as possible, we should have a relatively static master list of possible tags. These tags should have clear definitions so both users and contributors know what everything means. Without a level of internal consistency to these tags, the accuracy and reliability of our data will suffer.

Stash saved and shared the outline/list/dictionary I sent him before. You can find the whole thing here, but because it's so massive to the point of being embarrassing I'll give a brief synopsis as well so nobody feels like they have to scroll through all of it.

Because I have such a large list of tags, the only way to keep it manageable was to group everything together. I'm not sure how everybody feels about how tags should be structured and implemented, so for now it can just be seen as a convenient way of organizing my list so it can be more easily read and understood. I also can provide screenshots of my database in case anyone is curious what this system looks like in practice. I assure you it's much neater than the massive document above would imply.

Synopsis

I have everything organized into three broad sections first, with smaller categories underneath each of them.

People Tags contains tags that describe the appearance of a performer and may be listed on either a performer's individual profile page or to describe the appearance of performers within a particular scene.

• Categories include Age Group, Hair Color, and Height.
• Tags include Teen, Blonde, and Petite.

Scene Tags contains tags that describe the make-up of a particular scene/movie.

• Categories include Group Makeup, Relationship, and Location.
• Tags include Couple, Girlfriend, and Classroom.

Actions contains tags that describe actions in the scene. I only have two categories for these right now, Acts and Finishers. The first describes most positions and actions while the latter is reserved for finishing acts. (I'm trying to keep my language clean so GH doesn't get mad at me.) This is definitely the least fleshed out aspect of my list and I'm still not sure the best way to organize it. It contains a lot of modifiers with hyphens and just looks really ugly. Parent and sub-tags may help with this, I don't know.

Approach

Because I've been actively using this list of tags myself for years now, I already have most commonly tagged aspects included with simple definitions for just about everything already. I've also designed it with a few key directions in mind as well. I'm sharing those thoughts here as a proposal for guiding principles to consider while finalizing our list of tags.

• Try to keep the language as inoffensive as possible, using more neutral words for tags and definitions.
  I tried to avoid sounding cold and scientific, but I also want the language to be palatable for as broad an audience as possible, considering the subject matter. No need to turn people off because the default tag names are unnecessarily vulgar.
• Allow for tags to be additive, erring on the side of inclusion.
  By "erring on the side of inclusion", I mean that if there's doubt over whether one tag should be used over another, it's probably best to use both. At the same time, tags are kept simple so that greater meaning can be achieved by combining them together. By following this system, we allow users to search for obscure aspects like, say, clothing that could be considered "business casual" by searching for scenes that contain both of the tags "Business Wear" + "Casual". This approach is closely related to my next rule of thumb...
• Approach subjective tags as objectively as possible.
  For example, for a couple body part related categories (you can probably guess which) I have tags for essentially small, medium, and large. Where is the dividing line between these categories, meaning, when does small become medium? This is an inherently subjective decision to make, but I believe an important tag to keep track of. So why couldn't we just list both tags that could apply, listing "Small" and "Medium" at the same time? That way the scene/performer would not be excluded from searches that only include one or the other. If a user feels that our definitions are too broad (meaning the performers with an additional "Medium" tag no longer fit the "Small" tag they're also applied with) they can modify their search to include "Small" while excluding "Medium" to get a more narrowly defined set of results. This allows for more flexibility when describing edge cases, while still maintaining specificity so that the individual tags are still meaningful. This is the only way I can imagine making subjective tags workable if we imagine a shared database with a large number of people contributing tags. Rather than constantly debating which tag is more appropriate, consider the existence of a debate as an indication that both tags are likely appropriate. Everyone should be guided by the question, "Could a reasonable person consider this tag as fitting?" Or put another way, "Would a reasonable person be overly surprised to see this as a result when searching for that tag?" Additionally, the meaning of various subjective tags should become clearer the longer the system is used. If there's a question of if a tag fits, simply searching for that tag will provide plenty of examples of approved uses of that tag to compare it too.

Possible Next Steps

As it stands, there are a lot of adjustments I feel could be made to my list. When considering it as a starting point for StashBox to use, the most glaring weakness is that it's too large. I should be able to cut the larger categories down to what I feel are the most common and most important tags without much trouble, so we can start with a much more manageable size, adding more as needed.

If we decide that this is a worthwhile starting point and that my conception isn't way off base from where everybody else intends to take the tagging system, I thought the Wiki section on GitHub could be a good place to start. We could create a "Tag Dictionary" organized by the "Sections" and "Categories" described above and I could start loading them with the relevant tags and definitions from my list. If I go one category at a time, we can discuss the merits and flaws of each one, offer suggestions or replacements, consider alternatives, etc. either within this issue page or on Discord. This can serve as a reference document both for developers and users.

However people feel about my proposal, I would still be interested in helping flesh out this aspect of the project. Like I said before, I don't really have any coding knowledge so I'm pretty limited in what I can contribute to this project. Let me know what you think or if you have questions. I have the same username on Discord as well. I've been thinking about all of this stuff for a long time now, so I'm interested to hear which ideas people like, which don't make any sense, whether any of it conflicts with current plans, and more importantly what makes the most sense for incorporating into StashBox at this time.

Having users use the shared test account is less than ideal, and I figure that we don't want to open up registration too much.

Propose adding the following user roles:

• FINGERPRINT_READ - allows querying for fingerprints only - plus the minimum operations for the user control panel to work.
• FINGERPRINT_SUBMIT - implies FINGERPRINT_READ, allows for submission of fingerprints.

Propose also that configuration should include default roles when a user registers without an invite code.

In practise, I see envision the following:

• open up free registration without invite code, allowing for fingerprint reading and possibly submitting
• maintain the existing invite code system, which assigns more broader roles

Is your feature request related to a problem? Please describe.
Currently performer's page in Stash does not reference any external web links (Twitter, Instagram, TheNude, EuroBabeIndexxx, Indexxx, IAFD). This makes it very difficult to positively match performers between Stash and StashBox, requiring error-prone match by name and manual review

Describe the solution you'd like
Add a table to track performers against their external web references, with a constraint that each web reference link must be unique (only point to one performer)

Suggested Performer Handles table would have 2 columns

1. Performer StashID
2. Performer Web Link (unique constraint)

Performer web link should be normalized using consistent rules (unique for each site)

• http or https
• with or without www
• .eu or .com
• trailing /
• remove additional token info ?= and sub-pages from the end of the link e.g. #bio #profile etc

Describe alternatives you've considered
Match by name or alias + birthday. This requires that birthday in StashBox and Stash match perfectly, and StashBox and Stash have common spelling of performer's name or one of the aliases.

Additional context

Here's an example of links for Foxy Di (scraped from Indexxxx):
"http://1passforallsites.com/model?id=980",
"http://babedrop.net/gallery/ddfnetwork/foxy-di/",
"http://egafd.com/actresses/details.php/id/f00253",
"http://fhg.errotica-archives.com/2019-10-01/KATOA/",
"http://nubiles-porn.com/model/profile/2410/foxy-di",
"http://www.18eighteen.com/teen-babes/Foxy-Di/7536",
"http://www.actrice-sexe.com/foxi-di/",
"http://www.amourangels.com/997/z_model_671.html",
"http://www.definefetish.com/models/3c5/foxi-di/",
"http://www.eurobabeindex.com/sbandoindex/foxidi.html",
"http://www.europornstar.com/Nensi-B/",
"http://www.exclusiveteenporn.com/model_247.html",
"http://www.firstanalquest.com/models/foxy-di/",
"http://www.kindgirls.com/gallery/domai/katoa/8317",
"http://www.naughtymag.com/amateur-girls/Foxy-Di/7536",
"http://www.pornteengirl.com/model/angel-c.html",
"http://www.showybeauty.com/997/model_280.html",
"http://www.teenpornstorage.com/3622/model_161.html",
"http://www.trickyoldteacher.com/model?id=980",
"https://ddfnetwork.com/pornstars/foxy-di/4279",
"https://fancentro.com/foxydi",
"https://nubiles.net/model/profile/2410",
"https://onlyfans.com/foxydi69",
"https://petitehdporn.com/model/profile/2410/foxy-di",
"https://teenerotica.xxx/models/268/",
"https://teenmegaworld.net/models/angel-c.html",
"https://wtfpass.com/models/foxi-di/",
"https://www.21naturals.com/en/pornstar/Foxy-Di/42129",
"https://www.21sextury.com/en/pornstar/Foxy-Di/42129",
"https://www.babesnetwork.com/model/3177/foxy-di",
"https://www.clubseventeen.com/girl.php?slug=foxy_b",
"https://www.cumlouder.com/girl/foxy-di/",
"https://www.danejones.com/modelprofile/43265/foxy-di",
"https://www.doghousedigital.com/model/58814/foxy-d",
"https://www.domai.com/model/katoa/latest",
"https://www.eroticbeauty.com/model/katoa/latest",
"https://www.errotica-archives.com/model/katoa/latest",
"https://www.evilangel.com/en/pornstar/Foxy-Di/34713",
"https://www.fakehub.com/modelprofile/43265/foxy-di",
"https://www.femjoy.com/models/medinau",
"https://www.freeones.com/foxy-di/links",
"https://www.goddessnudes.com/model/katoa/latest",
"https://www.instagram.com/foxy.shmoksi/",
"https://www.inthecrack.com/Model/368",
"https://www.karupspc.com/model/foxy-di-2293.html",
"https://www.legalporno.com/model/2852/foxy_d",
"https://www.lesbea.com/modelprofile/43265/foxy-di",
"https://www.metart.com/model/nensi-b/latest",
"https://www.milehighmedia.com/model/58814/foxy-d",
"https://www.mofos.com/model/3177/foxy-di",
"https://www.pornmegaload.com/hd-porn-scenes/Foxy-Di/50952/",
"https://www.realitykings.com/model/3177/foxy-di",
"https://www.roccosiffredi.com/en/pornstar/Foxy-Di/34713",
"https://www.rylskyart.com/model/foxy-di/latest",
"https://www.sexy-models.net/f/foxy-di/",
"https://www.thenude.com/Foxy%20Di_26953.htm",
"https://www.vivthomas.com/model/foxy-di/latest",
"https://www.webyoung.com/en/pornstar/Foxy-Di/29028",
"https://www.wetandpuffy.com/girls/foxy-di/",
"https://www.woodmancastingx.com/girl/foxi-di_5853",
"https://www.x-art.com/models/kate/"

Is your feature request related to a problem? Please describe.
A few fields would be more accurately represented with the capacity to have multiple values. This is related to #210 and expands upon it.

Describe the solution you'd like
Add multi-value support for:

1. Ethnicity
   Applicable performer's could have combos like Asian and Black to accurately reflect them, instead of falling into one of the other or into Mixed, which seems like a catch-all for unknown mixed ethnicity.
2. Breast type
   Many performers start their career with natural and change to augmented. How can we better reflect that?
   a. Allowing multiple values
   b. Allowing multiple values with an adjacent form for date ranges (i.e. "Natural, 2010 - 2015; Augmented: 2015 - 2019")
3. Nationality
   Somewhat of an edge case, but there are performer's that have dual nationalities. This would apply to people who are born in country a, but raised and are a citizen of country b. This is really pedantic but I thought I'd mention it for accuracy's sake.
4. Hair color
   See #210

If a search string contains e.g. ham/bacon this will end up as hambacon, which makes a match unlikely. Separators like comma, dash, slash, should be replaced with space instead.

Is your feature request related to a problem? Please describe.
Running on Linux, I install binaries in /usr/local/bin.
The running user does not have access to write to this folder, nor should it.

Describe the solution you'd like
I would like to see the config folder be placed in ~/.config/stashbox

Eventually Stashbox is going going to encounter cases of vandalism or a lot of good faith bad edits on the same recurring fields of data. While all edits require approval, the pending edits will still clutter the queue. I think this is where locked fields can be useful.

TMDB defines locked fields as,

Confirmed data is routinely locked by content moderators. Moderators may also lock data to prevent vandalism.
When you stumble upon incorrectly locked data, please use the report button, explain the problem and link us to a proper source if needed.

Locked fields are indicated by a padlock icon next to the field. Unlocked fields are indicated by an open padlock next to the field.

Is your feature request related to a problem?
The autocomplete suggestions that show up when adding performers to a scene don't show their genders. It is currently hard to disambiguate between performers that use the same name but that are of different genders.

Describe the solution you'd like
Prepend the gender symbols to the autocomplete suggestions.

The death date should be similar to birthdate, a fuzzy date field with two database columns to represent approximate dates.

Is your feature request related to a problem? Please describe.
Sometimes we do not have the bra size, only a bust size. The current measurements forms are good, but it will not accept a bust size.

Describe the solution you'd like
Split the current bra size form into two forms:

1. Bust size (only accepts numerical values)
2. Cup size (drop down form list with the following US cup sizes: AA A B C D DD/E DDD/F DDDD/G H I J K L M N O P Q R
   Automatically change any DD value to E; DDD to F; DDDD to G to make those cup values consistent through the database
   Source: https://en.wikipedia.org/wiki/Bra_size#The_meaning_of_cup_sizes_varies

Should function similarly to measurement fields in that it's hidden for "incompatible" genders.

Shoe size is a static property that should be relatively low effort to add. The only question is whether to pick US or EU sizes.

Currently, only performer names are considered when searching for performers.
The search term should be checked against the performer's aliases too.

Maybe the performer disambiguation should be considered as well, although they might need to be given less weight, compared to the name and aliases.

Problem

Need to provide a native data import process which handles mapping to other options. The process should allow for the creation of complete scene data without needing to perform post-import modifications.

Proposal

This RFC is based on the previous work in the branch at https://github.com/InfiniteTF/stash-box/tree/bulk-import

Here is the basic requirements I think are needed for the mvp import functionality:

• accept csv (json to come later)
• support mapping of csv columns to scene fields
• support fixed scene fields (not just studio)
• support manipulation of csv data via regex replacements
• support mapping studio/performer/tag names to existing objects

Here is how I envision the import process to work:

• user navigates to the import page
• user selects a file to import, configures scene field to column mappings (and fixed values), and clicks submit
• system parses the file, inserting the data into a database table, and attempts to match studio/tag/performer names to objects
• system presents the results and allows the user to map/change studio/tag/performer names from the data to actual object instances (using auto-complete selectors)
• user maps studio/tag/performer names to objects
• user clicks to submit
• system imports the data and removes the data from the import data table

Other considerations

• only one import operation may be performed per user. User may resume or abort processing of pending imports.
• stale pending import data should be removed eventually

Implementation details

Database schema

Add new import_data table:

• user_id - assuming a single import per user, this plus row should be sufficient composite key
• row - index of csv or json
• data - a jsonb encoded of the raw row data

If we need to identify stale imports, then we'll need a separate table to identify pending imports, with a user and date.

Graphql schema

• add submitImport mutation
  • accepts data file upload, a datafile type, and a list of fieldMapping objects
  • ImportFieldMappingInput includes outputField, optional inputField, optional fixedValue, optional list of regex replacements
  • processes the input file inserts into import table
• add queryImportData query, accepting page size and page. Returns parsed import data (does not translate tag/studio/performers).
• add importMappings query.
  • returns ImportMapping object, which contains studios, performers, tags fields, which are lists of name/id pairs
• completeImport mutation
  • accepts ImportMappingInput object which is basically the same structure as ImportMapping
  • creates scenes from the imported data, mapping tags/performers/studios as needed
  • names without a mapped id are ignored
• abortImport mutation
  • aborts a pending import for the current user, removing the data from the import data table

GUI changes

• add Import top-level menu item for allowed users
• if there is no pending import, then the import page will show the new import page, allowing selecting of data file and mapping of scene fields to data file fields
• clicking submit on this page submits the import and redirects to the pending import page
• pending import page is shown if there is a pending import for the current user
• pending import page allows browsing of the pending import data, and mapping of studio/performer/tag names to objects

Extensions for future iterations

• support manual data correction prior to importing
• support json files, mapping using gjson
• separate import role permissions and allow submitting imports with a separate user approving and importing the data

Is your feature request related to a problem? Please describe.
A lot of performers use a different hair color throughout their career, but only allowing one option limits us to just one hair color. If Jane Doe has brown hair in three scenes, and blond hair in three scenes, her hair color should be defined as both blond and brown.

Describe the solution you'd like
Make the hair color field a multi-value field. That is, let a performer have more than one hair color.

Additional context
I'm not sure if the various option is applicable here or if it's for performers that have multi-colored hair. Either way, it would be really vague to select various for every performer that has used different hair colors throughout their content.

Implement the option to amend/update already-submitted edits, prior to their application/rejection.
This will help immensely in resolving conflicts (when they are identified ahead of time), correcting mistakes (typos, missing/incorrect data, switching merge direction, updating merge sources) and generally updating data due to a comment from a fellow user.
Currently the only option is to cancel and recreate the edit.

A preliminary design idea - use the entity forms (PerformerForm, SceneForm, TagForm, StudioForm).
This is open to suggestions.

• By default, the form will be populated with the edit details, merged with the entity's current values - current value, unless edit details is not null for that field (edit details override entity's current values).
• Have the option to reset specific fields to the entity's current values.
• "Confirm" tab should diff the new values, either against the entity's current values, or against the edit's current details (this might be too confusing).
• Will require some changes to the components in order to allow passing all the "old" values (edit's old_details).
  Perhaps this will not be needed - if the "Confirm" tab will show the diff against the entity's current values, the user can determine what they need to change from that diff view.
• Merge edits are an edge case that need to be handled.
  Merge sources should be editable (removal), and the merge target should be changeable.
  I think this will add another layer of complexity to this feature, and may need to be delegated.
• Create edits should be fairly straightforward, since the created entity can be constructed from EditDetails and passed on to the form component.
• The buttons for amending and cancelling edits should be visible (in some fashion) on the edits list.
  Currently, the cancel button is only visible on a single edit's view page, and only at the bottom of the page, which is buried in my opinion, and users easily miss it/don't even know about it.

Added by InfiniteTF:

• Amending edits should remove all votes.
• Limit to one amend per edit, to prevent abuse.

#365

Introduction

This RFC covers the user registration and activation process and the user invite system.

Configuration

Propose to add the following configuration keys:

• require_invite [true] - if false, allows new users to create accounts without needing an invite key
• activation_expiry [2 hours] - time in seconds from when an activation event is generated (new user account, reset password requests) before the activation key expires
• email_cooldown [5 minutes] - time in seconds before a second activation email may be generated - to prevent spamming

New user process

1. New user enters email address and (if require_invite is true) a valid invite key.
2. System sends an email with a link to activate the account. The link includes a generated activation key.
3. User clicks the link and the system shows the activation page. User enters their email address (to verify), the password for the new account and hits submit.
4. System verifies the activation key and creates the account, setting the password.

If the user clicks the link after the activation_expiry period has passed, then the system reports that the activation link is no longer valid.

An invite key may only be used once. When the activation link is sent out, the invite key is considered used. The key may only be used again if the activation expiry has passed and the account was not created. The same key may be used to resend the activation email to the same email address, but only after the email_cooldown time period has passed.

Invite keys will be associated with the user that generated them. Accounts created by invite keys will be associated with the account that created the invite key. This association will only be viewable by users with the ADMIN role.

Invite system

Users may be granted any number of invite tokens, these may be used to generate invite keys. As mentioned above, an invite key may only be used once. A user that generated an unused invite key may rescind it and reuse the token to generate another key.

Two new roles will be created: MANAGE_INVITES, and INVITE.

A user with the INVITE role can generate new invite keys and rescind unused invite keys that they generated. They do not require invite tokens to generate invite keys.

A user with the MANAGE_INVITES roles may grant and rescind invite tokens for users to generate invite keys, and may rescind any invite keys. Invite keys rescinded in this manner do not refund the invite token.

Token management should be logged, including the user that performed the operation.

Interfaces

newUser - requires email address and optionally an invite key. Creates a pending user and sends email containing activation key.
activateNewUser - requires email address, activation code and password to set. Validates the activation code against the email address and creates the new user
generateInviteCode - use an invite token (if applicable) to generate an invite key. Returns the invite key.
rescindInviteCode - invalidates an invite key, refunding the invite token if the key was generated by that user.
grantInvite - increments the invite tokens for a user.
repealInvite - decrements the invite tokens for a user.

I will also include resetPassword - which will send an email with an activation key to reset an existing users password, and change changePassword to optionally accept the activation key to set the password.

Is your feature request related to a problem?
The 'Favorites' switch serves no function on the studio 'Edits' tab and could be removed to clean up the UI.

Describe the solution you'd like
It could be removed.

Scope

There is a significant desire to better organize performer images on stash-box, particularly by allowing images to be categorized by crop, pose, and state of dress.

Problem

Stash-Box performer images are currently organized by resolution only, basically serving the highest resolution image first followed by the rest in descending order. More popular performers can have many images and our StashDB guidelines encourage a diverse set for each performer representing various crops, poses, states of dress, and general "looks" from the performer's career. Typically, users will prefer a particular type of performer image for their personal use and are often left navigating stash-box's image carousel one-by-one until they find the "best" image. Currently, the only way to set a default image for a particular performer in stash-box is by making sure the preferred image has a higher resolution then the rest of the set. This is an imperfect work-around that requires maintaining a hard cap on image resolution for each performer rather than a true solution.

Proposal

The implementation of image categories could help to alleviate these issues. If individual images can be tagged with categories, users could set their own preferred defaults within both stash-box and their personal stash. A convenient system for categorization is already in use in the actress-images repo hosted by Trizkat. Though the collection is exclusively female performers (outside of a small number of AFAB non-binary performers), their system appears to be neutral enough to be suitable for performers of all genders. In their own words, with some light editing:

Crop

How much of the performer is visible?

• Face: Above the bust, and up
• Bust: Somewhere between the navel and bust, and up
• Torso: Above hips, below navel
• 3Q: Three-quarters view, about mid-thigh, and up
• Sit: When you see the person sitting
• Kneel: Where you can see the knees touch the ground
• Wide: For landscape images where the subject is in some horizontal position

Pose

How is the performer positioned in relation to the camera?

• Portrait
  • Front: Mostly facing towards the camera
  • Back: Mostly facing away from the camera
  • Side: Mostly facing perpendicular to the camera
• Landscape
  • Back: On their back
  • Fours, On all fours
  • Front: Mainly a frontal view and not covered by previous

State of Dress

What is the performer wearing, if anything?

• Non-Nude: Covered up, or can't be determined
• Topless: Defined by if areola and nipple is uncovered
• Nude: Exposed bust and pubic region

Set

Which photo set is this image from?

• The actress-images schema assigns each image a "set" number in their filename, grouping images of various crops, poses, and states that were originally part of the same photoshoot. This allows users to easily find a matching set of images for use in applications other than Stash that allow for multiple performer images, such as P-Vault.

Possible expansions on this system could include a full-length crop for head-to-toe images, more specifics for non-nude states (swimsuit/lingerie/casual/formal), and approximate release dates/years to allow users to sort by date. Many more recent uploads to the actress-images repo represent a slightly expanded 3Q crop with more specific guidelines for the model's positioning within the frame, which may or may not necessitate an additional category of 3Q+ or similar.

Standardization

Similar to other areas of stash-box, easily visible guidelines on relevant edit pages will greatly aid less experienced editors in conforming to established community standards. In this case, those guidelines would be clear definitions for the newly introduced terms above. This will require an agreed-upon level of standardization for these images to encourage consistency from performer to performer. Questions to consider while developing this standard:

• How specific should our standard be? The borrowed definitions above are fairly general, referencing vague areas like "about mid-thigh" for the bottom of 3/4 portraits. If a greater level of consistency is preferred, we would need to define the positioning of performers within the frame with more specificity. Providing image templates that include literal guidelines for each crop may be necessary.
• How big should the images be? This includes aspect ratio, resolution, and file size. The current standards for StashDB are laid out in our shared guidelines doc as a 2:3 ratio for vertical/portrait images, resolutions up to 666 x 1000, and file sizes of around 120-160 KB. The doc also notes that the "maximum size for images is 1280 pixels" and that anything larger will be "automatically reduced to that size." Images that are considered "low quality" in terms of content, resolution, or size are recommended to be deleted assuming higher quality images are available, though only a few specific examples of "low quality" are established. Including more "official" guidelines within StashDB itself would provide an opportunity to revise these standards if necessary. Images should be high enough in resolution and quality to meet most users preferences, but with file sizes small enough to not cause issues with hosting space in stash-box, inflated database sizes in stash, or slow loading speeds in a browser.
• How closely should our standard align with the actress-images repo? Their current standards are listed as 2:3 and "at least 1200px high" for vertical/portrait, 16:9 and 1280x720px for horizontal/landscape, around 350 kB maximum file size "though not at the cost of lower quality", and a recommended standard JPEG export described as "roughly 80% quality (very high)". However, more recent contributions to their repo are significantly higher than this standard, with some images at a resolution of 1275x1875 with sizes approaching 2 MB. Their minimum standards are already slightly higher than our maximum, so some compromise between the two standards may allow for a greater level of collaboration between the two projects.

Further Development

In addition to a more basic implementation of categories for performer images, more advanced features have been suggested:

• An image editor within the browser could allow users to conform to more specific standards without the need of advanced standalone software like Photoshop or GIMP. This embedded image editor could allow for basic operations like cropping the image with visible guidelines of the community-standard, downscaling or compressing to an acceptable size, and possibly even upscaling.
• If our standards are aligned closely enough with those of the actress-images repo, an automatic import process could be possible as well. Their file naming schema is specific enough to allow for parsing of the performer name, crop, pose, state of dress, and image set number. An automated system could theoretically detect additions to the repo, adjust the size of the new image if necessary, and submit it to the proper performer on stash-box for approval after assigning the relevant categories. If all images in stash-box are given a perceptual hash, it could detect duplicates that are already saved in stash-box as well. Then it could either submit the new image as a replacement or cancel the submission altogether as appropriate.

Is your feature request related to a problem?
Some of the scenes submitted by the democracy use the automatically generated thumbnails by stash, not the official thumbnail.

Describe the solution you'd like
Stash-box should detect that the thumbnail is bogus and remove it from the draft and warn the user that the thumbnail has been removed.