Allow Authorized Staff Users to Delete Non-Default Staff Roles

[noce-nick]

Summary

Extend Owner Community staff-role management so authorized staff users can delete non-default StaffRole records.

The action must be available from the existing staff-role details page and must safely handle staff users who are currently assigned the deleted role.

Requirements

Staff Role Deletion

• Add support for deleting a StaffRole.
• Only staff users with staffRolePermissions.canRemoveRole may perform the action.
• Default staff roles must not be deletable.
• The API must enforce these rules independently of UI visibility.
• Deleting a role must raise a StaffRoleDeletedEvent.

Assigned Staff Users

A deleted role may currently be assigned to one or more staff users.
Implement a StaffRoleDeletedEvent integration event handler that:

1. Finds all staff users assigned to the deleted role.
2. Reads the deleted role's enterpriseAppRole.
3. Finds the default StaffRole whose enterpriseAppRole matches the deleted role's enterpriseAppRole.
4. Reassigns each affected staff user to the matching default role
5. Persists the updated staff users.

The handler must be idempotent so repeated processing does not create duplicate assignments or otherwise corrupt staff-user role state.

If a matching default role cannot be found for the deleted role's enterpriseAppRole, the condition must be logged and surfaced as a processing failure rather than silently leaving affected staff users without an appropriate role.

Staff Portal

Update the existing staff-role details page:

• Add a red Delete button in the upper-right action area.
• Only display or enable the action when:
  • the current staff user has staffRolePermissions.canRemoveRole; and
  • the displayed role is not a default role.
• Guard the action with a Popconfirm explaining that assigned staff users will be reassigned to the default role matching the deleted role's enterpriseAppRole.
• Display mutation progress and failure feedback.
• After successful deletion, navigate back to the staff-role list and refresh the displayed data.

Storybook

Add or update Storybook coverage for the staff-role details page, including:

• Deletable non-default role.
• Default role where deletion is unavailable.
• User without staffRolePermissions.canRemoveRole.
• Deletion confirmation.
• Deletion in progress.
• Deletion failure.

Acceptance Criteria

• Staff users with staffRolePermissions.canRemoveRole can delete non-default staff roles.
• Staff users without staffRolePermissions.canRemoveRole cannot delete staff roles through either the UI or API.
• Default staff roles cannot be deleted, even by staff users with staffRolePermissions.canRemoveRole.
• The delete action requires confirmation before the mutation is submitted.
• Deleting a staff role raises StaffRoleDeletedEvent.
• Every staff user assigned to the deleted role is reassigned to the default StaffRole whose enterpriseAppRole matches the deleted role's enterpriseAppRole.
• Staff users not assigned to the deleted role are unchanged.
• Event handling is idempotent.
• A missing matching default role produces an observable processing failure.
• The UI correctly handles successful, pending, and failed deletion states.
• Storybook demonstrates the required permission, role-type, confirmation, pending, and failure states.
• Unit and integration tests cover the new domain, application service, persistence, integration event handler, GraphQL, and UI behavior as applicable.
• Serenity coverage in @ocom-verification enforces the expected behavior across the acceptance API, acceptance UI, and end-to-end test suites.

Development Guidance

This task is recommended to be implemented using test-driven development.

Begin by adding the Serenity scenarios that define the expected staff-role deletion and reassignment behavior, then implement the domain, application service, integration event handler, GraphQL, and UI changes required to satisfy those scenarios.