fix: wire up Add Employee screen#1694
Conversation
6b9c545 to
acc8e8b
Compare
There was a problem hiding this comment.
Pull request overview
Fixes a missing state-machine transition in the UNSTABLE Time Off flow so the “Add Employee” action from the policy detail screen actually navigates into the add-employees step and preserves the selected policyId in machine context.
Changes:
- Added a
TIME_OFF_ADD_EMPLOYEES_TO_POLICYtransition fromviewTimeOffPolicyDetail→addEmployeesToPolicy, reducingpolicyIdinto context. - Added unit tests covering the new transition and the round-trip back to
viewTimeOffPolicyDetailviaTIME_OFF_ADD_EMPLOYEES_DONE.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/components/UNSTABLE_TimeOff/TimeOffFlow/timeOffStateMachine.ts |
Wires the previously-unhandled TIME_OFF_ADD_EMPLOYEES_TO_POLICY event to transition into addEmployeesToPolicy while updating context with policyId. |
src/components/UNSTABLE_TimeOff/TimeOffFlow/timeOffStateMachine.test.ts |
Adds regression tests validating the new transition and that policyId is preserved after returning from the add-employees step. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@copilot can you fix tests? |
Added the two missing state-machine transitions in
Also renamed the shared |
The Add Employee button on the time-off policy detail screen emitted TIME_OFF_ADD_EMPLOYEES_TO_POLICY, but viewTimeOffPolicyDetail had no matching transition — so the event was swallowed and the button appeared to do nothing. Add a transition from viewTimeOffPolicyDetail → addEmployeesToPolicy that reduces the payload's policyId into context. The existing addEmployeesToPolicy → viewTimeOffPolicyDetail transition (on TIME_OFF_ADD_EMPLOYEES_DONE) preserves ctx, so the round trip lands back on the same policy detail with the new employees attached. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Add Employees button now lands on a "manage membership" screen: existing assignees are pre-checked with their current balance shown read-only, and unchecking one queues a removal. On submit, the screen diffs the selection against the policy's current roster and runs the add and/or remove mutations as needed (remove first, then add). When removals are queued, a destructive confirm dialog gates the submit. Behavior: - Pre-select via `useSelectEmployeesData(companyId, originalUuids)`. - Read-only balance text for originally-on-policy rows; new selections keep the editable input with the carry-over pre-fill. - Diff at submit: skip unchanged rows so balances are not re-submitted (the dedicated edit-balance flow on the detail page owns those). - No-op diff just emits TIME_OFF_ADD_EMPLOYEES_DONE without an API call. - Cache invalidation matches the detail page's pattern. - Wizard mode is unchanged: still emits employeeUuids without fetching the policy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…s from viewTimeOffPolicyDetail Agent-Logs-Url: https://github.com/Gusto/embedded-react-sdk/sessions/5dde40e2-2625-4283-93dd-0f5c698b1b1b
8d2a2de to
a67611b
Compare
Summary
Reworks the Add Employees screen reached from a Time-Off policy detail page so a single round-trip can manage the policy's roster end-to-end. Previously the user landed on a list of every non-terminated employee with no indication of who was already on the policy — re-submitting an existing assignee was easy and removing one was a separate flow on the detail page.
Two parts:
viewTimeOffPolicyDetailnow transitions toaddEmployeesToPolicyonTIME_OFF_ADD_EMPLOYEES_TO_POLICY, reducing the payload'spolicyIdinto context. Round-trip back via the existingTIME_OFF_ADD_EMPLOYEES_DONEtransition.Behavior details on (2):
useSelectEmployeesDataacceptsinitialSelectedUuidsto seed the selection set.policy.employees.toAddcallsuseTimeOffPoliciesAddEmployeesMutation;toRemovecallsuseTimeOffPoliciesRemoveEmployeesMutation. Unchanged rows are skipped — balances for existing assignees are owned by the dedicated edit-balance flow on the detail page.toRemove.length > 0a destructive confirm dialog gates the submit. On confirm, run remove first, then add, then invalidate the policy cache.TIME_OFF_ADD_EMPLOYEES_DONEwithout an API call so navigation still works.employeeUuids).This is PR 9 in the time-off bug-fix slate captured in
~/.claude/plans/ok-i-want-to-partitioned-balloon.md. Plan for the membership UX work:~/.claude/plans/we-were-just-working-memoized-island.md.Test plan
npm run test -- --run src/components/UNSTABLE_TimeOff— 305/305 passing (added 6 new tests covering pre-select, read-only balance, no-op diff, add-only path, dialog-gated submit, remove-then-add ordering, cache invalidation)npx tsc --noEmit— cleannpm run lint— cleanWithExistingAssignees,ExistingAssigneesWithNewSelections, andRemoveConfirmDialogOpenrender correctly (npm run storybook)npm run sdk-app):🤖 Generated with Claude Code