Add tenant module entitlement administration
This commit is contained in:
@@ -61,6 +61,25 @@ blocker is shown through Core's actionable blocker pattern with the required
|
||||
action, responsible operator or administrator, and destination. Contextual help
|
||||
uses the stable `admin.module-lifecycle-workflow` documentation topic.
|
||||
|
||||
## Tenant Module Entitlements
|
||||
|
||||
Deployment lifecycle and tenant availability are separate administration
|
||||
workflows. **System > Tenant modules** lets a system administrator select a
|
||||
tenant, mark installed modules unavailable, available, or forced, and set the
|
||||
tenant's current selection. **Tenant > Modules** lets an account with the
|
||||
`admin:module:write` permission change only the available selection. The
|
||||
`module_admin` role template grants the narrow read/write pair for that task.
|
||||
|
||||
Core closes required dependencies, retains protected administration modules,
|
||||
uses an optimistic entitlement revision, and records audit and governed
|
||||
configuration evidence. A selected module that is not globally active remains
|
||||
configured but unavailable at runtime. Module selection never grants module
|
||||
permissions.
|
||||
|
||||
User and group module visibility is configured through Views, where each WebUI
|
||||
module is represented by its root module surface. This keeps tenant operational
|
||||
state distinct from presentation preferences.
|
||||
|
||||
## Package Surfaces
|
||||
|
||||
The admin UI intentionally exposes two different package concepts:
|
||||
|
||||
Reference in New Issue
Block a user