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/users | Invite the colleague from the Users page. | CAP-PFM-SEC-008 | The browser test observes an invited membership after submission. | test react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users screen |
| 2 | resendConsoleUserInvitation | Resend the outstanding invitation. | CAP-PFM-SEC-008 | The replacement link supersedes the previously issued link. | test react-console:e2e/security/invitations.spec.ts#resending from the console invalidates the link it replaces |
| 3 | /console/{tenantId}/security/users/{userId}/edit | Assign a role from the person’s page. | CAP-PFM-SEC-010 | The tested grant identifies its grantor and can subsequently be removed. | test react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it away again |
| 4 | /console/{tenantId}/security/users/{userId} | Edit the colleague’s profile information. | CAP-PFM-SEC-009 | The saved details remain after a page reload. | test react-console:e2e/security/users.spec.ts#edits a person's details and keeps them through a reload |
| 5 | suspendConsoleUser | Deactivate the membership, then reactivate it. | CAP-PFM-SEC-009 | The browser test observes rejected sign-in after deactivation and restored sign-in after reactivation; it does not measure already cached authority. | test react-console:e2e/security/users.spec.ts#deactivating really shuts somebody out, and reactivating lets them back in |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | The address already belongs to a membership. | Reject invitation creation and offer navigation to that person. | The administrator can open the existing membership. | test react-console:e2e/security/invitations.spec.ts#refuses to invite an address that already belongs to a user, and offers the user instead |
| alternate | 5 | The colleague leaves permanently. | Remove their access and later issue a new invitation if they return. | The browser test verifies that reinvitation works after removal. | test react-console:e2e/security/invitations.spec.ts#re-invites them after their access is removed, and the new link works |
| failure | 3 | The offered role exceeds the administrator’s authority. | Reject the grant and describe the missing permission. | No invitation message is sent by the rejected operation. | test services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#refuses a role that grants more than the caller may do there, and names what was missing |
| failure | 5 | The administrator tries to remove the final Administrator assignment. | Reject the removal. | The remaining administrator retains the role. | test react-console:e2e/security/users.spec.ts#refuses to remove the Administrator role from the last person who holds it |
| Id | Statement | Provenance |
|---|---|---|
01 | The Users invitation flow creates a membership shown as Invited. | test react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users screen |
02 | The person’s role grant displays its grantor and supports removal. | test react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it away again |
03 | The deactivation browser test refuses sign-in until reactivation; this is separate from profile persistence and gateway-cache timing. | test react-console:e2e/security/users.spec.ts#deactivating really shuts somebody out, and reactivating lets them back in |
End-to-end policy: required: The journey involves an administrator’s Security pages and a colleague’s invitation and sign-in. Browser proof must establish that interaction; cached request propagation remains a separately qualified rule.