Page MenuHomePhabricator

Add a discoverable 'New column' button at the end of the table (!49)
Closed, ResolvedPublic

Description

Scope: Surface "add a column" as a discoverable, intuitive button at the end of the table — adding a column is currently buried inside the "Templates and columns" modal toolbar button, where most users never look.

What's wanted:

  • A full-height vertical button at the end of the visible columns (after the last data column, in the spot where a *future* column would land), so the affordance literally sits at the position of the future column.
  • Click it → small popover offering the most-relevant column choices directly:
    1. Quick-add list: a short list of currently-hidden built-in columns that most users want to surface, each clickable to enable in one click. Suggested seed list: Source, Original filename, Lens, Focal length, Date taken, Camera location, Object location, Location of creation (P1071) (filtered to those not already visible).
    2. Add Wikidata property as column: inline search input mirroring the existing autocomplete in ColumnMenu (currently dead code — see below), powered by window.KNOWN_PROPERTIES and (live) loadVocabPropertiesByQuery. Picking a result calls the same addCustomProp path the Templates-and-columns modal uses today.
    3. Add custom wikitext-template column: a link/button that dispatches into the existing CustomColumnCreator flow — easiest route is to open the Templates-and-columns modal at the Columns tab with the custom-column form auto-expanded.
    4. More options → link to open the full Templates-and-columns modal (so power users still have the full surface available).

Where in the code:

  • src/table.jsx:711–843 renders the table. The header row already terminates with <div className="tbl__th tbl__th--actions" /> (table.jsx:802) — that's where the new column button anchors.
  • src/table.jsx:497–503 builds gridTemplate. The new button cell needs to be added there (or rendered as a sticky/separate element, see UX note below) and in the head row + each Row.
  • src/table.jsx:455–493 already exposes addCustomProp(p) and addTemplateColumn(label, template) and the surrounding setColState mechanics — the new button just dispatches into them.
  • src/table.jsx:4635–4738 defines ColumnMenu (Wikidata-property autocomplete). It's currently dead code (rendered nowhere). The new popover can either reuse it or copy its property-search pattern.
  • src/columns-modal.jsx:332–422 defines CustomColumnCreator — keep using it via the modal route.
  • src/table.jsx:845–883 mounts the ColumnsModal driven by colMenuOpen (false | 'columns' | 'templates'). Easiest dispatch for "open columns modal" is setColMenuOpen('columns').

Acceptance criteria:

  • A visible button labelled something like "+ Add column" appears at the right end of the visible-columns block in both the stash table and the history table, and inside Groups view's per-group mini-tables (or the toolbar above them — see open question below).
  • The button visually reads as a column-shaped affordance (full row-block height, vertical orientation acceptable; doesn't collide with the existing per-column resize handle on the rightmost column).
  • Clicking it opens a popover anchored to the button.
  • The popover contains: (a) the quick-add list of currently-hidden default-most-relevant columns, (b) Wikidata property search, (c) "Custom wikitext-template column" entry-point, (d) "More options →" link to the full Templates-and-columns modal.
  • All add-paths persist correctly (verified by reload — the colState save flow already covers visible, order, customProps).
  • Existing "Templates and columns" toolbar button keeps working unchanged.
  • npm run build passes (the undefined-identifier scanner runs first).
  • Manual test in npm run dev: open dev server, click the new button, exercise each of the four affordances, reload, confirm columns persist.

Notes / non-goals:

  • The columns-modal's "Add custom wikitext-template column" UX stays the source of truth for the inline form — the button just needs to surface it earlier in the discovery path. No need to reimplement a parallel form inline in the popover (premature; the existing one is good).
  • Dead-code ColumnMenu in table.jsx:4635–4738 can either be wired into this popover (if its UX matches) or left alone for now — out of scope to delete it.
  • Mobile: the table is already horizontally scrollable on small screens, so the button-at-end-of-columns position works for mobile too (you scroll right to reach it). No special mobile pattern needed.

Refs:

  • Template / columns infrastructure: src/columns-modal.jsx, src/wikitext-templates.js
  • Vocab pools: src/vocabulary.js (window.KNOWN_PROPERTIES)
  • Persistence: localStorage key stashhub.columns.v10, user-store Preferences.json (customProps)

Event Timeline

Daanvr moved this task from To do to Doing on the Tool-upload-workbench board.

Grooming pass (AI)

Description rewritten with investigation findings (see task description above). Original preserved here verbatim:

The possiblity to add a new column is now hidden in "Templates and columns" this is not obvious for most users.lets add a button at the end of the table to add a column helping the user to know this is possible. I sould look very intuitive. a ful hight button that has the position of the future column. a simple drop down with the default most relevant columns and an option to add a custom column based on specific wikitext or SDC properties.

Daanvr renamed this task from New column button to Add a discoverable 'New column' button at the end of the table.Fri, May 15, 3:56 PM
Daanvr updated the task description. (Show Details)
Daanvr renamed this task from Add a discoverable 'New column' button at the end of the table to Add a discoverable 'New column' button at the end of the table (!49).Fri, May 15, 4:13 PM
Daanvr moved this task from Doing to Reviewing on the Tool-upload-workbench board.

it works but when i add a new SDC column it is shown as dark grey meaning it is not possible to edit it. that is incorrect and should be fixed.

Addressed feedback on !49: Wikidata-property columns added via the new "+ Add column" popover (or via the Templates-and-columns modal) are now editable.

What changed:

  1. table.jsx:getAllColumns — drops the kind-ternary on editable/immutable/copyable/tone/sortable for customProp columns. Both kinds now: editable: true, copyable: true, sortable: true, no tone: "exif", no immutable: true. The disabled-grey rendering came from immutable: true (Codex disabled-subtle background + disabled text color).
  2. table.jsx:CellEditor — broadens the customProp branch from kind === "template" to any customProp; both kinds use TextEditor and persist into item.customProps[pid].
  3. table.jsx:CellView — empty-cell placeholder reads "Add value" / "—" for both kinds (was "—" only for non-template).
  4. columns-modal.jsx:DefaultCell — allows a default value for any customProp (was template-only).
  5. user-store.js:DRAFT_FIELDS — adds customProps so user-typed values survive a reload via the wiki user-store, like every other editable cell. (Also fixes the same gap for existing template-column values.)

Verification:

  • npm run build clean (incl. undefined-identifier scanner).
  • Confirmed deployed bundle at https://upload-workbench.toolforge.org/mr-49/assets/index-BxObh17Y.js contains editable:!0,copyable:!0 for customProp columns and customProps in DRAFT_FIELDS.
  • Two remaining kind === "template" checks in the bundle are intentional: (a) columns-modal.jsx CompactRow/ExpandableRow badge ("Template" vs "Custom"), (b) app.jsx publish-time filter (only template-kind props get wikitext-substituted at publish).

Not in scope: SDC write-through at publish for arbitrary properties — typed values persist on the file draft but aren't yet emitted as wbeditentity claims. Existing publish flow still only handles hard-coded P180/P625/P1071/P571/P170. That's a follow-up.

New commit pushed to feat/T426421-new-column-button (e0d9d77); preview redeployed at /mr-49/.