From 2c80ba4526a64f3d1b1dfb1edf947a89f01f0b63 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 26 Sep 2026 20:31:15 +0200 Subject: [PATCH] Add USER-WP-0036 for account situational awareness. The account page currently presents the token tenant as membership. This plan separates login state, active sign-in, and allowed memberships. Assistant: grok Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f --- ...R-WP-0036-account-situational-awareness.md | 119 ++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 workplans/USER-WP-0036-account-situational-awareness.md diff --git a/workplans/USER-WP-0036-account-situational-awareness.md b/workplans/USER-WP-0036-account-situational-awareness.md new file mode 100644 index 0000000..5fd1134 --- /dev/null +++ b/workplans/USER-WP-0036-account-situational-awareness.md @@ -0,0 +1,119 @@ +--- +id: USER-WP-0036 +type: workplan +title: "Show allowed and active access on the account page" +domain: communication +repo: user-engine +status: ready +flavor: extension +owner: grok +topic_slug: user-engine +created: "2026-09-26" +updated: "2026-09-26" +related: [USER-WP-0026, USER-WP-0028] +--- + +# USER-WP-0036 - Account situational awareness + +The signed-in account page mixes three different facts. The verified token +names the tenant this sign-in is using. A portal membership row is access the +portal has recorded. A tenant account written on first sign-in is neither. + +On 2026-09-26 a directory sign-in for `tenant:trial:demo-company` had a portal +tenant account, no membership rows, and company admission from the directory +group on the token. The account page showed that token tenant under "Tenant +access" and then "No tenant memberships yet." Workload access listed nothing, +because the page only reads memberships whose scope is an application, +service, workload, or asset. The company application does not consult that +list. + +A person may hold access to more than one tenant and more than one workload. +An ordinary session uses one tenant at a time. Vendor roles, administrators, +and a person hired by more than one vendor may have more than one tenant +active, and each active tenant stays visible. Allowed access and active +access are both shown. Login state is shown separately from either list. + +Allow, deny, and unavailable workload decisions stay with USER-WP-0026-T03 +and USER-WP-0028-T02. This plan does not infer those decisions. + +## Separate login state, active access, and allowed access + +```task +id: USER-WP-0036-T01 +status: todo +priority: high +``` + +On `/onboarding`, and in the signed-in home identity block, present three +labelled situations in ordinary language. + +Login state names the verified portal identity, or says the portal session is +absent. Say that this is the portal session and that an application can keep +its own session. Do not infer identity from the URL. + +Active now is this verified token: its tenant, roles, and directory groups. +An ordinary session has one active tenant. A tenant administrator, +platform operator, platform root, vendor role, or multi-hire membership may +have more than one tenant active, and each one is marked. Until the account +carries one of those exception roles, show a single active tenant. Do not +invent a new role catalogue to detect the exception. + +Allowed access is portal membership rows for this user. A tenant membership +shows the tenant and kind. A workload membership is only a row whose scope is +application, service, workload, or asset. An empty list says that nothing is +recorded. A tenant account created on first sign-in is not a membership. The +token tenant is not repeated as a membership. Remove the "Viewing " +line that currently does that. + +A workload with no catalogue decision is "not checked." That is neither +access nor a denial. Do not copy a successful application login, a directory +group, a platform role, or a tenant account into a membership to fill the +list. + +The observed case renders as: signed in, one active tenant taken from the +token, no allowed tenants, no allowed workloads, workload decisions not +checked. Keep the layout readable on a phone. + +## Change the active tenant only through sign-in + +```task +id: USER-WP-0036-T02 +status: todo +priority: high +``` + +An ordinary user changes the active tenant through the existing +reauthentication handoff, `/login?tenant_hint=`. The identity provider +replaces the token tenant. After return, the page shows that tenant as the +only active one and leaves other allowed memberships inactive. + +An exception role may show more than one active tenant. Those tenants still +come from verified sign-in context. Do not add a control that marks a second +tenant active inside the portal session alone. Recognize only roles and +membership kinds the account already stores: `tenant-admin`, +`platform-operator`, `platform-root`, and a vendor or multi-hire kind when +one is already recorded. + +Switching tenant does not claim to end application sessions. The existing +sign-out copy remains the place that explains a remaining shared sign-in. + +## Record the journey and prove the three situations + +```task +id: USER-WP-0036-T03 +status: todo +priority: medium +``` + +Update `docs/account-journeys.md` U01 and U09 so login state, active access, +and allowed access are the contract. U10 keeps explicit reauthentication as +the tenant switch. + +Add portal tests for signed-out, a token tenant with no membership, an +allowed tenant that is not active, a recorded workload membership, and an +exception role whose verified context has two active tenants. Assert that a +tenant account alone does not appear as allowed access, and that an absent +catalogue decision renders as not checked. + +Do not close USER-WP-0026-T03 or USER-WP-0028-T02 from this plan. They remain +the owners of allow, deny, and unavailable workload decisions.