Task: Make the demo tenant exercise the system
Table of Contents
This page documents a task in the Rework the market data feeds into a market data service with adapters — the remaining work story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
The role seeds grant every screen's permission to the roles that perform it, and Acme's users and data exercise every screen.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Rework the market data feeds into a market data service with adapters — the remaining work |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-26 |
3. Acceptance
- A matrix of screen, permission and role, with no screen unreachable by an appropriate human role.
- Acme has a user for each role and the data each screen lists.
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 |
|---|---|
| #3880 | [iam] Grant the screens' permissions to the roles the journeys name |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Measurements
| What | Value |
|---|---|
| Role grants added | 17, each tied to a screen card or a journey actor |
| Acme accounts | 65, with Member, Trading, Operations, Viewer, Sales, Support, TenantAdmin |
| Parties on distinct providers | ACMCOR bloomberg, ACCOUK demo, ACCOUS lseg, ACCOHK bloomberg |
| Adapter accepts | bloomberg 362 of 362, demo 71 of 71, lseg 14 of 14, zero rejects |
| Trades and requests | 60 each, 28 distinct requesters |
| Catalogue instruments | 447, generated from the feeds by the committed tool |
| Engine settings | 502 before the recreate, working after it |
| Ticks smoke | passed |
11. Result
Every screen a human role needs is reachable, and Acme exercises the system.
- The role seed holds the reads and writes the screens' cards and the journeys' actors name: Trading the synthetic and curve authoring, Operations the pricing engine and market-risk approval and subscriptions, Member the engine settings groups, with the earlier market data reads.
- The Acme profile entitles each party to its own provider and source, written by the subscribe step itself, so a recreate keeps the spread and every adapter accepts every demanded id.
- The trade population is entered by each party's own people, so a party user sees the party's requests. The group's treasurer carries the group's.
- The IR and FX catalogues are generated from the feeds, so a provider's catalogue is exactly what its feeds serve.
Open. The decision queue is empty for party personas because no party role holds the permission to decide a trading operational authorisation; the tenant administrator holds it and sees 52. The SuperAdmin screens stay with the platform administrator, as their journeys say.