Skip to content

feat(workflow): advance record state from the lifecycle diagram#66

Merged
xuyushun441-sys merged 1 commit into
mainfrom
feat/state-machine-transitions
Jun 1, 2026
Merged

feat(workflow): advance record state from the lifecycle diagram#66
xuyushun441-sys merged 1 commit into
mainfrom
feat/state-machine-transitions

Conversation

@xuyushun441-sys
Copy link
Copy Markdown
Contributor

Summary

Makes the state machine interactive. Under the Lifecycle diagram on record detail, the current state's outgoing transitions render as Available Actions buttons; tapping one confirms, PATCHes the record's state field to the target, and refreshes — the diagram re-highlights and the action set updates for the new state.

  • RecordStateMachines gains onTransition + pendingEvent. It lists only the current state's transitions as buttons (labelled "<event description> → <target state>"), disabling them while one applies.
  • Record detail wires the handler: confirm (Alert) → client.data.update({ [field]: target }) → refetch, with success/error toasts.
  • i18n: adds a workflow bundle (availableActions, updateStatus, moveToConfirm, statusUpdated, statusUpdateFailed) in en / zh / ar.

Verification

  • ✅ In-browser against a local 7.5.0 server: advancing crm_opportunity proposal → negotiation re-highlights the diagram (谈判 becomes current) and swaps Available Actions to the negotiation transitions (Deal won → 成交 / Lost in negotiation → 失败). The underlying PATCH /data/... returns 200 and persists.
  • ✅ New RecordStateMachines tests (current-state-only buttons, fires onTransition, read-only when omitted, empty when no machines); tsc clean; full suite 1128 pass (20 pre-existing snapshot failures, unrelated).

Note

The confirm step uses Alert.alert (consistent with the existing Delete action), which is native-only — on RN-Web the confirm is a no-op, so the data path was verified directly in the browser while the button → handler wiring is covered by tests + native behavior. Could move to the cross-platform Dialog component in a follow-up if web parity is wanted.

🤖 Generated with Claude Code

Make the state machine interactive. Under the Lifecycle diagram, the current
state's outgoing transitions render as "Available Actions" buttons; tapping one
confirms, then PATCHes the record's state field to the target and refreshes —
the diagram re-highlights and the action set updates for the new state.

- RecordStateMachines gains `onTransition` + `pendingEvent`; it lists only the
  current state's transitions as buttons (labelled "<event desc> → <target
  state>"), disabling them while one is applying.
- The record detail screen wires the handler: confirm (Alert) → client.data
  .update({ [field]: target }) → refetch, with success/error toasts.
- i18n: adds a `workflow` bundle (availableActions, updateStatus, moveToConfirm,
  statusUpdated, statusUpdateFailed) in en / zh / ar.

Verified in-browser against a local 7.5.0 server: advancing crm_opportunity
proposal → negotiation re-highlights the diagram and swaps the available
actions to the negotiation transitions (Deal won / Lost in negotiation). Adds
RecordStateMachines tests; typecheck clean; suite green apart from pre-existing
snapshots.

Note: the confirm uses Alert.alert (matching the existing Delete action), which
is native-only — on RN-Web the confirm step is a no-op.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@xuyushun441-sys xuyushun441-sys merged commit 01545e9 into main Jun 1, 2026
1 of 4 checks passed
@xuyushun441-sys xuyushun441-sys deleted the feat/state-machine-transitions branch June 1, 2026 20:49
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.

2 participants