3.4 KiB
Quick Access
Quick Access is an optional presentation module. Feature modules register
compact tool metadata through the Core manifest contract and contribute their
renderer through quickAccess.tools. Quick Access owns the rail, overlay,
effective preference calculation, and settings UI. It never copies or owns the
underlying business objects.
Resolution
The live catalogue is derived from installed module manifests. Personal catalogues contain only currently authorized tools; system and tenant administrators can inspect the complete registered catalogue and inherited constraints. Effective visibility is resolved in this order:
- module installation and tenant entitlement;
- system availability, blocking, forcing, and ordering;
- tenant availability, blocking, forcing, and ordering;
- the user's enabled state and ordering;
- the active View or Workflow projection;
- the current principal's permissions.
An upper scope may block or force a category or tool. Lower scopes cannot override that decision, but may configure any still-available item. Stale preferences are retained and diagnosed so uninstalling and reinstalling a contributing module does not silently discard a user's arrangement.
The effective API reports each item's availability_state,
availability_source, and order_source. It also returns every unavailable
stored id as a stale_preferences entry with its system, tenant, or user
source. Administration and support tooling can therefore explain a result
without reading or copying any contributing module's state.
Categories
The initial stable categories are Work, Calendar, Messages, and Files. Messages may contain Mail, Postbox, and future chat contributions in one overlay. A category is a presentation grouping only; channel-specific authority, retention, acknowledgement, encryption, and delivery state remain with each owner module.
Safety
Quick Access is not an authorization boundary. Every contribution keeps its own permission requirements and View surface. Full-page routes remain the canonical fallback. Launch-context version 2 contains only the tenant/account identity, a reference-contract-version-1 active object, acting-assignment identifiers, temporal selection, exact View identity, View recommendations or focus, and a safe return route. Cross-tenant object references are discarded and unknown versions fail closed. View focus applies only when at least one focused tool is currently enabled, context-compatible, and authorized; a recommendation only changes ordering and emphasis. The rail identifies an active View focus and offers All available tools as a temporary escape to the complete permission-derived catalogue. This does not change the active View, persist an override, or expose a tool that failed installation, entitlement, policy, preference, context, surface, or permission checks. If no focused tool is eligible, the rail explains that stale focus and falls back to the permission-derived catalogue instead of becoming empty.
Each renderer performs owner-side reads and effects and explicitly reports either a result-contract-version-1 completion with a typed owner reference or a cancellation reason. Closing the drawer is not completion. The host may listen for that correlated result while its unsaved page state remains mounted. Disabling this module removes the rail without making any domain state unavailable through its owning module.