The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /acceptInvite?token=… | Open the invitation message’s link. | CAP-PFM-SEC-005 | The acceptance page displays organization information and a masked email before sign-in. | test react-console:e2e/dev/invitations.dev.spec.ts#shows who invited them, then sets their password and opens the console |
| 2 | acceptInvitation | Accept with a password that satisfies policy. | CAP-PFM-SEC-005 | The tested password acceptance activates the account. | test services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#accepts the e-mailed token with a password and makes the account active (the invite created the account before it sent the link) |
| 3 | getMySecurityContext | Request the current security context as the console loads. | CAP-PFM-SEC-007 | The backend response identifies the caller, organization, reachable workspaces and evaluated default workspace. | test services-platform:modules/security/tests/e2e/security-context.e2e.spec.js#answers the caller, their organization and the tenants they reach, with the default tenant evaluated |
| 4 | /console/{tenantId} | Use an application from the console. | CAP-PFM-SEC-007 | The tested create action appears for Administrator and is absent for Read Only. | test react-console:e2e/dev/permissions.dev.spec.ts#offers the administrator an action it does not offer the read-only user |
| 5 | /login | Visit a protected page after signing out, then sign in. | CAP-PFM-SEC-006 | The login return flow restores the originally requested page. | test react-console:e2e/dev/session.dev.spec.ts#sends a signed-out visitor to the login screen and back to the page they wanted |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | A resend replaced the opened invitation. | Show the replacement-link guidance. | The browser directs the person to the latest invitation message. | test react-console:e2e/dev/invitations.dev.spec.ts#sends somebody to their newest e-mail when a resend superseded the link they opened |
| alternate | 3 | The authenticated person has no role. | Display No Access when context cannot provide access. | The person can sign out without a repeated login redirect. | test react-console:e2e/dev/permissions.dev.spec.ts#shows a person with no role the No Access screen, and does not loop back to the login screen |
| failure | 1 | The invitation has expired. | Show expiry guidance on the acceptance page. | The person is told how to request another invitation. | test react-console:e2e/controlled/invitation-expired.controlled.spec.ts#tells somebody their invitation has expired, and what to do about it |
| failure | 2 | The browser already holds another person’s console session. | Require that session to be signed out before acceptance. | The invitation is not accepted in that other session. | test react-console:e2e/dev/invitations.dev.spec.ts#refuses to accept an invitation while somebody else's console is on the screen |
| Id | Statement | Provenance |
|---|---|---|
01 | The acceptance browser flow shows invitation information, sets the password and opens the console. | test react-console:e2e/dev/invitations.dev.spec.ts#shows who invited them, then sets their password and opens the console |
02 | The tested acceptance permits sign-in and removes the membership from the Invited filter. | test react-console:e2e/security/invitations.spec.ts#lets them set a password and sign in, and clears them off the Invited filter |
03 | The access browser test observes a changed available action after a role change. | test react-console:e2e/security/access.spec.ts#a role change alters what somebody can actually do |
End-to-end policy: required: Acceptance, authentication and console permissions cross public and protected screens. Backend tests establish individual rules; real-service browser evidence is required for the combined path.