|
|
|
@@ -63,7 +63,7 @@ def _dsar_provider(_context: ModuleContext) -> TenancyDsarProvider:
|
|
|
|
|
manifest = ModuleManifest(
|
|
|
|
|
id="tenancy",
|
|
|
|
|
name="Tenancy",
|
|
|
|
|
version="0.1.21",
|
|
|
|
|
version="0.1.22",
|
|
|
|
|
required_capabilities=(
|
|
|
|
|
CAPABILITY_AUTH_PRINCIPAL_RESOLVER,
|
|
|
|
|
CAPABILITY_AUTH_PERMISSION_EVALUATOR,
|
|
|
|
@@ -108,6 +108,16 @@ manifest = ModuleManifest(
|
|
|
|
|
),
|
|
|
|
|
),
|
|
|
|
|
documentation=(
|
|
|
|
|
DocumentationTopic(
|
|
|
|
|
id="tenancy.reference.navigation-layout",
|
|
|
|
|
title="Arrange tenant navigation",
|
|
|
|
|
summary="Set a tenant default with the shared module and separator editor.",
|
|
|
|
|
body="Tenant Settings uses the same drag-and-drop layout editor as system, personal and View configuration. Add or remove available navigation modules, insert optionally labelled separators, and drag either kind of entry. Keyboard handles use Space to pick up, arrows to move, Enter to drop and Escape to cancel; arrow buttons offer the same moves. Removing a module here only hides its navigation entry. System locks remain visible and cannot be removed; tenant locks prevent personal removal while permitting reordering. User preferences take precedence over the tenant layout. Opening does not dirty the page; Save persists the draft and Use inherited layout removes the tenant override. Collapsed rails show the group boundaries as horizontal lines. Entitlements, Views and permissions are not changed.",
|
|
|
|
|
documentation_types=("user", "admin"), audience=("tenant_admin", "system_admin", "user"),
|
|
|
|
|
related_modules=("admin", "access", "views"), metadata={"kind": "reference"},
|
|
|
|
|
translations={"de": {"title": "Mandantennavigation anordnen", "summary": "Mandantenstandard mit dem gemeinsamen Editor für Module und Trennlinien festlegen.",
|
|
|
|
|
"body": "Die Mandanteneinstellungen verwenden denselben Drag-and-drop-Editor wie System-, persönliche und View-Konfiguration. Ergänzen oder entfernen Sie verfügbare Navigationsmodule, fügen Sie optional benannte Trennlinien ein und ziehen Sie beide Eintragsarten. Am Tastaturgriff nimmt die Leertaste auf, Pfeile verschieben, Eingabe legt ab und Escape bricht ab; Pfeilschaltflächen bieten dieselben Schritte. Das Entfernen blendet nur den Navigationseintrag aus. Systemsperren bleiben sichtbar und können nicht entfernt werden. Mandantensperren verhindern persönliches Entfernen, erlauben aber Umordnen. Benutzerpräferenzen haben Vorrang vor der Mandantenanordnung. Das Öffnen erzeugt keine Änderung. Speichern übernimmt den Entwurf; Geerbte Anordnung verwenden entfernt die Mandantenausnahme. Eingeklappte Leisten zeigen Gruppengrenzen als horizontale Linien. Modulfreigaben, Views und Berechtigungen ändern sich nicht."}},
|
|
|
|
|
),
|
|
|
|
|
DocumentationTopic(
|
|
|
|
|
id="tenancy.current-context",
|
|
|
|
|
title="Work in the correct tenant context",
|
|
|
|
@@ -139,7 +149,7 @@ manifest = ModuleManifest(
|
|
|
|
|
id="tenancy.lifecycle-and-settings",
|
|
|
|
|
title="Administer tenant lifecycle and settings",
|
|
|
|
|
summary="Tenancy adds explicit tenant creation, activation, context resolution, and tenant-owned settings over Core's shared scope storage.",
|
|
|
|
|
body="A tenant is a concrete administrative and data boundary. Tenant lifecycle changes must preserve ownership and recovery guarantees for module-owned records. Retirement and suspension retain data. Destructive erasure is a separate, provider-neutral workflow with a digest-bound preview, recent interactive authentication, exact slug confirmation, distinct approvals, resumable checkpoints, and final reconciliation before the Core scope is removed. Provider absence, timeout, stale evidence, tenant data without an erasure contribution, legal holds, retention requirements, external cleanup, backup expiry, and unknown outcomes remain visible and fail closed. Execution suspends access before the first provider step; cancellation is permitted only before destructive work begins. New tenants default to the German reference language unless the administrator selects another enabled system language; existing tenant and user preferences remain unchanged. Tenant administrators can inherit or override the system side-rail order and visibility and can lock entries visible for users; system locks remain effective. Personal navigation preferences still take precedence except that they cannot hide locked entries. Tenant appearance likewise inherits the system palette until explicitly selected; an unlocked tenant default permits a personal palette, while a policy-authorized tenant lock suppresses it and a system lock always wins. Resetting the tenant palette restores inheritance rather than copying the current system value. When the system permits advanced personal color overrides, a policy-authorized tenant administrator may inherit, allow, or block them; the tenant cannot enable a system-denied policy, and palette locks still suppress the editor. Advanced documents cover both light and dark modes and are validated atomically by Core. Navigation and appearance changes never grant module entitlement, View visibility, or permissions. Tenancy contributes system tenant management and tenant settings to the shared administration workspace; without this module, the Core and Access baseline can operate in single-scope compatibility mode. Core-reserved module entitlement settings are managed only through the Admin module's tenant-module policy endpoints and are preserved when generic tenant settings are replaced.",
|
|
|
|
|
body="A tenant is a concrete administrative and data boundary. Tenant lifecycle changes must preserve ownership and recovery guarantees for module-owned records. Retirement and suspension retain data. Destructive erasure is a separate, provider-neutral workflow with a digest-bound preview, recent interactive authentication, exact slug confirmation, distinct approvals, resumable checkpoints, and final reconciliation before the Core scope is removed. Provider absence, timeout, stale evidence, tenant data without an erasure contribution, legal holds, retention requirements, external cleanup, backup expiry, and unknown outcomes remain visible and fail closed. Execution suspends access before the first provider step; cancellation is permitted only before destructive work begins. New tenants default to the German reference language unless the administrator selects another enabled system language; existing tenant and user preferences remain unchanged. Tenant administrators can inherit or override the system side-rail order and visibility and can lock entries visible for users; system locks remain effective. Personal navigation preferences still take precedence except that they cannot hide locked entries. Tenant appearance likewise inherits the system palette until explicitly selected; an unlocked tenant default permits a personal palette, while a policy-authorized tenant lock suppresses it and a system lock always wins. Resetting the tenant palette restores inheritance rather than copying the current system value. When the system permits advanced personal color overrides, a policy-authorized tenant administrator may inherit, allow, or block them; the tenant cannot enable a system-denied policy, and palette locks still suppress the editor. Advanced documents cover both light and dark modes and are validated atomically by Core. Navigation and appearance changes never grant module entitlement, View visibility, or permissions. Tenancy contributes system tenant management and tenant settings to the shared administration workspace; without this module, the Core and Access baseline can operate in single-scope compatibility mode. Core-reserved module entitlement settings are managed only through the Admin module's tenant-module policy endpoints and are preserved when generic tenant settings are replaced. Opening lists and creation or edit dialogs does not save changes. If an authorized section reports a load failure, reload after deployment and report the frontend diagnostic; do not broaden permissions or recreate records to work around a render failure.",
|
|
|
|
|
documentation_types=("admin", "user"),
|
|
|
|
|
audience=("system_admin", "tenant_admin", "operator"),
|
|
|
|
|
related_modules=("access", "admin", "audit"),
|
|
|
|
@@ -183,6 +193,7 @@ manifest = ModuleManifest(
|
|
|
|
|
"Cores gemeinsamen Bereichsspeicher."
|
|
|
|
|
),
|
|
|
|
|
"body": (
|
|
|
|
|
"Das Öffnen von Listen sowie Anlage- oder Bearbeitungsdialogen speichert keine Änderungen. Meldet ein berechtigter Bereich einen Ladefehler, laden Sie nach der Bereitstellung neu und melden Sie die Oberflächendiagnose; erweitern Sie keine Berechtigungen und legen Sie keine Datensätze erneut an, um einen Darstellungsfehler zu umgehen. "
|
|
|
|
|
"Ein Mandant ist eine konkrete Administrations- und Datengrenze. Änderungen am Mandantenlebenszyklus müssen Eigentums- "
|
|
|
|
|
"und Wiederherstellungsgarantien für modulbezogene Datensätze bewahren. Ruhestand und Sperrung bewahren Daten. Die "
|
|
|
|
|
"destruktive Löschung ist ein eigener, anbieterneutraler Ablauf mit digestgebundener Vorschau, aktueller interaktiver "
|
|
|
|
|
zemion