fix(ux): confirm destructive actions on Team Revoke and SLA Remove #187
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/mokosh-apps!187
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/pms-369-confirm-destructive-actions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Team page's Revoke button on a pending invitation fired DELETE /invitations/{id} on the first click with zero confirmation - a single misclick on the row instantly destroyed a pending invite. PMS-369 reviewer flagged this class of bug as a data-loss vector across the app, and Team was the only call site that actually had zero confirmation: the other 15 destructive call sites use window.confirm_with_message (browser-native), and one used native confirm on SLA target Remove that the reviewer specifically called out as feeling like "no confirmation" because of the native dialog's unstyled appearance.
Two surgical fixes here. Team Revoke now stages the (id, email) of the target row into a
pending_revokesignal that opens the shared ConfirmDialog component (already in src/components/modal.rs), inlining the invitee's email in the dialog body so the user can see which invite they are about to revoke. SLA target Remove switches from the native browser confirm to the same ConfirmDialog, surfacing the priority name and a sentence explaining the policy will fall back to no target for that priority until a new one is set. Both dialogs use destructive: true so the confirm button renders in the Danger variant, and both gate cancel + close while the in-flight DELETE is running so the user cannot dismiss the confirm mid-request.The other 14 destructive sites already gate behind a confirm (window.confirm_with_message). Standardising them onto the polished ConfirmDialog is a UX consistency follow-up; this PR closes the actual safety hole (Team) and the specific styling call-out (SLA) without ballooning into a 16-file sweep.
#PMS-369
The Team page's Revoke button on a pending invitation fired DELETE /invitations/{id} on the first click with zero confirmation - a single misclick on the row instantly destroyed a pending invite. PMS-369 reviewer flagged this class of bug as a data-loss vector across the app, and Team was the only call site that actually had zero confirmation: the other 15 destructive call sites use window.confirm_with_message (browser-native), and one used native confirm on SLA target Remove that the reviewer specifically called out as feeling like "no confirmation" because of the native dialog's unstyled appearance. Two surgical fixes here. Team Revoke now stages the (id, email) of the target row into a `pending_revoke` signal that opens the shared ConfirmDialog component (already in src/components/modal.rs), inlining the invitee's email in the dialog body so the user can see which invite they are about to revoke. SLA target Remove switches from the native browser confirm to the same ConfirmDialog, surfacing the priority name and a sentence explaining the policy will fall back to no target for that priority until a new one is set. Both dialogs use destructive: true so the confirm button renders in the Danger variant, and both gate cancel + close while the in-flight DELETE is running so the user cannot dismiss the confirm mid-request. The other 14 destructive sites already gate behind a confirm (window.confirm_with_message). Standardising them onto the polished ConfirmDialog is a UX consistency follow-up; this PR closes the actual safety hole (Team) and the specific styling call-out (SLA) without ballooning into a 16-file sweep. #PMS-369