[Feature] Custom performer fields

[QxxxGit]

Is your feature request related to a problem? Please describe.
Sometimes I want to provide more information on a performer (i.e. OnlyFans or Patreon links).

Describe the solution you'd like

• A setting page where you configure your custom performer fields.
• On this page, you can create a name for the field and the expected data type (i.e. text, link, or number).
• These custom fields would then appear on the 'details' panel for the performer page. For cleanliness, these fields would probably sit under a 'Custom Fields' header underneath the Instagram field.
• These fields could be used within the filter to find a performer.

Describe alternatives you've considered

• A note textarea, though this wouldn't be super valuable for filtering.
• Customization for all objects (scenes, movies, images, etc.) using the solution I provided above. It would be much more work but would cut down on future requests for specific fields.

[raunmorgan]

I think this is an excellent suggestion. The performers page is very rigid and could be expanded and enhanced much better.

[JennaDiamonds]

Great suggestion. My OCD would love to be able to add more to the details pages

[echo6ix]

Also let the user specify what genders the custom field is applicable too.

[echo6ix]

On this page, you can create a name for the field and the expected data type (i.e. text, link, or number).

Just wanted to add, the last I used PornVault, they had the option for custom fields and expected data type like this. I think you could even go as far as defining what those data value options were if the custom field was a drop down form.

[Nalla22]

Thank you for putting this feature up on stash, it is very important.

[ovladuk]

so this was posted 2 years ago. is this feature on the app?

[PorkenPig]

No unfortunately not that I can see. Sent from ProtonMail for iOS

…

On Wed, May 25, 2022 at 4:02 PM, ovladuk ***@***.***> wrote: so this was posted 2 years ago. is this feature on the app? — Reply to this email directly, [view it on GitHub](#885 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVC6ARFEPXYHX3DZBJ2ADJDVL2WQVANCNFSM4S4J7MJA). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ovladuk]

No unfortunately not that I can see. Sent from ProtonMail for iOS
…
On Wed, May 25, 2022 at 4:02 PM, ovladuk @.> wrote: so this was posted 2 years ago. is this feature on the app? — Reply to this email directly, [view it on GitHub](#885 (comment)), or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.>

do you know of any other apps that you can add custom fields to?

[KamillaPup]

Just an ups for this. It would also be nice to set if we want metric or imperial measurements. Many porn sites are in the US and list details in imperial.

Also instead of birthdate, age would be nice. Many porn sites don't share such specific info on their performers.

[AdultSun]

An issue with "age" is that it's a moving target, which is why tracking birthdates and using those to calculate ages instead makes more sense. I think the solution there would to instead allow the birthdate field to be approximate, meaning just save YYYY or just save YYYY-MM. Incomplete dates are already possible in Stash-Box, so I expect we'll eventually want Stash to work the same way. But that topic's really grounds for a separate Issue, I haven't checked if someone's made it already but it's at least come up before.

[PorkenPig]

No unfortunately not. It’s sad but this app is the closest I know of that is LGBT+ friendly can’t even get a proper male measurements field. Sent from ProtonMail for iOS

…

On Wed, May 25, 2022 at 4:21 PM, ovladuk ***@***.***> wrote: > No unfortunately not that I can see. Sent from ProtonMail for iOS > […](#) > On Wed, May 25, 2022 at 4:02 PM, ovladuk @.> wrote: so this was posted 2 years ago. is this feature on the app? — Reply to this email directly, [view it on GitHub]([#885 (comment)](#885 (comment))), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVC6ARFEPXYHX3DZBJ2ADJDVL2WQVANCNFSM4S4J7MJA). You are receiving this because you are subscribed to this thread.Message ID: @.> do you know of any other apps that you can add custom fields to? — Reply to this email directly, [view it on GitHub](#885 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVC6ARFA3LJ4OST2SUK6BFTVL2YY5ANCNFSM4S4J7MJA). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Dark-kn1ght]

I would love to see custom fields for pretty much everything, not just studios/performers, scenes and images too, that would make it easier to adapt Stash to non-traditional collections (like furry or hentai)

[xx790]

For a mixed collection I figured I'd like to have different sets of fields defined by the kind of entry.
For example, live performers and fictional characters would have different sets of fields.
Thinking about how it could be implemented, I can only conclude that it has to be closer to some kind of booru/wiki - (almost) everything could be tags. Specialization of certain tags can be achieved through namespaces - performer namespace for performer tags, character namespace for character tags, studio namespace for studio tags... Namespace defines custom fields for its tags among other things.

[KamillaPup]

I would think it would be so easy...at least let us rename the fields. The fact there's a field called "fake tits" is pretty cringe. It's not even a true/false toggle.

This app could be something amazing but making tags booru style would be a nightmare and the complexity would scare others away.

Just let us add fields and define if they're numerical, integer, short text, long text, true/false, or drop-down.

[xx790]

I think it can be done elegantly and without sacrificing user experience.
The bigger issue might actually be on the other end - the rigidity of GraphQL API is what more likely to stand in the way.

[echo6ix]

Adding these Discord posts here per WithoutPant's request.

This post was in response to the idea of making certain core fields (breast type, penis fields, etc) available only to specific genders.

If the implementation of custom fields is part of future plans, I presume the user setup of said fields would involve something like a dropdown checklist to determine the fields availability to specific genders? In this case, I would recommend making such a settings option available for some of the core fields too (penis*, breast type, body shape measurements, the rest are gender agnostic). The availability of the incumbent Stash core fields remain as they are, with no assumptions to where they belong, and users have the flexibility to customize what genders they are available to. This approach absolves the devs to ever address any concerns related to gender specific fields.

To elaborate on my reasoning, specifics about gender is widely debated in the public sphere. It evokes strong emotions from various individuals (but we can avoid any of that drama). Assigning specific genital/breast attributes to a particular gender could potentially spark unnecessary debate and consume dev resources when addressing/fixing such matters. For example, it is possible that some may prefer to classify transgender women as female but still have access to the fields related to male anatomy. Therefore, my approach aims to prevent potential complications by granting users the flexibility to control the gender availability of a few core fields.

[xx790]

Oh god why

More fields I don't care about are introduced in 0.21.0 and still no official way to deal with it.

[WithoutPants]

Proposed Design

Requirements

• support reading and writing of custom fields (on all top-level object types)
• support simple filtering on custom field values

Assumptions

• plugins will customise the display of custom fields,
• users will primarily interact with custom fields through the user of plugins

Graphql interface design

Add custom_fields: Map! to top-level objects. Map is a javascript object on the client side. All custom field values will be included in this map.

Create and update inputs will accept a CustomFieldsInput input type - with field name custom_fields:

input CustomFieldsInput {
  full: Map
  partial: Map
}

If the full field is populated, then all existing custom fields are replaced with the values of the provided field. If partial is populated, then only keys provided in the map will be created/updated and existing missing keys will be left unchanged.

Bulk update interfaces will also include the ability to set custom fields, using the above input logic.

FilterType inputs will be changed to accept an array of CustomFieldFilterInput values in the custom_fields field. The specification of CustomFieldFilterInput is as follows:

input CustomFieldFilterInput {
  field_name: String!
  modifier: CriterionModifier!
  value: [Any!]!
}

Database schema design

Custom fields will be stored in a table per object type. The following is the expected table creation script for performer custom fields:

CREATE TABLE `performers_custom_fields` (
  `performer_id` integer NOT NULL,
  `field` varchar(255) NOT NULL,
  `value` BLOB NOT NULL,
  PRIMARY KEY (`performer_id`, `field`)
);

Display of custom fields in the core UI

Custom fields will shown behind a collapsible header - which is collapsed by default - showing values in key/value pairs.

Custom fields will be able to be edited behind a collapsible header in the edit panels. Custom fields will be shown in rows of field and value - both of which will be displayed as a text field. A delete button will be shown for each custom field, and a button to add new field/value pairs will be available.

Filtering in the core UI will be by selecting the custom field filter option, which will allow for entry of the field name, a filter modifier and field value.

[miltuss]

I would like custom forms to only display if I have selected a specific Tag. Would it be possible to add a condition for the display of personalized forms?

[WithoutPants]

I would like custom forms to only display if I have selected a specific Tag. Would it be possible to add a condition for the display of personalized forms?

That would be out of scope for the core functionality, but the goal will be to enable something like this fairly easily via plugin.

[QxxxGit]

Seems mostly fine but I'm unsure of the filtering due to a lack of data type specificity. If a user wants a custom field based on dates, it would be ideal to support it with the date tools. Similarly, filtering based on numerical ranges.

Filtering in the core UI will be by selecting the custom field filter option, which will allow for entry of the field name, a filter modifier and field value.

If data types were to be supported like above, I imagine just using the field name as a drop down amongst the other filter options would work, and based on the data type it would provide the correct tooling.

[WithoutPants]

Seems mostly fine but I'm unsure of the filtering due to a lack of data type specificity. If a user wants a custom field based on dates, it would be ideal to support it with the date tools. Similarly, filtering based on numerical ranges.

Including types in this iteration significantly expands the complexity and design scope. I would rather start with a simple solution that we can expand on/rework as the requirements emerge from use.

[miltuss]

It would be wise if the user could create personalized fields with a semi-automatic drop-down menu to select data (performers, studios, scenes, etc.) as he does with tags. This will allow selection of values ​​by identifiers as with tags, and plugins will be able to rely on these values ​​reliably to identify Stash elements.