# System configuration — Phase 5A

Configuration Center is at `/settings/`. It discovers existing authoritative
configuration; it does not create duplicate master models, replace domain
services, or provide a generic key/value settings table. No migration is needed.

## Inventory and ownership

Classification: **A** already manageable through an operational UI; **B**
manageable through Django Admin; **C** lacked a practical management/discovery
interface for the stated use; **D** internal data not to edit as configuration.
Some domains have both operational and technical Admin interfaces. Transaction
records listed below explain dependencies, not a proposal to turn them into
master data.

| Domain / authoritative item | Class before Phase 5A | Owner and current interface |
| --- | --- | --- |
| Company, Region, ServiceCenter, Department | B | Trusted system administrator; Organization Admin with existing lifecycle actions |
| UUID User, password, staff/superuser flags | B | Trusted account administrator; native UserAdmin / createsuperuser |
| UserOrganizationAssignment, primary assignment | B | Access administrator; assignment Admin and lifecycle/primary services |
| Role and Permission membership | B | Access administrator; Role Admin calls the existing permission service |
| UserRoleAssignment | B | Access administrator; role-assignment Admin and lifecycle services |
| Permission definitions, ContentType records | D | Django migrations/post_migrate; select memberships, do not create substitute permission records |
| Groups/direct user permissions | B | Native Django administration only; do not create business scope |
| Brand, ProductCategory, ProductModel, ProductVariant | B | Global catalog owner; Catalog Admin, existing activation/movement validation |
| DeviceIdentificationPolicy | B | Catalog owner; explicit IMEI1/IMEI2/serial choices in Admin |
| ServiceCategory | B | Service taxonomy owner; independent reference master, not inferred complaint classification |
| ComplaintSymptom and category applicability | B | Taxonomy Admin and applicability service |
| FaultDiagnosis, RootCause, RepairAction and applicability | B | Taxonomy Admin; RootCause remains optional and NULL means unknown/unconfirmed |
| Customer, addresses, contacts | A/B | Front-desk customer creation; Admin supported updates/primary/lifecycle; workspace search and overviews are read-only |
| Device, identifiers, ownership, purchase/warranty evidence | B | Supported Device Admin/services; operational lookup/overviews do not replace evidence workflows |
| Customer/device records as initial setup | Not a prerequisite | Created during actual operations; readiness never demands fake customers or hardware |
| PartCategory, SparePart, serialization policy | B | Parts Admin/services; serialization policy locks after units or posted inventory history |
| SparePartCompatibility | B | Existing part compatibility management; model-wide versus variant-only semantics remain distinct |
| InventoryLocation | B | Scoped Inventory Admin; configure before inventory receipts/movements |
| Stock ledger, units, reservations, document/posting evidence | D for configuration | Existing inventory workflow services only; never seed balances or edit ledgers directly |
| Quotations, invoices, payments, allocations, receipts, releases | B workflow / A read-only overview | Commercial transaction services/Admin; these are not global settings |
| Commercial currency, responsibility, payment method, status choices | D | Existing validated transaction choices/constants; no new currency/tax/payment-method master is justified |
| AppointmentSlot date/time/capacity | A; C for slot-only management navigation | Existing front-desk forms/services; Phase 5A adds scoped discovery and return navigation usable by slot-only managers |
| Appointment and QueueEntry lifecycle | A | Existing Front Desk; not master-data configuration |
| NotificationTemplate | A | Company-scoped operational template UI |
| Notifications, attempts, delivery results | D for configuration | Existing communications workflow only; no direct status editing |
| Communication adapters and credentials | Deployment configuration | Provider mapping and environment/secrets; not ordinary database settings |
| SlaPolicy | A | Company-scoped SLA policy UI |
| SLA snapshots, escalation/communication history | D | Existing enrollment/monitoring services; immutable evidence |
| Reporting permissions | B membership / D definitions | Existing Role Admin; permission definitions are migration-owned |
| Reporting dimensions and calculations | D | Frozen query semantics, not configurable classifications or stored dashboard counters |
| Operations navigation and dashboards | D | Permission-derived presentation; no editable global selected-company or navigation table |
| Customer/job/quotation/invoice/receipt/queue numbering sequences | D | Domain allocators, never manually edited or reset |
| Sessions, Admin logs, migration recorder, immutable evidence | D | Framework/domain ownership, not master data |

No other C-class business configuration required a new CRUD screen. Existing
Admin interfaces are appropriate for infrequent technical/global management.
Real SMS integrations and deployment secrets remain deployment work, not an
invented database model or generic configuration editor.

## Configuration Center and authorization

The Phase 4D shell adds a Configuration Center link only when a relevant
capability is present. Merely being staff, having a URL, or having native Django
permissions does not grant scoped operational configuration.

- Organization, access, global product/service catalogs and parts Admin links
  are shown only to active **staff superusers**. The older Admin querysets in
  these areas are intentionally global, as documented in ADMINISTRATION.md;
  this phase does not advertise them as company-scoped management or change their
  frozen native authorization semantics.
- Existing template and SLA policy links require their company-level business
  permissions. A center-only assignment does not grant company-wide management.
- Slot configuration requires `frontdesk.manage_slots` against each center.
- The scoped InventoryLocation Admin link requires staff status, native change
  permission, `inventory.manage_inventory` and `inventory.view_stock` capability.
  The destination retains its existing scoped queryset and write checks.
- Global readiness UI is restricted to active staff superusers. Ordinary scoped
  managers cannot inspect another company's setup through readiness results.

`/settings/slots/` lists authorized centers. `/settings/slots/<center UUID>/`
paginates their slots. New/edit forms reuse `SlotForm` / `ConfigureSlotForm` and
`create_slot` / `configure_slot`; their post-save destination stays in settings.
This resolves the existing front-desk redirect issue for a manager who has slot
permission but no appointment/queue viewing permission. Every GET/POST scopes the
center first and binds existing slots to that center. POST remains CSRF-protected;
capacity and lifecycle validation are delegated to the existing services.

No new permissions or authorization adapters are introduced. Center/company
querysets retain the existing region/department semantics. Configuration landing
and readiness are GET-only and non-cacheable. Lists paginate at 25 and reuse the
responsive operational shell. No internal sequence, balance, transaction-status
or history editor is added.

## Readiness

`python manage.py check_installation_readiness` is read-only. `--json` prints the
same structured checks. It exits nonzero for any REQUIRED failure and reports
actionable next steps. It never creates data, changes schema, instantiates a
communications provider, or sends a message. Connectivity/history failures are
reported without raw database exception text or secret values.

**REQUIRED — minimum intake setup:** all migrations applied; at least one active
company; at least one valid active region/center path per active company; an
active staff superuser with a usable password; at least one active product model
with active brand/category and an explicit identification policy. An
all-NOT_APPLICABLE policy is configured; an absent policy is not.

**RECOMMENDED:** a non-superuser usable login with a valid active organizational
assignment and a permission-bearing active role assignment; identification
policies for every active model; applicable active complaint, diagnosis and
repair-action reference data for configured product categories. This detects
setup presence, not authorization for every workflow. Review role capabilities
and taxonomy coverage for every category the installation will actually service.

**OPTIONAL:** known RootCause data; parts catalog; active inventory locations;
current/future active appointment capacity; active company notification
templates; a configured communications adapter; a currently effective SLA policy.
RootCause is never a mandatory completion prerequisite and no unknown cause
master is fabricated. Optional checks are presence indicators, not full coverage
or transport verification. Current/future slots are date-based; SLA dates use the
configured project timezone. Existing disabled adapters are not live-delivery
certification.

Readiness is a **minimum intake configuration check**, not production security
certification, stock availability, financial readiness, or proof that every
repair workflow can complete. Recommendations/optional gaps are visible without
falsely prohibiting quotation-free, parts-free, or unknown-root-cause workflows.

## Environment-only settings and safety

Database credentials, Django secret key, provider/email passwords, API keys and
other secrets stay in environment/deployment configuration. `DB_PASSWORD` follows
the existing local `.env`-only convention; no values are displayed by these
screens/commands. Settings such as DEBUG, allowed hosts, TLS, adapter selection,
email backend and timezone remain deployment-owned. No generic settings table is
justified by the current architecture.

Use existing lifecycle/deactivation actions. Reactivation restores only what its
supported service permits; it is not a blanket descendant restore. Referenced
records retain protective foreign keys and historical snapshots. This phase
does not relax deletes, rewrite applicability, unlock serialization policies, or
reinterpret financial/taxonomy choices for convenience.

Future CSV/Excel master-data import could cover organization, catalogs, taxonomy
and parts compatibility. It must define stable identifiers, dry-run validation,
scoped authorization, per-domain service calls and conflict reporting. No import
engine or changes to existing reporting/export behavior are included here.

See [INSTALLATION_BOOTSTRAP.md](INSTALLATION_BOOTSTRAP.md) for installation and
demo instructions. Known limits: global master management remains trusted Admin
work; there is no delegated company-scoped organization/RBAC editor, secret
manager, provider setup wizard or automatic scheduler in this phase.

## Phase 5A verification

Validated against the committed Phase 4D baseline `ad8c5f5`. The final focused
run passed **32 tests in 54.666 seconds**: 30 new configuration/readiness/bootstrap
tests plus the two unchanged operational dashboard/search query-bound tests.
The seed tests include actual concurrent PostgreSQL execution.

`manage.py check` passed; `makemigrations --check` reported no changes. Help for
both new commands resolved successfully. The single required
`audit_project --quick` invocation passed all checks and **19 smoke tests**
(28.923 seconds of tests; **72.568 seconds** total audit runtime). No full audit
was run. Existing tests, historical migrations and domain services were unchanged.
No demo data was seeded into the working application database.


## Phase 6E administration discovery

The existing Configuration Center at /settings/ now presents Administration /
Settings: People & Access, Organization, Service Master Data, Operations and
System. These are navigation groups, not new domain models or permission scopes.
Global Admin destinations remain restricted in discovery to active staff
superusers; existing scoped slot/SLA/template/location management is reused.
A label-only search never searches configuration values or user records.

The overview reports active-state counts, scoped to existing management authority.
It does not infer capacity, effective SLA coverage, successful communications or
production readiness from those counts. Installation readiness still reuses the
existing inspector and exposes safe statuses only. No credential values, provider
calls, new mutation path or generic settings editor were added.

See OPERATIONAL_UI.md, Phase 6E, for exact metric definitions, query measurements,
responsive verification and known limitations. Existing audit/history and domain
lifecycle protections remain at their management destinations.