Jobs: the Who, When and Worth pickers

nalum commented

2026-08-23 19:46:04 +00:00

Owner

Part of the jobs flow redesign. The design handoff (design_handoff_jobs_flow, held outside the repo) is the source; the facts it depends on are repeated here so this issue stands alone.

Three pickers behind the sheet's three chevrons. Who and Worth share one component; When is its own.

Who — one row per household member at 56px, then Anyone with the line Falls to you if nobody takes it. Commits and closes on tap. No search and no A-Z; a household is four people.

When — day chips first, then a 7-column month grid at 44px cells, then a Time row. This picker confirms, because the date and the time are two decisions. The footer button states the outcome (Due Tuesday 09:45). Today is ringed and the selection is filled — two different marks. Leading days of the previous month are blank cells, never grey numerals.

Worth — eligible rewards, then Make a new one and Worth nothing. Eligibility is stricter than it looks and depends on the Who row, so the list re-filters when the owner changes (internal/domain/reward.go:107-126):

unclaimed, REWARD_TYPE_POINTS, not already on an item;
a reward already granted to a person links only to a job owned by that same person, and is refused outright on an unowned job (ErrBountyMustBeUnassigned);
never on an item in a list. The jobs flow cannot reach that case, but the server guard stays.

web/src/pages/Jobs.tsx:69-78 already holds the correct predicate. Use it; do not write a second definition of eligible.

Make a new one asks for an amount and names the reward after the job. Authoring a full reward stays on the rewards surface.

Update — #183 is closed: creating a reward inside the job stays

I think we should keep the ability to create a points reward within the job,
it's a nice convenience that we already ship.

So Make a new one stays inside the Worth picker, asking for an amount and
naming the reward after the job — the picker links, and this one shortcut also
authors. The shipped changeRewardValue affordance stays on the job sheet for
the same reason: it is a convenience the household already has, and removing it
to satisfy a boundary would be a regression.

Both remain gated on the permission matrix: RewardService.Create and Update
are Admin and Member only, so a Child sees neither.

Part of the jobs flow redesign. The design handoff (`design_handoff_jobs_flow`, held outside the repo) is the source; the facts it depends on are repeated here so this issue stands alone. Three pickers behind the sheet's three chevrons. Who and Worth share one component; When is its own. **Who** — one row per household member at 56px, then `Anyone` with the line `Falls to you if nobody takes it`. Commits and closes on tap. No search and no A-Z; a household is four people. **When** — day chips first, then a 7-column month grid at 44px cells, then a `Time` row. This picker confirms, because the date and the time are two decisions. The footer button states the outcome (`Due Tuesday 09:45`). Today is ringed and the selection is filled — two different marks. Leading days of the previous month are blank cells, never grey numerals. **Worth** — eligible rewards, then `Make a new one` and `Worth nothing`. Eligibility is stricter than it looks and **depends on the Who row, so the list re-filters when the owner changes** (`internal/domain/reward.go:107-126`): - unclaimed, `REWARD_TYPE_POINTS`, not already on an item; - a reward already granted to a person links only to a job owned by that same person, and is refused outright on an unowned job (`ErrBountyMustBeUnassigned`); - never on an item in a list. The jobs flow cannot reach that case, but the server guard stays. `web/src/pages/Jobs.tsx:69-78` already holds the correct predicate. Use it; do not write a second definition of eligible. `Make a new one` asks for an amount and names the reward after the job. Authoring a full reward stays on the rewards surface. --- ## Update — #183 is closed: creating a reward inside the job stays > I think we should keep the ability to create a points reward within the job, > it's a nice convenience that we already ship. So `Make a new one` stays inside the Worth picker, asking for an amount and naming the reward after the job — the picker links, and this one shortcut also authors. The shipped `changeRewardValue` affordance stays on the job sheet for the same reason: it is a convenience the household already has, and removing it to satisfy a boundary would be a regression. Both remain gated on the permission matrix: `RewardService.Create` and `Update` are Admin and Member only, so a Child sees neither.

nalum added the

enhancement

android

web

labels

2026-08-23 19:46:04 +00:00

nalum referenced this issue

2026-08-23 19:46:30 +00:00

Order of work for the jobs flow redesign (#170-#183) #184

nalum added the

area/jobs

label

2026-08-23 22:57:16 +00:00

nalum referenced this issue from a commit

2026-08-24 13:06:46 +00:00

feat(jobs): one surface for the job detail sheet

nalum referenced this issue

2026-08-24 13:07:09 +00:00

feat(jobs): one surface for the job detail sheet #213

nalum commented

2026-08-26 18:47:55 +00:00

Author

Owner

Delivered by the merged jobs stack (now on main, 2026-08-26): the three pickers live in web/src/components/JobPickers.tsx and android/.../ui/JobPickers.kt — Who and Worth share the component, When confirms with the outcome-stating footer. The audit rounds (#238–#254) verified them against the handoff.

nalum closed this issue

2026-08-26 18:47:55 +00:00

Rows
Columns

Jobs: the Who, When and Worth pickers #173

Update — #183 is closed: creating a reward inside the job stays