The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /console/{tenantId}/security/policies/new | Create a policy with explicit allow permissions and a deny pattern. | CAP-PFM-SEC-012 | The editor rejects an allow wildcard and accepts the tested deny wildcard. | test react-console:e2e/security/policies.spec.ts#refuses an allow rule that names a wildcard, and accepts it as a deny |
| 2 | /console/{tenantId}/security/roles/new | Compose a custom role from the selected policies. | CAP-PFM-SEC-012 | The role appears in the searchable list with its custom classification. | test react-console:e2e/security/roles.spec.ts#is on the Roles list, searchable, and marked custom |
| 3 | grantConsoleUserRole | Assign the new role to a colleague. | CAP-PFM-SEC-010 | The role’s Members tab includes that person. | test react-console:e2e/security/roles.spec.ts#is given to a person, who then shows on its Members tab |
| 4 | /console/{tenantId}/security/roles/{roleRef} | Edit the role and reload its page. | CAP-PFM-SEC-012 | The test observes the saved role change after reload. | test react-console:e2e/security/roles.spec.ts#is edited, and the change survives a reload |
| 5 | archiveSecurityRole | Archive the role after its assignments have been withdrawn. | CAP-PFM-SEC-012 | The archived role disappears from the active list. | test react-console:e2e/security/roles.spec.ts#is archived once nobody holds it, and leaves the active list |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | An existing built-in policy provides a useful starting point. | Duplicate it and edit the customer-owned copy. | The copy is editable while the shared built-in remains read-only. | test react-console:e2e/security/policies.spec.ts#shows a built-in policy read-only, and duplicates it into one that can be changed |
| failure | 5 | The role still has a holder. | Reject archive and display links to the holders. | The role remains available rather than being archived. | test react-console:e2e/security/roles.spec.ts#refuses to archive a role somebody still holds, and names them |
| failure | 4 | Another editor has already saved a new version. | Present the stale-save conflict and choose Reload. | The mock editor replaces local values with the saved version. | test react-console:e2e/mock/security-editor-bar.mock.spec.ts#a stale save is the bar's conflict, and Reload takes what was saved |
| Id | Statement | Provenance |
|---|---|---|
01 | Policy creation requires at least one permission in the rule before saving. | test react-console:e2e/security/policies.spec.ts#is created with a rule, and the rule has to name a permission |
02 | The policy’s usage view links the role that uses it. | test react-console:e2e/security/policies.spec.ts#is used by a role, and the policy says so |
03 | The role’s Members tab shows the person who receives its assignment. | test react-console:e2e/security/roles.spec.ts#is given to a person, who then shows on its Members tab |
End-to-end policy: required: Policy editing, role composition and member assignment span separate screens. Real-service browser tests must establish their agreement, with API rules tested independently and mock conflict behavior identified separately.