Open WithoutPants opened 5 days ago
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?
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
Adds
custom_fields
field to performers.In graphql, performer create mutation, the
custom_fields
field accepts an object value. For performer update mutation, thecustom_fields
field accepts either afull
value or apartial
value. Thefull
value performs a full replacement of existing custom fields, whereaspartial
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:
In the new/edit performer views, custom fields are hidden behind a collapse button:
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.