cabloy 5.1.159 → 5.1.160

package/.cabloy-version

@@ -1 +1 @@
-5.1.159
+5.1.160

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## 5.1.160
+
+### Features
+
+- Update feature capabilities
+
+### Improvements
+
+- Add documentation explaining shared RBAC architecture
+- Add system management guides
+- Document ZovaRender.column
+
 ## 5.1.159
 
 ### Features

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.159",
+  "version": "5.1.160",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [

package/repo-docs/.vitepress/config.mjs

@@ -287,6 +287,17 @@ export default defineConfig({
             { text: 'Validation Guide', link: '/backend/validation-guide' },
           ],
         },
+        {
+          text: 'System Management',
+          items: [
+            { text: 'User Management', link: '/backend/user-management' },
+            { text: 'Role Management', link: '/backend/role-management' },
+            { text: 'Department Management', link: '/backend/department-management' },
+            { text: 'Shared RBAC Architecture', link: '/backend/shared-rbac-architecture' },
+            { text: 'RBAC Authorization', link: '/backend/rbac-authorization' },
+            { text: 'Menu Authorization', link: '/backend/menu-authorization' },
+          ],
+        },
         {
           text: 'Application Basics',
           items: [

package/repo-docs/backend/department-management.md

@@ -0,0 +1,98 @@
+# Department Management
+
+Department Management maintains an instance's organizational hierarchy and its user memberships. Departments are not roles and are not tenant boundaries. They are trusted organizational facts that can later participate in Department-scoped RBAC decisions.
+
+> <Badge type="warning" text="Start specimen" /> The examples below are grounded in Cabloy Start's `admin-department` module. The Start tree/list page is one UI implementation; the hierarchy and membership invariants are the portable operational model.
+
+## Department and membership model
+
+A Department represents a node in an ordered hierarchy:
+
+| Department fact | Meaning                                                          |
+| --------------- | ---------------------------------------------------------------- |
+| `parentId`      | The parent organizational unit, or the root                      |
+| `sortOrder`     | Order among sibling Departments                                  |
+| `enabled`       | Whether the Department is active for operations and policy scope |
+| `managerId`     | The user currently designated as its manager                     |
+
+A Department membership relates one user to one Department and carries its own facts:
+
+| Membership fact | Meaning                                          |
+| --------------- | ------------------------------------------------ |
+| `position`      | Membership-specific organizational position      |
+| `enabled`       | Whether this membership is active                |
+| `primary`       | The user's primary enabled Department membership |
+
+A user may hold more than one Department membership. This is intentionally different from role membership: roles describe access groupings, while Departments describe organizational placement.
+
+## Tree administration
+
+The Start management surface supports Department CRUD, parent moves, sibling reordering, activation changes, manager assignment, and membership management.
+
+Keep these hierarchy invariants in the service layer:
+
+1. moving a Department must not create a cycle;
+2. a move must leave sibling ordering coherent;
+3. names must satisfy the configured sibling uniqueness rule;
+4. operations that would leave active children or invalid organizational relationships must be rejected; and
+5. tree changes must be serialized where concurrent ordering updates could conflict.
+
+The Start service uses a lock around ordered-sibling operations and verifies ancestry before a move. A frontend tree is useful for navigation, but it must not be the only place enforcing those rules.
+
+## Membership and manager rules
+
+Membership administration should preserve clear, durable facts:
+
+- a duplicate membership for the same user and Department is invalid;
+- at most one **enabled** membership is primary for a user;
+- a Department manager must be an enabled membership of that Department; and
+- before disabling or deleting a manager's membership, assign a replacement manager or clear the manager relationship according to the operation's explicit policy.
+
+These constraints explain why Department membership is managed as its own record rather than as an array embedded casually in a user profile.
+
+## Relationship to RBAC
+
+Department data becomes authorization input only when a protected action uses a Department-based scope.
+
+```text
+Department tree and enabled memberships
+  → RBAC policy resolution
+  → server-derived Department/user terms
+  → scoped query or entry check
+```
+
+For example, [RBAC Authorization](/backend/rbac-authorization) can use the current user's enabled primary Department, all enabled Department memberships, descendants of a Department, or explicit custom Departments. The Department service must invalidate relevant policy state after topology or membership changes so future requests do not evaluate a stale organizational scope.
+
+> [!NOTE]
+> The Vona instance remains the tenancy boundary. Department hierarchy is an organizational model inside that instance; it must not be used as a substitute for cross-instance isolation.
+
+## Source specimen
+
+Representative Start sources:
+
+- `vona/src/suite/cabloy-admin/modules/admin-department/src/controller/department.ts` — protected tree, membership, manager, move, reorder, and lifecycle endpoints.
+- `vona/src/suite/cabloy-admin/modules/admin-department/src/service/department.ts` — hierarchy/membership validation, manager constraints, ordering, and RBAC invalidation.
+- `vona/src/suite/cabloy-admin/modules/admin-department/src/entity/department.tsx` and `entity/departmentMembership.tsx` — persisted Department and membership facts.
+
+## Common mistakes
+
+- **Using Departments as roles.** Use [Role Management](/backend/role-management) for access-group membership.
+- **Trusting a client-supplied owner or Department in a scoped API.** RBAC must derive and check authoritative values on the server.
+- **Allowing a manager membership to disappear silently.** Enforce replacement/clearance rules in the mutation service.
+- **Using Department hierarchy as a tenant boundary.** Vona instance scoping remains mandatory.
+
+## Verification checklist
+
+1. Create root and child Departments, then verify ordering and parent relationships.
+2. Attempt an ancestor/descendant cycle and confirm it is rejected.
+3. Create multiple memberships for a user and verify the enabled-primary invariant.
+4. Attempt to disable or remove a manager's membership and confirm the configured manager safeguard applies.
+5. Change a Department/membership relevant to a scoped grant, then verify the next RBAC evaluation reflects the new topology.
+
+## Read next
+
+- [User Management](/backend/user-management)
+- [Role Management](/backend/role-management)
+- [RBAC Authorization](/backend/rbac-authorization)
+- [ORM Guide](/backend/orm-guide)
+- [Transaction Guide](/backend/transaction-guide)

package/repo-docs/backend/menu-authorization.md

@@ -0,0 +1,124 @@
+# Menu Authorization
+
+Menu Authorization controls **navigation disclosure**: which SSR menu leaves are returned to a caller for the active site. It does not grant controller, API, page, Resource, action, or data-scope access.
+
+> [!WARNING]
+> A menu association is never an authorization grant. Keep backend guards and RBAC policy on the protected route even when the menu is visible. See [RBAC Authorization](/backend/rbac-authorization) for action/data authority and [Menu Guide](/backend/menu-guide) for the shared SSR retrieval model.
+
+> <Badge type="warning" text="Start specimen" /> The dynamic role-menu administration examples below come from Cabloy Start's `admin-menu` module. Its SSR-site names, role editor, and refresh behavior are implementation details, not Basic UI guarantees.
+
+## Static menu eligibility
+
+An SSR menu item can declare `roles` metadata:
+
+```typescript
+@SsrMenu({
+  item: {
+    title: $locale('Operations'),
+    link: 'presetResource',
+    roles: ['systemAdmin'],
+  },
+})
+```
+
+The declaration determines whether a leaf participates in role-aware disclosure:
+
+| `roles` declaration | Static visibility                               | Dynamic role-menu configuration                      |
+| ------------------- | ----------------------------------------------- | ---------------------------------------------------- |
+| omitted             | Public to the menu audience                     | Not configurable                                     |
+| `[]`                | No static role makes it visible                 | Required for role-based visibility                   |
+| nonempty names      | Visible to a caller with any matching role name | Can additionally be disclosed through an association |
+
+The `roles` declaration is server-only metadata. It is removed from the public menu DTO and is not a frontend substitute for route authorization.
+
+## Role-to-menu associations
+
+A persisted association identifies a configurable SSR menu leaf for a role:
+
+```text
+roleId + ssrSiteName + ssrMenuName
+```
+
+The management service must validate all three parts against live menu metadata:
+
+- the role exists;
+- the target is a real site-bound leaf, not a group; and
+- the leaf declares `roles`, making it eligible for dynamic configuration.
+
+Public leaves and structural groups are intentionally not configurable. For keyed items, the runtime derives a stable menu-leaf identity from the menu declaration and item key.
+
+## Effective request-time visibility
+
+At retrieval time, Cabloy prepares menu structure for the current SSR site and locale, then filters it for the caller. The effective result is additive:
+
+```text
+static role-name visibility
+  OR
+persisted association held by any current role
+  → visible leaf in the SSR menu response
+```
+
+The system removes empty groups after leaf filtering and does not expose the private declaration metadata to the consumer.
+
+This union is about discoverability only. It must not be confused with frontend site admission or with Vona controller policy:
+
+```text
+siteIds            → may enter a frontend site
+menu authorization → may discover a navigation destination
+RBAC / Passport    → may execute a backend action
+RBAC data scope    → may affect this persisted row
+```
+
+## Administration workflow
+
+Role Management is normally the operator's entry point for configuring both action policy and navigation disclosure:
+
+```text
+choose a role
+  → configure RBAC grants for API/resource authority
+  → configure eligible SSR menu leaves for disclosure
+  → refresh affected current subjects
+  → verify direct API access independently
+```
+
+> <Badge type="warning" text="Start specimen" /> Cabloy Start registers the System Management group as `start-siteadmin:systemManagement` and presents a role-menu tree editor in the role detail. These names and layout are not a cross-edition contract. The stable contract is an SSR menu group with independently authorized backend operations.
+
+## Freshness after a menu-policy change
+
+Start records a separate menu-visibility revision when associations change. Its frontend model invalidates role-menu state and refreshes the application when the edited role belongs to the current Passport subject.
+
+This refresh matters because the frontend menu query is intentionally keyed by stable site/public-path/locale inputs, not by every role identity detail. It remains a UX freshness concern: route, Resource, controller, and API guards must still re-evaluate independently.
+
+## Source specimen
+
+Representative Start sources:
+
+- `vona/src/suite/cabloy-admin/modules/admin-menu/src/service/roleMenu.ts` — target validation, serialized role updates, association mutation, and revision changes.
+- `vona/src/suite/cabloy-admin/modules/admin-menu/src/bean/eventListener.menuVisibilityResolver.ts` — merging static visibility with current-role associations.
+- `vona/src/suite/cabloy-start/modules/start-siteadmin/src/bean/ssrMenuGroup.systemManagement.ts` — Start-specific System Management group registration.
+- `zova/src/suite/cabloy-admin/modules/admin-menu/src/model/roleMenu.ts` — Start client freshness behavior.
+
+The current Start role-menu editor protects `systemAdmin` from ordinary editing. Treat that as a Start UI safeguard and resolve any edition-specific policy rule from the active implementation/specification; do not infer an implicit administrative-menu bypass.
+
+## Common mistakes
+
+- **Using menu visibility to secure an API.** Always use a backend Passport/RBAC guard.
+- **Making public menu leaves configurable.** Only leaves that explicitly declare `roles` have dynamic role-menu eligibility.
+- **Expecting menu association to admit a role to a site.** Site admission is a separate `siteIds` decision.
+- **Assuming a menu refresh proves authorization.** Exercise the actual protected request and data-scope path.
+
+## Verification checklist
+
+1. Verify omitted, empty, and nonempty `roles` declarations produce the expected static/dynamic eligibility.
+2. Associate an eligible leaf with a role and verify a current holder receives the menu after refresh.
+3. Remove the association and verify the leaf disappears when no static role rule still exposes it.
+4. Attempt to configure a group or public leaf and confirm server validation rejects it.
+5. Attempt the destination's protected API with and without the appropriate backend grant; menu visibility must not change the result.
+
+## Read next
+
+- [Menu Guide](/backend/menu-guide)
+- [Role Management](/backend/role-management)
+- [RBAC Authorization](/backend/rbac-authorization)
+- [Navigation Guards Guide](/frontend/navigation-guards-guide)
+- [Admin Resource and Web Self-Service](/fullstack/admin-resource-and-web-self-service)

package/repo-docs/backend/rbac-authorization.md

@@ -0,0 +1,117 @@
+# RBAC Authorization
+
+RBAC Authorization decides whether a backend action is allowed and, for scoped actions, which persisted data the caller may reach. It is server-enforced action and data authorization.
+
+Read [Shared RBAC Architecture](/backend/shared-rbac-architecture) first for the shared Basic/Start `a-rbac` runtime, Resource permission projection, frontend matcher, SSR, and freshness model. This page focuses on the Cabloy Start operational policy specimen: roles, grants, Departments, and administration workflow.
+
+> [!WARNING]
+> RBAC is not authentication, SSR menu disclosure, or a frontend-button rule. A hidden action may improve UX, but every direct Vona request must pass the backend guard and, when applicable, the server-side data-scope check.
+
+> <Badge type="warning" text="Start specimen" /> This guide uses Cabloy Start's `admin-rbac` configuration module and `a-rbac` runtime path. Editions can compose the administration UI differently without weakening the backend decision model.
+
+## The protected-action model
+
+A controller opts an action into dynamic RBAC with `@Passport.rbac(...)` metadata. A representative scoped action looks like this:
+
+```typescript
+@Web.get()
+@Passport.rbac({ dataScope: true })
+async select(...) {
+  return await this.scope.service.record.select({
+    where: this.ctx.rbacScopeCurrent.where(where),
+  });
+}
+```
+
+The exact decorator options depend on the action contract. The important rule is that protected controllers consume the resulting request-local scope instead of treating guard admission as a complete row-level decision.
+
+The runtime chain is:
+
+```text
+cataloged route action
+  → current Passport role IDs
+  → enabled role/action grants
+  → allowed policy terms
+  → typed scope operations in the controller
+  → ORM query filter or persisted-entry check
+```
+
+For updates, views, and deletes, use the appropriate scope operation such as `checkEntry(...)` or `checkEntries(...)`. For creates, derive trusted owner/Department values with `ownerValues()` rather than accepting values that can widen a client request.
+
+## Role, action, and scope grants
+
+A grant binds a role to a stable catalog action and a compatible data scope:
+
+```text
+roleId + actionKey + dataScope + enabled
+```
+
+The catalog comes from routes decorated with `@Passport.rbac(...)`; ordinary routes do not become dynamic RBAC actions merely because they are visible in a UI. The Start catalog also supports controlled action inheritance, validated centrally to reject missing targets and cycles.
+
+Multiple enabled grants held through the current user's roles combine as a union. A caller-provided query filter remains additionally constrained by the server scope, rather than replacing it.
+
+## Data scopes
+
+The Start specimen supports these five scopes:
+
+| Scope                         | Effective data boundary                                        |
+| ----------------------------- | -------------------------------------------------------------- |
+| `all`                         | All records within the active Vona instance                    |
+| `customDepartments`           | Records belonging to explicitly configured enabled Departments |
+| `ownDepartment`               | Records in the caller's enabled Department scope               |
+| `ownDepartmentAndDescendants` | Caller Department scope plus enabled descendants               |
+| `mine`                        | Records owned by the current user                              |
+
+`all` dominates narrower terms. Department-aware terms depend on enabled memberships and enabled Department topology; descendant expansion must be cycle-safe. A non-data-scoped action accepts only the scope compatible with its catalog definition.
+
+Departments are inputs to the policy, not alternative authorization stores. Read [Department Management](/backend/department-management) before designing Department-scoped grants.
+
+## Runtime authority and frontend projections
+
+Resource permissions are derived from the same guards to support frontend action visibility. They are UX projections, not a second grant database and never the final authority:
+
+```text
+frontend permission projection → UX decision
+backend RBAC guard/scope       → authoritative decision
+```
+
+For the shared guard simulation, projection contract, matcher semantics, SSR behavior, and active-tab freshness limitation, read [Shared RBAC Architecture](/backend/shared-rbac-architecture). This distinction prevents stale browser state, crafted requests, and hidden-button assumptions from becoming security vulnerabilities.
+
+## Policy freshness
+
+A grant change, role-membership change, Department-membership change, or Department-topology change can affect later policy resolution. The Start implementation emits `a-rbac:policyInvalidated`, advances policy revision state, and clears dependent permission caches after the relevant transaction commits.
+
+Treat this as a dependency graph: source mutations must refresh every warmed policy or permission projection that depends on them. Do not hand-patch a browser cache while leaving the server policy stale.
+
+## System-administrator safeguards
+
+The Start grant service/editor excludes `systemAdmin` from ordinary grant management, and its scope adapter treats that subject as unrestricted for the RBAC decision path. These are explicit Start operational safeguards, not a guarantee that every Cabloy edition exposes the same UI or management rule.
+
+Whatever the edition, protect administrator transitions deliberately and ensure the final backend decision remains explicit, testable, and server-owned.
+
+## Source specimen
+
+Representative Start sources:
+
+- `vona/src/suite/cabloy-admin/modules/admin-rbac/src/lib/rbacPolicy.ts` — scope compatibility and action inheritance rules.
+- `vona/src/suite/cabloy-admin/modules/admin-rbac/src/service/rbacPolicy.ts` — role/grant lookup and Department/user-term resolution.
+- `vona/src/suite/cabloy-admin/modules/admin-rbac/src/service/rbacGrant.ts` — mutation validation and invalidation.
+- `vona/src/suite-vendor/a-cabloy/modules/a-rbac/src/bean/guard.rbac.ts` and `bean.rbacScope.ts` — guard-time decision and typed scope consumption.
+
+## Verification checklist
+
+1. Confirm an unauthenticated or ungranted caller is denied for every opted-in action.
+2. Test each supported scope with persisted data, not only a frontend visibility assertion.
+3. Verify forged owner/Department values cannot widen create, update, view, delete, or bulk operations.
+4. Grant two scopes through multiple roles and confirm their permitted terms combine as expected.
+5. Change a grant, role membership, or Department topology and verify subsequent server decisions and frontend projections refresh.
+6. Verify a visible menu or button never makes an ungranted direct API request succeed.
+
+## Read next
+
+- [Shared RBAC Architecture](/backend/shared-rbac-architecture)
+- [Role Management](/backend/role-management)
+- [Department Management](/backend/department-management)
+- [Menu Authorization](/backend/menu-authorization)
+- [Controller AOP Guide](/backend/controller-aop-guide)
+- [Permission FormScene and Action Visibility Guide](/frontend/permission-formscene-action-visibility-guide)

package/repo-docs/backend/resource-field-update.md

@@ -113,7 +113,7 @@ A resource list can search and order a relation by a human-readable column from
 studentId: TableIdentity;
 ```
 
-`table` and `joinOn` identify the relation, while `originalName` resolves both the `studentId` filter and order key to `trainingStudent.name`. `_includesI_` makes the filter a case-insensitive partial-name match. `ZovaRender.column({ enableSorting: true })` exposes the sortable table column; the query pipeline uses the same field metadata to add the join and rewrite `orders: [['studentId', 'asc']]` to the related display column.
+`table` and `joinOn` identify the relation, while `originalName` resolves both the `studentId` filter and order key to `trainingStudent.name`. `_includesI_` makes the filter a case-insensitive partial-name match. `ZovaRender.column({ enableSorting: true })` is the shared Cabloy Basic/Start frontend eligibility declaration for a sortable table header; it does not by itself authorize or resolve the backend order key. The order schema and query metadata remain authoritative, and the query pipeline uses the same field metadata to add the join and rewrite `orders: [['studentId', 'asc']]` to the related display column. For the complete table-column contract and resource-page sort path, see [Table Guide](/frontend/table-guide#configure-physical-columns-with-zovarendercolumn).
 
 Use `innerJoin` deliberately when the relation is required and unmatched rows should not participate in this filter/order path. For an optional relation whose unmatched rows must remain visible, choose the join behavior explicitly instead of copying the required-relation example.
 
@@ -154,7 +154,7 @@ A custom backend-rendered field normally needs both sides of the frontend pair:
 
 A plain frontend component is not sufficient for backend table-cell metadata. Reuse the closest shared renderer’s option/data flow and keep the customization focused.
 
-For public implementation patterns, see [Form Guide](/frontend/form-guide), [TableCell Cookbook](/frontend/table-cell-cookbook#pattern-7-backend-contract-to-frontend-cell-handoff), and the Basic-only [Custom Form/Table Renderers tutorial](/fullstack/tutorial-4-custom-level-renderers).
+For public implementation patterns, see [Form Guide](/frontend/form-guide), [TableCell Authoring Cookbook](/frontend/table-cell-cookbook#pattern-7-backend-contract-to-frontend-cell-handoff), and the Basic-only [Custom Form/Table Renderers tutorial](/fullstack/tutorial-4-custom-level-renderers).
 
 ## Follow the contract loop
 

package/repo-docs/backend/role-management.md

@@ -0,0 +1,92 @@
+# Role Management
+
+Role Management defines reusable access groupings and assigns them to users. A role is the common subject for several access-related systems, but those systems remain independent:
+
+| Role relationship      | What it controls                            | Does not control         |
+| ---------------------- | ------------------------------------------- | ------------------------ |
+| `siteIds`              | Admission to a frontend SSR site            | Individual API actions   |
+| RBAC grants            | Backend action and data-scope authorization | Menu disclosure          |
+| Role-menu associations | Navigation disclosure                       | Controller or API access |
+
+> <Badge type="warning" text="Start specimen" /> The Cabloy Start `admin-role` module is the source specimen. Its role-detail tabs are an edition-specific UI composition; the three policy domains above are the durable model.
+
+## Role lifecycle
+
+The Start role controller supports role CRUD and user-role membership management. The role service validates role names and validates configured `siteIds` against enabled SSR sites.
+
+A role should therefore be created with a clear operational purpose:
+
+```text
+Role name and title
+  → eligible frontend sites
+  → users who hold the role
+  → action/data grants, when needed
+  → navigation disclosure, when needed
+```
+
+Creating a role or assigning it to a user does not automatically create RBAC grants or menu assignments. Configure those policy domains deliberately after the role exists.
+
+## Assign roles to users
+
+A user can hold multiple roles. Ordinary membership replacement belongs to Role Management because it changes an access grouping, even though the affected user is visible in User Management.
+
+The Start specimen preserves an existing `systemAdmin` membership during ordinary replacement and excludes it from the usual candidate flow. Dedicated protected operations handle system-administrator transitions instead.
+
+> [!WARNING]
+> Treat built-in and administrator roles as protected operational identities. Do not implement a generic role form that can rename or delete them, and do not make the last usable system administrator removable or disableable.
+
+## Site admission is a coarse boundary
+
+A role's `siteIds` determines whether a current role may enter a frontend site. It is a coarse admission check, not proof that the role may execute every action once it is inside.
+
+```text
+site admission
+  → menu disclosure
+  → frontend action visibility
+  → backend API guard
+  → data-scope enforcement
+```
+
+Each later layer remains responsible for its own decision. In particular, a role admitted to an Admin site still needs a passing backend guard for every protected request.
+
+## Role as the configuration hub
+
+The Start Role Resource embeds two separate editors in its entry view:
+
+- **Resource Permissions** configures action/data policy through `admin-rbac`.
+- **Menu Authorization** configures SSR navigation disclosure through `admin-menu`.
+
+This is a useful operator workflow, but not a claim that every Cabloy edition must use the same route, tabs, component identifiers, or UI library. The important design is that the editors update different persistence and runtime-policy paths.
+
+## Source specimen
+
+Representative Start sources:
+
+- `vona/src/suite/cabloy-admin/modules/admin-role/src/controller/role.ts` — protected role and membership endpoints.
+- `vona/src/suite/cabloy-admin/modules/admin-role/src/service/role.ts` — name/site validation, built-in-role safeguards, membership replacement, and policy invalidation.
+- `vona/src/suite/cabloy-admin/modules/admin-role/src/dto/roleView.tsx` — edition-specific composition of the two authorization editors.
+
+Role changes that affect memberships must invalidate dependent RBAC policy state. The next request must resolve current roles and policy rather than relying on an old browser projection.
+
+## Common mistakes
+
+- **Using a role name as a substitute for every action grant.** Use [RBAC Authorization](/backend/rbac-authorization) for protected resource/API actions.
+- **Treating menu assignment as API authorization.** A role-menu association only changes discoverability; see [Menu Authorization](/backend/menu-authorization).
+- **Putting Department facts on a role.** Departments describe organizational membership and supply some RBAC scopes; see [Department Management](/backend/department-management).
+- **Changing role membership from a client-only cache.** Membership mutation must pass through backend validation and invalidation.
+
+## Verification checklist
+
+1. Confirm built-in roles cannot be deleted or renamed.
+2. Confirm only valid enabled SSR sites may be assigned to a role.
+3. Assign and remove an ordinary role, then verify the user's next access evaluation uses the new membership.
+4. Verify system-administrator changes use the edition's dedicated safeguards.
+5. Verify RBAC and menu assignments remain separate before and after role edits.
+
+## Read next
+
+- [User Management](/backend/user-management)
+- [RBAC Authorization](/backend/rbac-authorization)
+- [Menu Authorization](/backend/menu-authorization)
+- [Menu Guide](/backend/menu-guide)
+- [User Access Guide](/backend/user-access-guide)