web(views): the group-by picker lists every field and says why one can't be used (#225) - #330
Merged
Merged
Conversation
… finally submit multi-select (#303) The PUBLIC form at /f/:token was a THIRD hand-rolled copy of field rendering (after table cells and the authenticated form-view), and it hid a functional bug: select + multi_select shared ONE native <select>, so multi_select did onChange([e.target.value]) — every pick REPLACED the array. A public form could never submit more than one value for a multi-select field. Now the two are separate branches, both rendering the shared `OptionChip` via a thin `PublicOptionToggle` wrapper (the chip is never redrawn here), and multi_select toggles into the array. `workflow` is folded in with `select` — omitting it is the exact recurrence #272 keeps producing. API: the public definition now carries each option's `color` and `icon`. Those are workspace SCHEMA, so they're safe on an unauthenticated payload. NOT included, deliberately — avatars. Rendering them would mean putting member photo URLs into an endpoint anyone with the link can read, and the existing code withholds them on purpose ("id + name only (no PII)"). That's a privacy decision for the founder, not a styling choice, so the person picker keeps names only here while the AUTHENTICATED form (#328) gained avatars. Test locks BOTH halves: option colours must arrive, and each member object must still be exactly {id, name} with no email anywhere in the payload — a "test what it must keep OUT" assertion for a public endpoint. Verified: full API suite 1822 passed / 187 files (only backup-restore.test.ts fails — needs Docker, documented); lint, typecheck, build green; no SDK drift. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…n't be used (#225) Acceptance criterion 6 of #225, and the cheapest fix for the confusion that produced #267 and #272: a picker that silently omits a field is indistinguishable from a bug. Both tickets were filed as "State is missing" — the reporter had no way to tell "deliberately excluded" from "broken". Every field now appears. Ungroupable ones are `disabled` with the reason inline: Assignees — a multi-person field would put one card in several columns Tags — a multi-select would put one card in several columns Due date — date grouping (by week/month/quarter) is not built yet Estimate — number grouping (into bins) is not built yet Progress — computed fields cannot group a board yet The wording distinguishes CAN'T-WORK (multi-value: a card can't live in two columns) from NOT-BUILT-YET (date/number/computed), so the picker doubles as an honest roadmap instead of looking arbitrary. On a List, a field a BOARD could group says "try a board" rather than a dead end. Reasons live beside the predicates in groupable-fields.ts — same module, so a capability and its explanation can't drift apart either. 6 new unit tests (24 total in this file), including one that walks a range of field types asserting every ungroupable field returns SOME reason — no empty labels. Does NOT implement date/number/computed grouping. That is the rest of #225 and is being decomposed into its own tickets. Verified: lint, typecheck, build; web suite 491 passed / 35 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
storyos-docs | d2af4ac | Commit Preview URL Branch Preview URL |
Aug 12 2026, 10:11 PM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Acceptance criterion 6 of #225 — "Show all fields in the group-by picker; grey out
unsupported ones with an explanation."
Why this one first
A picker that silently omits a field is indistinguishable from a bug. #267 and
#272 were both filed as "State is missing from the picker" — and the reporter was
right to file them, because there was no way to tell a deliberate exclusion from a
broken one. This makes the difference visible.
What you'll see
Assignees — a multi-person field would put one card in several columnsTags — a multi-select would put one card in several columnsDue date — date grouping (by week/month/quarter) is not built yetEstimate — number grouping (into bins) is not built yetProgress — computed fields cannot group a board yetThe wording deliberately separates can't-work (multi-value: one card can't live
in two columns — a real constraint, mirrored by the API's
boardGroupError) fromnot-built-yet (date / number / computed). So the picker reads as an honest
roadmap rather than an arbitrary allowlist.
On a List, a field a board could group says "try a board" instead of a dead
end.
Reasons live in
groupable-fields.tsbeside the predicates they explain — samemodule, so a capability and its explanation can't drift apart the way the
capability and its pickers did.
Not in this PR
Date bucketing, number bins, and computed-field grouping — the substantive parts of
#225. Being decomposed into their own tickets; #225's seven criteria are a multi-day
feature and Fibery's own staff called the date/text case "trickier than sounds".
Verification
types asserting every ungroupable field returns some reason — no field can
ever render as a bare disabled label with no explanation.
pnpm lint,pnpm typecheck,pnpm buildgreen; web suite 491 passed / 35 files.apps/web) — worth one look: New view → Board→ open Group by, and check the disabled entries read sensibly.
🤖 Generated with Claude Code