On hold. Filed for the record during a manual UI pass; it should not be picked up until videocore:latest has been promoted to stable.
Problem
The assets table's columns are fixed. An operator cannot choose which are shown, and the set is defined in code (public/assets-table.js, the column array beginning around :350): thumbnail, ID, title, status, size, dates, actions.
Requested by the product owner during testing: which columns are shown should be editable.
Why it matters
Different jobs want different columns, and the table is the primary working surface:
There is already machinery to build on: sort, filter and pagination state is persisted in the URL via public/table-url-state.js (#368/#373), and the shared table primitive in public/ops-ui-table.js is used by the assets, jobs and logs tables alike.
Proposed change
A column chooser on the assets table, and — because the primitive is shared — ideally on the jobs and logs tables for free.
Worth deciding while implementing:
- Where the preference lives. URL state makes a configured view linkable and shareable, consistent with how sort and filter already behave.
localStorage makes it sticky per operator. They are not exclusive: URL wins when present, otherwise fall back to the stored default.
- What cannot be hidden. The actions column, and probably one identifying column, should be pinned so the table cannot be made useless.
- Additional columns worth offering, beyond hiding existing ones:
slug, id, rendition count, review state, tags.
- Reset to defaults, so an operator can always get back to a known state.
Acceptance criteria
- An operator can show and hide columns on the assets table.
- The choice persists across a reload.
- A configured view can be shared (or the decision to make it operator-local is recorded deliberately).
- Actions and at least one identifying column cannot both be hidden.
- Sort, filter and pagination continue to work against a customised column set.
How to verify
Hide a column, reload, and confirm it is still hidden. Share the URL (if URL-persisted) and confirm the recipient sees the same view.
Context
Requested during a manual UI pass, alongside #851 (the ID column shows the slug — the proposed fix there adds an ID column with a copy button and a separate Slug column, which increases the column count and makes choosing between them more useful).
Problem
The assets table's columns are fixed. An operator cannot choose which are shown, and the set is defined in code (
public/assets-table.js, the column array beginning around:350): thumbnail, ID, title, status, size, dates, actions.Requested by the product owner during testing: which columns are shown should be editable.
Why it matters
Different jobs want different columns, and the table is the primary working surface:
There is already machinery to build on: sort, filter and pagination state is persisted in the URL via
public/table-url-state.js(#368/#373), and the shared table primitive inpublic/ops-ui-table.jsis used by the assets, jobs and logs tables alike.Proposed change
A column chooser on the assets table, and — because the primitive is shared — ideally on the jobs and logs tables for free.
Worth deciding while implementing:
localStoragemakes it sticky per operator. They are not exclusive: URL wins when present, otherwise fall back to the stored default.slug,id, rendition count, review state, tags.Acceptance criteria
How to verify
Hide a column, reload, and confirm it is still hidden. Share the URL (if URL-persisted) and confirm the recipient sees the same view.
Context
Requested during a manual UI pass, alongside #851 (the ID column shows the slug — the proposed fix there adds an ID column with a copy button and a separate Slug column, which increases the column count and makes choosing between them more useful).