Story: Account-party management and login
Table of Contents
This page documents a story in Sprint 13. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Add the multi-party login picker and the UI for managing account-party assignments. This is the future-story note from sprint 12's party-RLS work.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 13 |
| Now | Completed 2026-02-23. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2026-02-23 |
Continued from: Party-level RLS isolation (sprint 12). That story laid the schema + RLS + session plumbing and noted that the multi-party login picker was a future story; this is that story.
Acceptance
- Login picker handles single + multi-party accounts.
- AccountPartiesWidget covers add/remove.
- Server-side handlers in place.
- Initial admin auto-assigned to the system party.
- Protocol 38.0 (breaking).
- multi_party.org doc explains the flow.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Add account-party management and login support | DONE | 2026-05-20 | 2026-02-23 | Multi-party login: select_party_request/response messages; login_response carries available parties; AccountDetailDialog Parties tab + AccountPartiesWidget; server-side get_account_parties_by_account / save_account_party / delete_account_party handlers; ores_iam_account_parties_system_party_id_fn auto-assigns system party to initial admin; protocol 37 → 38 (breaking); multi_party.org doc. |
Decisions
- Server returns choices, client picks
- avoids client-side party knowledge before authentication.
- System party auto-assigned to initial admin
- closes the bootstrap chicken-and-egg.
Out of scope
- Party picker UX polish (deferred).
See also
- Party-level RLS isolation (sprint 12) — predecessor.