Filed on behalf of @jeff363b, from his comment on #719:
Just curious, is there a plan to show the custom fields on the data card when viewing the data? Right now, I have to go into edit to see what it is. No biggie, just wondering
Splitting it out so it is on the backlog rather than at the end of a closed bug thread. It is the natural follow-up to #739, which built custom fields in 26.9.98.
What problem does this solve?
Custom fields shipped with everything except a way to read them. A value can be filtered on in advanced search, sorted on in the wide list view, and exported — but on the one screen dedicated to a single film, it is not there. Seeing what a film's "shelf" or "rip status" says means opening the edit form, which is a writing surface: you enter it to change something, and leaving it is a decision about whether to save.
That is backwards for the field's most common use. A custom field exists because its owner wants to know something about a film; the film's own page is where they look.
Proposed solution
A custom-fields section on the film detail page, beside the fields DiscVault defines itself.
Everything needed is already on the wire: the definitions arrive on the dashboard snapshot as customFields, and the values arrive on the detail payload as movie.custom_values. No new endpoint, no new request.
Points that need deciding rather than assuming:
- Where. The Collectors tab holds the owner-managed facts (location, storage location, edition), which is what a custom field is. The alternative is a section of its own.
- Empty state. A film with no value for a field should show nothing rather than a row saying nothing — and an instance with no fields defined should show no section at all.
- Archived fields. An archived definition keeps its values and keeps them matching in filters (contract §4e.5), so a value on an archived field has to stay readable here. That is the opposite of the edit form, which filters archived fields out because they take no new input.
- Ordering. The owner's own order from Admin → Custom fields, which the server already returns.
- Labels are not translated. The owner typed them.
Alternatives considered
Leaving it as it is and reading values in the edit form, which is what happens today. It works, but it makes reading a value an act of opening a form you then have to decide how to close.
Which platform is this for?
PWA (browser) first. The iOS and Android apps model custom fields as sync entities but show nothing yet; whatever is decided here is the reference for them.
How important is this to you?
Recorded as "nice to have some day" — Jeff framed it as a wondering rather than a blocker. He can correct that below.
Additional context
Related and separate: #761 fixes a defect found while looking at this — the edit form read the values from a key the API never sends, so saving a film erased its custom values. That has to land first, or this feature would put values on screen that the next save deletes.
Filed on behalf of @jeff363b, from his comment on #719:
Splitting it out so it is on the backlog rather than at the end of a closed bug thread. It is the natural follow-up to #739, which built custom fields in 26.9.98.
What problem does this solve?
Custom fields shipped with everything except a way to read them. A value can be filtered on in advanced search, sorted on in the wide list view, and exported — but on the one screen dedicated to a single film, it is not there. Seeing what a film's "shelf" or "rip status" says means opening the edit form, which is a writing surface: you enter it to change something, and leaving it is a decision about whether to save.
That is backwards for the field's most common use. A custom field exists because its owner wants to know something about a film; the film's own page is where they look.
Proposed solution
A custom-fields section on the film detail page, beside the fields DiscVault defines itself.
Everything needed is already on the wire: the definitions arrive on the dashboard snapshot as
customFields, and the values arrive on the detail payload asmovie.custom_values. No new endpoint, no new request.Points that need deciding rather than assuming:
Alternatives considered
Leaving it as it is and reading values in the edit form, which is what happens today. It works, but it makes reading a value an act of opening a form you then have to decide how to close.
Which platform is this for?
PWA (browser) first. The iOS and Android apps model custom fields as sync entities but show nothing yet; whatever is decided here is the reference for them.
How important is this to you?
Recorded as "nice to have some day" — Jeff framed it as a wondering rather than a blocker. He can correct that below.
Additional context
Related and separate: #761 fixes a defect found while looking at this — the edit form read the values from a key the API never sends, so saving a film erased its custom values. That has to land first, or this feature would put values on screen that the next save deletes.