Skip to content

feat(settings): say what each column means, instead of mapping them - #6728

Open
viktormarinho wants to merge 1 commit into
mainfrom
feat/column-settings-ui
Open

feat(settings): say what each column means, instead of mapping them#6728
viktormarinho wants to merge 1 commit into
mainfrom
feat/column-settings-ui

Conversation

@viktormarinho

@viktormarinho viktormarinho commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

The screen this whole direction set out to remove — replaced, not deleted.

An org whose board is its own now sees its Jira columns in Settings → Tasks → Jira, with one question each: what does this mean to Studio? Options are "Nothing special" (the default), "Under review", and "Archive".

Most columns mean nothing, and leaving them that way is the answer — not a gap to fill. That is the whole difference from the mapping it replaces. The mapping asked a team to restate, lane by lane, something their tracker already knew, and every unmapped column was a silent hole. This asks the one thing Jira cannot tell us: which of their columns is where review happens, and which retires a card.

Same place in settings. The mapping is untouched for an org on Studio's board — its lanes are ours and Jira has no idea what they mean, so there is nothing to ask there.

This is the third of three UIs this work has owed. Automations (#6690) and the board mode (#6698) are still tool-only, and I would not call the debt cleared.

How did you verify your code works?

bun run check 0 errors — which also proves the pt-BR dictionary mirrors en, since the satisfies contract makes a missing key a compile error, and six new keys landed on both sides. bun run lint at baseline, knip clean, fmt:check clean.

apps/web/src/views + the board layout: 184 pass / 4 fail, identical to baseline measured by stashing and re-running. Those four (PublishPolicyField and neighbours) are the known order-dependent set at that scope.

Not verified, and this is the weak part of this PR:

  • No test at all for the new component, and no live browser check. Nothing here asserts that the rows render, that the select shows the current role, or that choosing one calls the mutation. A component test needs QueryClientProvider and ProjectContextProvider, which by this repo's own rule makes it e2e rather than unit — and there is no e2e for settings. So the honest position is: the types line up and the pieces it composes are each covered elsewhere, but this specific screen has been reasoned about, not exercised. It wants a look before anyone relies on it.
  • It reads the whole board via useTaskBoardItems to get the columns, because that read is the only source of a column's role. On a settings page that is heavier than it needs to be; it is cached and shared with the board itself, so the cost is usually zero, but a dedicated read would be cleaner.
  • No optimistic update. The mapping UI keeps a local copy to survive a slow round-trip; this one waits for the invalidation, so a slow save shows the old value briefly.
  • Only two roles are offered because only two exist. in_review is settable and still read by nothing (flagged in feat(task-board): let a column say what it means #6718) — so choosing it today records an intent that nothing acts on yet.

Screenshots/Demonstration

Not captured — see above. The visible change is the mapping table swapped for a column-and-role table, only for an org with org_board_columns on, of which there are none.

How to Test

  1. On any org today (flag off): Settings → Tasks → Jira shows the status mapping, unchanged.
  2. Turn org_board_columns on and sync so the columns exist. The same card should now read "What each column means" and list the Jira columns.
  3. Set one to "Archive" and confirm the archive sweep starts retiring cards there.
  4. Set it back to "Nothing special" and confirm it stops.
  5. Before the first sync, confirm the empty state reads "No columns yet".

Migration Notes

None. Client-only; the tool it calls shipped in #6718.

Review Checklist

  • PR title is clear and descriptive
  • Changes are tested and working
  • Documentation is updated (if needed)
  • No breaking changes

Summary by cubic

Replaces the Jira column mapping screen in Settings → Tasks → Jira with a per-column role picker, only for orgs whose board is their own. Most columns mean nothing to Studio, and "Nothing special" is now the honest default instead of a silent unmapped gap.

  • Each Jira column gets a select: Nothing special (default), Under review, or Archive.
  • The old mapping stays untouched for orgs on Studio's board.
  • Adds useSetColumnRole, which calls TASK_BOARD_COLUMN_ROLE_SET and invalidates the shared board read.
  • New labels landed in en and pt-br, covered by the existing satisfies contract.
  • No migration needed — client-only.
  • The new component has no test and got no live browser check; the pieces it composes are covered elsewhere, but this screen is reasoned about, not exercised.
  • No optimistic update — a slow save shows the old value briefly.
  • in_review is settable but nothing reads it yet, so choosing it records intent nothing acts on.

Written for commit 2070687. Summary will update on new commits.

Review in cubic

The screen this direction set out to remove, replaced rather than deleted.

An org whose board is its own now sees its Jira columns with one question each:
what does this mean to Studio. Most mean nothing, and leaving them that way is
the answer rather than a gap to fill — which is the whole difference from the
mapping it replaces. That asked a team to restate, lane by lane, something
their tracker already knew; this asks the one thing it cannot know.

Same place in settings, and the mapping is untouched for an org on Studio's
board: its lanes are ours and Jira has no idea what they mean, so there is
nothing to ask there.

Third of the three UIs this work has owed. Automations and the board mode are
still tool-only.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant