Fixes: #21243
# Issue
When a user is on a specific record's page (for example, looking at a
Person) and opens a related record (like a Note) in the right-side
panel, clicking "Permanently Delete" on that Note would abruptly
redirect the user to the main "Notes" list. This breaks the user's
workflow, as they typically want to remain on the parent Person page
after deleting a sub-record.
# Root Cause
Inside the `DestroyRecordsCommand` and `DeleteRecordsCommand`
components, the application was programmed to unconditionally trigger a
`navigateApp` redirect to the deleted object's index page upon
successful deletion. The code did not account for whether the deletion
was triggered from the main index page or from inside a contextual side
panel.
# How we fixed it
I introduced a new `isInSidePanel` flag into the
`HeadlessCommandContextApi`.
The command menu now detects if the delete action originated from inside
a side panel and passes this flag down the execution chain. If `true`,
the `DestroyRecordsCommand` simply closes the panel
(`closeSidePanelMenu()`) and keeps the user exactly where they were.
## After that fix, I encountered another issue (UI not updating
automatically)
Because the app now correctly kept the user on the Person page, a new
bug surfaced: the "Note" chip inside the relation table did not
disappear immediately. The user had to manually refresh the page to see
the deletion.
This happened because:
1. The Apollo optimistic cache occasionally failed to trace deeply
nested morph-relationships back to the parent.
2. A standard local React `useState` fallback was insufficient. The
table component aggressively unmounts and remounts relation cells
whenever a user hovers over them to display interactive controls, which
would wipe the local React state clean and cause the "ghost chip" to
reappear.
##How I fixed that issue (and optimized it)
I built an event-driven fallback using global Jotai state to permanently
hide the chips:
1. **Precision ID Broadcasting**: I updated the `useDestroyManyRecords`
and `useIncrementalDestroyManyRecords` hooks to extract and broadcast
only the *confirmed* destroyed IDs directly from the Apollo mutation
response, preventing false-positive UI removals if the backend performed
a partial delete.
2. **Batch Optimizations**: During bulk deletions, events are now
broadcasted per-batch rather than accumulating thousands of IDs in
memory until the end, keeping the UI instantly responsive and memory
bounded.
3. **Per-Cell State Scoping (`atomFamily`)**: Instead of a leaky global
array, we used Jotai's `atomFamily` to dynamically generate a unique
Noticeboard for every specific table cell (`${recordId}-${fieldName}`).
This ensures the hidden-state survives mouse-hover unmounts while
remaining cleanly isolated.
4. **Defensive Filtering**: The `RelationFromManyFieldDisplay` component
was updated to defensively guard against `undefined` array entries and
strictly match deleted IDs only against valid foreign keys (ending in
`'Id'`), preventing false-positive removals if a UUID happened to be
pasted into a description field.
5. **SSE Resilience**: We hardened the Server-Sent Event (SSE) listeners
with optional chaining and null-filtering to ensure malformed backend
payloads do not crash the real-time event pipeline.
# Screen Recording
https://github.com/user-attachments/assets/19fc8a3f-ba28-43c2-b1f3-a91127cdad97
---------
Co-authored-by: bosiraphael <raphael.bosi@gmail.com>
Co-authored-by: Raphaël Bosi <71827178+bosiraphael@users.noreply.github.com>
Replace generic JSON scalar with a typed GraphQL union
CommandMenuItemPayload (PathNavigationPayload |
ObjectMetadataNavigationPayload) for the CommandMenuItem.payload field
- Adds a payload JSON column to `CommandMenuItem` and introduces a
unified `NAVIGATION` engine component key that replaces all individual
GO_TO_* keys
- Navigation commands now use the payload to determine their target
(either an objectMetadataItemId or a path), making navigation commands
dynamic and eliminating the need for a hardcoded engine key per object
- Includes a 1.21 upgrade command (refactor-navigation-commands) that
migrates existing GO_TO_* items to NAVIGATION items with the appropriate
payload, and applies a CHECK constraint enforcing payload coherence
https://github.com/user-attachments/assets/4d305ba2-ae0b-4556-bb0e-e9d899777350
TODO: In a second PR, create the sync between object metadata items and
the navigation command menu items
- Object metadata item created or enabled -> Create navigation command
- Object metadata item deleted or disabled -> Delete associated
navigation command
In another PR:
- Allow `label`, `shortLabel` and `icon` to resolve the
`navigateToObjectMetadataItem` dynamically in their interpolation
instead of being hardcoded in the command menu item
- Make the icon dynamic in the command menu items as the label so that
we can resolve ${navigateToObjectMetadataItem.icon} at runTime -> This
way we won't need to keep update the command menu item icon when we
update the objectMetadataItem icon
- Makes engineComponentKey non-nullable on CommandMenuItem. Adds two new
engine component keys: TRIGGER_WORKFLOW_VERSION and
FRONT_COMPONENT_RENDERER to cover the former standalone cases.
- Unifies the previously separated engine, front component and workflow
runners into a single `CommandRunner` component with a unified
`useMountCommand` hook that handles all command types.
DeviSriSaiCharan