Task: Walk each role through its journeys
Table of Contents
This page documents a task in the Give a person's token the permissions they hold story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
Prove against the running deployment that every role a person can hold meets the refusals its grant calls for and no others, now that tokens carry their permissions and an empty list refuses, and record the matrix in the story.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Give a person's token the permissions they hold |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-03 |
3. Acceptance
- Each person role is signed in and walked through the same routes.
- Every refusal matches the role's grant, and every failure that is not a refusal is fixed or captured.
- The story holds the permission matrix as an org table.
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 |
|---|---|
| #2567 | [agile] Walk each role and record the permission matrix |
9. Review
| # | Comment summary | File | Decision | Notes |
|---|---|---|---|---|
| #2565.1 | Share the party-choice audience as one constant | jwt_claims.hpp |
Accept | party_selection_audience, used by the signer, the refresh rule, party selection, party switching and the request context. |
| #2565.4 | Say that a missing verifier yields the service's own context | request_context.hpp |
Accept | The documentation says so, and that no production service runs without one. |
| #2565.5 | Test that a workspace scope keeps the list | handler_helpers_tests.cpp |
Accept | Added. |
10. Result
Five accounts, one per narrower person role, were created in Acme with
evidence/walk_setup.mjs, and evidence/walk_roles.py signed in as each role
and both administrators and called the same twelve routes. The matrix is in
the story's Permission matrix section. Every refusal matches the role's grant,
and no role holding a permission was refused it.
The walk turned up three failures that are not refusals:
GET /api/change-reasonsanswered 502 for every role, because the BFF sent the request without itsorderfield and the server's decoder requires every field. Fixed here: the request is the generated type, and a test pins its body; removing the field fails the test. It now answers 200 for every role.- SuperAdmin's lock of an Acme account answers success but changes nothing, because row-level security keeps the system session out of the tenant's rows. Captured.
- Reading a session that still has to choose a party answers 500. Captured.
This task also carries the three review follow-ups from #2565, recorded in the
Review table. ctest passes the service, security and iam suites. The web
service logs to the journal already: its unit sets no redirection and the BFF
logs JSON to stdout; the file ores.web.service.0.log under the log directory
is left over from an earlier run and nothing writes it now.