Manage account access through deliberate actions
Give administrators named actions for changing roles, suspending access and restoring accounts. Wildo carries those actions through their permissions, account transitions and audit behavior.
A suspension, a person’s own deactivation and account deletion mean different things. Keeping them separate makes both the interface and the resulting access easier to understand.
Example — Restore an account for the right reason
An administrator unsuspends an imposed hold. A voluntarily deactivated account uses a different reactivation action with a required reason.
For engineers
Choose the lifecycle action rather than patching status
The user resource declares separate operations for role assignment/revocation, suspension, unsuspension, reactivation and forced password reset. Generic updates do not stand in for those transitions.
| Action | Intended transition |
|---|---|
| Suspend | An administrator imposes a halt on access |
| Unsuspend | Lift that imposed suspension |
| Reactivate user | Restore an account its owner deactivated |
| Assign or revoke roles | Change authority through the role-management path |
| Force password reset | Withdraw sessions and send the owner a reset link |
Keep the actor and subject distinct
Administrative variants combine their role requirement with admitsCrossSubjectUserAdministration: true. That flag allows the target to be another user; it does not itself grant administrative authority. The same operation still has to satisfy its declared roles and any fresh-proof requirement.
The destructive user operation makes the combination explicit:
variantType: ResourceOperationVariantType.API_CALL,
isDefault: true,
roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
admitsCrossSubjectUserAdministration: true,
riskLevel: ResourceOperationRiskLevel.CRITICAL,
requiresStepUpAuthentication: true,
These are selected fields from the real user-deletion variant, with comments omitted. Presentation risk and step-up enforcement are separate settings.
Preserve continuity and the record of change
The shared transition machinery owns status changes and scheduled reactivation cleanup. Administrative floors prevent removing the last usable administrator. reactivate_user requires a reason because it reverses the owner’s chosen departure, while unsuspension has a different contract. Custom administration screens should invoke these operations and display their outcomes, not write the underlying status and role fields directly.