tegwick
1c7634c7ce
fix-consistency registered the account situational-awareness plan and its three tasks. Assistant: grok Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f
123 lines
5.1 KiB
Markdown
123 lines
5.1 KiB
Markdown
---
|
|
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]
|
|
state_hub_workstream_id: "2d182130-88d0-5b17-b2bf-3e28f5df4f37"
|
|
---
|
|
|
|
# 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
|
|
state_hub_task_id: "ffc8f42f-5ca3-56a2-8850-d2da9beba72c"
|
|
```
|
|
|
|
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 <tenant>"
|
|
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
|
|
state_hub_task_id: "136a27ff-fd3e-5f0a-8a3a-bb080f1965d5"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "4c9b0600-5034-58ce-9b02-90a040f6f65f"
|
|
```
|
|
|
|
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.
|