# Access administration

Django Admin is the operational interface for organization records, users,
organizational assignments, roles, role permissions, and role assignments.
Access uses Django staff status and native model permissions. The business
scope authorization APIs do not restrict admin querysets. Grant admin model
permissions according to the administrative responsibility intended.

## Supported workflows

- Manage organization master data through its existing forms. Use the
  deactivation action for lifecycle cascades; it delegates to organization
  services and ends affected organizational and role assignments atomically.
  Reactivation restores only the selected record. Restore parents before children.
- Create organizational assignments with consistent company, region, center,
  and department values. Use the deactivation action to end an assignment and
  its active role assignments. Use the reactivation action to restore an eligible
  assignment; inactive parents and duplicate active scopes are rejected.
- To switch the primary organizational assignment, select exactly one active
  assignment and use the primary action. Reactivation does not restore a former
  primary designation or reactivate role assignments.
- Manage role permissions using the role form's permission selector. Both add
  and change forms call `set_role_permissions` inside the admin change-form
  transaction. A failure rolls back the role edit and permission replacement.
- Deactivate roles through the lifecycle action to end their active role
  assignments while preserving organizational assignments. Reactivate roles
  and role assignments explicitly after their prerequisites are active.
- Manage users through the existing Django `UserAdmin`. Native user permissions,
  Groups, staff status, and superuser status retain their Django behavior.

Forms retain domain model validation. Editing an activation checkbox does not
perform a cascade; operations requiring coordinated changes must use the
lifecycle actions. Assignment deletion is disabled in admin to preserve history;
protected foreign keys continue to guard referenced master records.

Lifecycle actions require the model's change permission. Each selected record
uses its service transaction; a multi-record selection is not one transaction.
Reactivation validation errors are reported without restoring invalid records.

## Verification

Phase 1B.6 adds admin request tests for service delegation, parent and duplicate
validation, permission gating, downstream lifecycle effects, permission-save
rollback, and availability of the native user admin.

`python manage.py test --noinput`: 228 tests passed (217 existing, 11 added).
Django system checks passed; migration checks found no schema changes.


## Phase 6E operational discovery

Administration / Settings (/settings/) consolidates links to these existing
management surfaces. Global people/access and organization Admin links remain
visible only to active staff superusers; this navigation boundary does not change
native Admin authorization. Scoped managers receive only authorized operational
configuration links (and the existing restricted inventory-location Admin link).

No second permission editor, generic CRUD layer, lifecycle implementation, delete
operation or audit log was added. Primary assignment switching, role membership,
parent/child lifecycle actions and existing change history remain here. The
workspace explains dependencies and preserves existing confirmation/validation
paths. See OPERATIONAL_UI.md for the Phase 6E scope and verification results.