Task: Read a tenant's parties from inside it
Table of Contents
This page documents a task in the Act inside a tenant story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
(Describe what user-visible-or-internal change this task produces.)
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Act inside a tenant |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-03 |
3. Acceptance
- The parties are read with refdata.v1.parties.list in the tenant's session, paged with a pager and the server total.
- refdata.v1.parties.list-of-tenant, its service, handler, tests, shell command and recipe are removed.
- The See one tenant journey says where the parties are read.
4. Plan
(Implementation strategy. Written when work starts; key decisions
are distilled into the parent story's * Decisions at close, but the
plan itself stays — it is the historical record of what we did.)
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
6. Notes
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
| #2535 | [web] Read a tenant's parties from inside it, a page at a time |
9. Review
| # | Comment summary | File | Decision | Notes |
|---|---|---|---|---|
| L1 | A parent on another page is not named | party-page.ts |
Decline | Party get and get_many key by short code and nothing reads by id, so naming it would mean reading every page. The list contract capture records the read it needs. |
| L2 | The parties page in key order, not by name | party-page.ts |
Decline | The generated service refuses a stated order; the list contract capture covers it. |
| R1.1 | Sign-out keeps the cached parties | SessionProvider.tsx |
Accept | Sign-out empties every cached read but the session, as entering and leaving do. |
| R1.2 | Query parsing accepts "" and "1e1" | server.ts |
Decline | Both are valid whole numbers after parsing, and anything else fails the schema with a 400. |
| R1.4 | The empty order needs a pointer to the capture | party-page.ts |
Accept | A comment names the capture. |
| #2525.1 | Two @startuml lines in the wireframe | wireframe_act_inside_a_tenant.puml |
Accept | Fixed here and in wireframe_see_one_tenant.puml, which had the same copy defect; both re-rendered. |
| #2525.2 | Settle the source of the read permissions, how read only is enforced, the claim, the BFF state, the audit and the refusals | journey_act_inside_a_tenant.org |
Accept | The journey states each, matching the code in #2533 and #2534; the audit is one row in the tenant's trail. |
| #2525.3 | The wireframe shows 1-3 of 5 beside three rows | wireframe_act_inside_a_tenant.puml |
Decline | It is the first page of five, with Next, which is what the screen shows. |
10. Result
refdata.v1.parties.list-of-tenant is removed with its model, service,
handler, registrar, tests, shell command, recipe and script, because a request
that names a tenant breaks the protocol's tenancy rule. GET /api/parties
pages the session's own parties through refdata.v1.parties.list with the
server total and refuses system administration, whose tenant the party policy
lets read every tenant's parties. The Parties screen pages them with the
pager the roster now shares, and entering a tenant lands on it. The tenant's
screen in system administration reads no party and points inside. Both tenancy
journeys say where the parties are read.
Tests: two wire cases, three BFF route cases, two screen cases, and the tenant screen's cases rewritten. Live, the parties of Acme read 2, 2 and 1 across three pages with a total of 5, and system administration was refused.