Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performer custom fields #5487

Open
wants to merge 16 commits into
base: develop
Choose a base branch
from

Conversation

WithoutPants
Copy link
Collaborator

Adds custom_fields field to performers.

In graphql, performer create mutation, the custom_fields field accepts an object value. For performer update mutation, the custom_fields field accepts either a full value or a partial value. The full value performs a full replacement of existing custom fields, whereas partial will only replace values provided in the input value.

Custom fields may currently be either strings or numeric values. JSON objects or arrays are not accepted.

In the UI, custom fields are hidden behind a collapse button and are only shown in the expanded view:
image

In the new/edit performer views, custom fields are hidden behind a collapse button:
image

Filtering is available in the graphql interface, but is not currently implemented in the UI. This may be added in this or a separate PR.

Custom fields will be added to other object types in future.

@WithoutPants WithoutPants added the feature Pull requests that add a new feature label Nov 20, 2024
@WithoutPants WithoutPants added this to the Version 0.28.0 milestone Nov 20, 2024
@DogmaDragon DogmaDragon linked an issue Nov 21, 2024 that may be closed by this pull request
@Maista6969
Copy link
Contributor

These were reported by Tweeticoats and kanaza on Discord but I'm repeating them here for posterity:

does not work on a brand new instance creating a new performer with nothing configured

performerCreate: input: performerCreate getting SQL value for field "full": unsupported custom field value type: map[string]interface {}
  • if a value has been set once, you can't go back to an empty string (it defaults to "0")
  • in that case it's also no longer possible to enter dots "."

In my own testing I've found that the CSS class names for custom fields will probably need another pass as well: I created a field called "Maiden name" and it's getting the class detail-item-title custom-field-Maiden name.

One of the reasons I tested this is because I imagine that people who want custom fields might value them highly enough that they'd want to use custom CSS to change their display order, maybe even placing them above the regular fields. I'm no CSS wizard, but would the current implementation with the extra div also get in the way of that goal?

@randemgame
Copy link
Contributor

randemgame commented Nov 23, 2024

Hey, I'm testing this right now and it's looking good. I got inspired with how these fields were being added and was thinking how they could be utilised to track the historical changes of performers (and other types) according to user activity. I think I could probably make a plugin that could write certain events from logging or other detection to this table. If WP thinks this could be part of core functionality, I could work on implementing it with some assists.

Perhaps it would be worth including an additional, optional , field to the custom_fields table for categorisation? It is not necessary for the above, but would make things cleaner. I was just inspired in one direction and thought there could be other cases where an optional field here could be useful. In a future-proofing sense, especially if other object types will eventually have a similar functionality.

Here's an example of how that additional field could look like from the SQL DB and how the historical data could look from the DB :
table: performer_custom_fields
performer_id, field, [NEW! Category], value

4953, Pnalike, [User Field], Princess D*a
4953, Rating, [User Field], 8.7

4952, Birthplace, [Scraped from pedia], Massapequa
4952, Instagram Followers, [Scraped from *], 105K

table: performer_custom_fields
performer_id, field, [NEW! Category], value

4953, **** alike, [User Field], Princess D****
4953, **** Rating, [User Field], 8.7

4952, Birthplace, [Scraped from ****pedia], Massapequa
4952, Instagram Followers, [Scraped from *****], 105K

4953, 2004-11-26 14:56, [Automated History], Piercings updated from 'Stash DB' to 'left nostril; Navel'
4953, 2004-11-23 10:01, [Automated History], User Tag added '**** Goat'
4953, 2004-11-21 08:00, [Automated History], 'Example Film X', 'Example Film Y' and 'Example Film Z' added to library
4953, 2004-11-23 10:00, [Automated History], Performer Rating increased from 4.3 to 4.4
4953, 2004-11-23 10:00, [Automated History], Performer Rating increased from 4.3 to 4.4
4953, 2004-11-20 23:59, [Automated History], 'Example Film' Rating increased from 3.7 to 4.1
4953, 2004-11-20 23:59, [Automated History], O-Count increased from 4 to 5 for 'Example Film'
4953, 2004-11-20 23:59, [Automated History], 'Example Film' watched for 56:43:23 (Total Play Duration 7:39:53) on StashAppAndroidTV
4953, 2004-11-20 23:23, [Automated History], Play Count increased from 6 to 7 for 'Example Film' on StashAppAndroidTV

cross-posted to Discord https://discord.com/channels/559159668438728723/642079454054711306/1309991781412114513

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Pull requests that add a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Custom performer fields
3 participants