Interaction Behaviors

Use cases and scenarios for the GEN::INT (Interactions) area. These behaviors define the cancel and undo interaction patterns that are shared across all forms and inline editing contexts in the application. Any use case that involves a multi-step data entry flow — including inline list editing, item creation forms, and entity edit forms — depends on these patterns to define the behavior of the “Cancel” path.

GEN::INT::0001 — Cancel and Undo Flows

All cancel paths leave the system in its pre-action state. No data is modified, no API call is made for the discarded change, and any form or edit state is cleared. This use case is crossed by GEN::LST::0007 (navigate-away prompt during inline edit) and by entity creation and edit forms across all domains.

Persona	Irene Itemsworth (Inventory Manager), David Dealsworth (Purchasing Manager), Sam Scansworth (Shop Floor Worker), Keisha Clerkson (Receiving Clerk), Owen Ownerton (Business Principal), Alan Adminson (Account Admin)
Status	Covered

GEN::INT::0001::0001.US — Cancel Entity Creation Form

The user opens an entity creation form (for example, the Add Item form), partially or fully fills in fields, and then clicks “Cancel” or closes the panel without submitting. The form closes and no entity is created. The form state is cleared so that reopening the creation form presents a blank form. No API call is sent.

GEN::INT::0001::0002.US — Cancel Inline Edit via Escape

The user has double-clicked an editable cell in the list and is in inline edit mode. The user types one or more characters and then presses Escape. The cell exits edit mode immediately. The typed value is discarded and the cell reverts to its original pre-edit value. The isCancelAfterEnd() method returns true and the wasCancelled flag is set. No draft-creation API call is made. This scenario is the Escape path of GEN::LST::0007::0004.US.

GEN::INT::0001::0003.US — Cancel Entity Edit Form

The user opens an entity edit form from a detail panel (for example, the Edit Item form), modifies one or more fields, and then clicks “Cancel.” The form closes and the original data is preserved. No update API call is sent. The entity remains in its pre-edit state.

GEN::INT::0001::0004.FS — Navigate Away with Unsaved Inline Edit Changes

When the user navigates away from a row that is in inline edit mode and changes have been made, the system presents a confirmation prompt with three options: accept the changes (which triggers the two-phase commit described in GEN::LST::0007::0003.US), cancel the changes (which discards the edits and exits edit mode cleanly), or return to the editing position (which keeps the row in edit mode with the current unsaved values intact). The prompt blocks navigation until the user makes a selection. This scenario crosses GEN::LST::0007.

GEN::INT::0001::0005.US — Remove Item from Order Queue

The user cancels a pending order by removing an item from the Order Queue while it is in REQUESTING or REQUESTED state. The card returns to its previous state before the order was initiated. This action is available only before the supplier has started processing. This scenario crosses PRO::OQ (Order Queue domain) for the specific card state transition involved.

GEN::INT::0002 — Concurrent-Edit Awareness

The system notifies the user when the entity data on screen has changed elsewhere — through another tab of the same browser, another browser, or another user — before the user acts on it. The notification is a banner with Refresh and Dismiss controls. This use case implements the read-side half of the Concurrent-Edit Awareness feature and applies to every surface that mounts the item-details panel (items page, order-queue, scan modals, card-preview modal). The bulk-action half is documented in REF::ITM::0009.

Persona	Irene Itemsworth (Inventory Manager), David Dealsworth (Purchasing Manager), Sam Scansworth (Shop Floor Worker), Keisha Clerkson (Receiving Clerk)
Status	Covered

GEN::INT::0002::0001.US — Sibling Tab Sees the Banner After a Local Edit

The user opens the same item-details panel in two tabs of the same browser. In tab 1, the user changes a kanban card’s state (for example, marks it as Received from the order-queue page). Within sub-second time of the change, tab 2’s detail panel shows the stale-data banner at the top. Tab 1 does not show the banner — the tab that originated the change refreshes through its own success path. Clicking Refresh in tab 2 issues a new fetch and clears the banner once the fetch resolves with the new state. Clicking Dismiss closes the banner without refreshing.

GEN::INT::0002::0002.US — Detail Panel Shows the Banner When Cached State Has Diverged

The user is on the items page and opens the detail panel for an item that has been modified by another user since the items page last loaded. The panel renders immediately with the cached cards (stale-while-revalidate); within the time of one BFF round-trip, the stale-data banner appears at the top of the panel. The cards in the panel are still the cached ones — the banner is the signal that the user should refresh before acting. Clicking Refresh updates the cards to the new server state and clears the banner.

GEN::INT::0002::0003.US — Banner Does Not Appear on Transient Network Errors

The user has the detail panel open. The browser briefly loses connectivity, or the BFF returns a 5xx for the freshness check. The stale-data banner does not appear, and the panel keeps rendering the cards it had. When connectivity returns and the next freshness check succeeds against the unchanged state, no banner appears. The capability degrades to “no information” on transport failure rather than to a false-positive banner the user cannot clear.

GEN::INT::0002::0004.US — Cross-Browser Banner Within the Operational Latency Bound

User A on browser A modifies a card. User B on browser B has the same item’s detail panel open. User B sees the banner appear within the operational poll-interval bound (default two minutes) without taking any further action. The exact latency depends on NEXT_PUBLIC_ITEM_CARDS_POLL_MS for the deployment.

GEN::INT::0002::0005.FS — Banner Survives Tab Backgrounding

The user opens the detail panel and switches away to another browser tab or another application. While the tab is backgrounded, the cross-process polling tick does not fire — the capability suspends quietly without producing background network traffic. When the user returns to the tab, the freshness check resumes; if the data changed in the interim, the banner appears within one tick of the user re-focusing.

Summary

Use Case	Scenarios	US	FS	UC
GEN::INT::0001 Cancel and Undo Flows	5	4	1	0
GEN::INT::0002 Concurrent-Edit Awareness	5	4	1	0
Total	10	8	2	0

---