stashapp / stash

An organizer for your porn, written in Go. Documentation: https://docs.stashapp.cc
https://stashapp.cc/
GNU Affero General Public License v3.0
8.76k stars 778 forks source link

[Feature] Custom performer fields #885

Open QxxxGit opened 3 years ago

QxxxGit commented 3 years ago

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

Describe alternatives you've considered

raunmorgan commented 3 years ago

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

JennaDiamonds commented 3 years ago

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

echo6ix commented 3 years ago

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

echo6ix commented 2 years ago

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 commented 2 years ago

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

ovladuk commented 2 years ago

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

PorkenPig commented 2 years ago

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, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

ovladuk commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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)), 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?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Dark-kn1ght commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 3 weeks ago

Proposed Design

Requirements

Assumptions

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.