Keep a working administrator in place

An application administrator hands responsibility to another administrator, with a pause at the handover.

Keep a working administrator in place

An administrative change should not leave the application with nobody able to manage it. Wildo refuses changes that would remove the last usable super-administrator and explains the recovery step.

The check considers whether an account can actually serve as an administrator, not only whether a role name remains in the database.

Example — Hand over administration before leaving

Before removing the final administrator’s authority, appoint another usable administrator. The same request can then proceed without leaving the application stranded.

For engineers

Role and account-status changes use the transition guard; removals use the removal guard. Both reach the same population check. This part of that check shows how it excludes the accounts being changed:

This implementation excerpt from super-admin-floor.backend.utils.ts shows the decision in context; explanatory source comments are omitted.

export async function assertSuperAdminFloorPreserved(params: {

  subjectUserIds: readonly string[];
  cause: SuperAdminFloorReductionCause;
  executionContext: ExecutionContext<any>;
  repositoriesRegistry: RepositoriesRegistryHandlerBackendService;
  errorBuilder: ErrorBuilderBackendService;
  conferringRoles: readonly string[];
  operationIdentifier: string;
}): Promise<void> {
  const { subjectUserIds, cause, executionContext, repositoriesRegistry, errorBuilder, conferringRoles, operationIdentifier } = params;

  const remainingUsableSuperAdmins = await countOtherUsableSuperAdmins({
    excludedSubjectIds: subjectUserIds,
    executionContext,
    repositoriesRegistry,
    errorBuilder,
    conferringRoles,
    operationIdentifier,
  });

  if (remainingUsableSuperAdmins >= SUPER_ADMIN_FLOOR_MINIMUM) return;

  throw errorBuilder.buildError(ErrorType.CONFLICT, executionContext, {
    context: {
      code: AdministrativeContinuityErrorCode.LAST_APPLICATION_SUPER_ADMIN,
      reason: SUPER_ADMIN_FLOOR_REFUSAL_REASON,
      message:
        'Refused: this would leave the application with no usable super-administrator. '
        + SUPER_ADMIN_FLOOR_REMEDY,
      cause,
      operationIdentifier,
      subjectUserIds: [...subjectUserIds],
      remainingUsableSuperAdmins,
      requiredUsableSuperAdmins: SUPER_ADMIN_FLOOR_MINIMUM,
      conferringRoles: [...conferringRoles],
      usableStatuses: [...ADMINISTRATIVELY_USABLE_USER_STATUSES],
    },
  });
}

Treat the refusal as a state conflict

The caller may have all the required permissions and still be unable to perform this change. The response is a conflict with LAST_APPLICATION_SUPER_ADMIN, because the problem is the resulting administrator population. Promoting another usable account is the remedy; acquiring another permission is not.

Custom roles that confer super-administrator authority participate through the live role hierarchy. A disabled or otherwise unusable account must not be counted as the fallback simply because its stored roles still look powerful.

Preserve continuity on the right lifecycle path

The account-role administration handlers call the guard when authority or usability decreases. Subject erasure has a separate continuity path: do not replace a privacy erasure workflow with a blanket refusal. Organization ownership has its own last-owner rule, because tenant ownership and application administration are different responsibilities.

Keep a working administrator in place