ab-ecosystem-sso 0.2.0 → 0.3.0

package/README.md

@@ -523,11 +523,39 @@ openAccountSettings({
 });
 ```
 
-- **Members** — list active or revoked members; edit a member's role and access expiry; revoke access. Revoking leaves their login alone: only this account becomes unreachable, from their next request onward, and re-inviting the same person restores the membership.
+- **Members** — for an **owner**, list active or revoked members; edit a member's role and access expiry; revoke access. Revoking leaves their login alone: only this account becomes unreachable, from their next request onward, and re-inviting the same person restores the membership.
 - **Roles** — create, edit and delete roles with a permission list (one per line). The server trims, uppercases, dedupes and sorts permissions (max 200), and they aren't validated against a catalogue yet, so a misspelled string simply grants nothing. **System** roles are assignable but neither editable nor deletable, and a role still held by anyone can't be deleted.
 - **Invitations** — create invites (email, member/user, role, access expiry), filter by status, and revoke pending ones. After creating one, the link is shown **once** with a copy button — the token is never returned again and no email is sent.
 
-Every endpoint behind these is **owner-only**. A non-owner gets `"Only the account owner can do this"`, which the sections display as-is rather than guessing at permissions client-side. Pass `isOwner={false}` to hide the tabs outright.
+### Owners and members see different things
+
+The modal works out which side the signed-in person is on from `context.act` in `GET /me`, and renders accordingly — no prop needed:
+
+| | Members | Roles | Invitations |
+| --- | --- | --- | --- |
+| **Owner** | full administration | ✅ | ✅ |
+| **Team member** | their team, read-only | hidden | hidden |
+
+A member's **Members** tab lists their colleagues and each one's role from `GET /account/team`, headed by which account they're in and the role they hold themselves. Roles and Invitations are hidden for them rather than shown and then refused — those endpoints are owner-only and would answer `"Only the account owner can do this"`, which the owner-side sections still display as-is if a non-owner ever reaches them.
+
+Detection is deliberately cautious: only an explicit `act` of `"member"` or `"user"` counts as a member. An unrecognised value, or no `context` at all, is treated as the owner — the behaviour from before per-member sessions existed. Override it with `isOwner` if you already know, and hide the three sections entirely with `showTeamSections={false}`.
+
+### Account context
+
+The same `context` block is useful outside the modal — it says which account the session is in, the member's role, and what that role grants:
+
+```ts
+import { getAccountContext, hasPermission } from "ab-ecosystem-sso";
+
+const ctx = await getAccountContext(projectId);
+// { accountId, act, isOwner, role: { id, title, version }, permission,
+//   accessExpiry, accountName, accountEmail } — or null when there's no context
+
+if (!ctx?.isOwner) showMemberUi(ctx?.role?.title);
+if (hasPermission(ctx, "CHAT.TRANSFER")) enableTransfer();
+```
+
+`hasPermission` is case-insensitive, passes owners everything, and returns `true` when there's no context — so it degrades to "unrestricted" rather than locking people out of an app that hasn't adopted roles yet. Permission strings aren't validated against a catalogue server-side, so a misspelled one simply never matches.
 
 The three panels are also exported for use in your own admin page:
 
@@ -597,7 +625,8 @@ const [open, setOpen] = useState(false);
 | `syncUrlHash` | `boolean` | Mirror open state + active section in the URL hash. Default `true`. See [URL hash & refresh](#url-hash--refresh). |
 | `title` | `string` | Modal heading. Default `"Settings"`. |
 | `mode` | `"light" \| "dark"` | Colour scheme. Default `"light"`. See [Light & dark mode](#light--dark-mode). |
-| `isOwner` | `boolean` | Pass `false` to hide the Members / Roles / Invitations sections. Omitted ⇒ shown, and the API refuses non-owners with its own message. |
+| `isOwner` | `boolean` | Overrides owner-vs-member detection. Omitted ⇒ read from `context.act` in `GET /me`. |
+| `showTeamSections` | `boolean` | `false` hides Members / Roles / Invitations entirely. Default `true`. |
 | `inviteLinkBase` | `string` | Where invite links point; the token is appended as `?token=…`. Default `<origin>/accept-invite`. |
 | `onAccountSwitch` | `({ accessToken, accountId }) => void` | Enables the **Accounts** switcher. Store the fresh token in place of the old one. |
 | `currentAccountId` | `string` | Marked "Current" in the switcher. |
@@ -893,6 +922,8 @@ Beyond the components, these functions are exported for building custom UIs:
 | `listRolesApi` · `createRoleApi` · `updateRoleApi` · `deleteRoleApi` | `/account/roles` (owner only) |
 | `listInvitationsApi` · `createInvitationApi` · `revokeInvitationApi` | `/account/invites` (owner only) |
 | `listMembersApi` · `updateMemberApi` · `revokeMemberApi` | `/account/members` (owner only) |
+| `listTeamApi(projectId, token?, apiBaseUrl?)` | `GET /account/team` → `TeamMember[]` — the caller's colleagues, for a **member** |
+| `getAccountContext(projectId, token?, apiBaseUrl?)` | `GET /me` → `AccountContext \| null` (owner vs member, role, permissions) |
 | `validateSession(projectId, token, apiBaseUrl?)` | `GET /me` → `{ valid, accountAccessLost, message, code }` |
 | `logout(options)` | `POST /auth/logout` + callbacks |
 | `logoutApi(projectId, token, apiBaseUrl?)` | `POST /auth/logout` |
@@ -917,7 +948,8 @@ import type {
   AccountOption, SelectAccountRequest, AccessTokenResponse, InvitationLookup, SessionValidation,
   Role, CreateRolePayload, UpdateRolePayload,
   Invitation, InvitationStatus, CreateInvitePayload, CreatedInvite,
-  Member, MemberStatus, UpdateMemberPayload,
+  Member, MemberStatus, UpdateMemberPayload, TeamMember,
+  AccountContext, AccountRoleRef,
   TokenStorageConfig, TokenStorageKind,
   AuthFetchInit, AuthHandlers, AuthInterceptorOptions, UnauthorizedInfo,
   SsoRoutePaths, SsoScreen, SsoRouteMatch, SsoRouteObject,