Story: Party-level refdata restrictions
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
Lay the framework for per-party visibility of currencies + countries; junction tables in place but full enforcement deferred.
Status
| Field | Value |
|---|---|
| State | BACKLOG |
| Parent sprint | Sprint 13 |
| Now | Postponed in sprint 13; carried forward. |
| Waiting on | A sprint with the slot. |
| Next | Return to this once a sprint has the budget. |
| Last touched | 2026-02-28 |
Acceptance
- party_currencies + party_countries junction tables.
- Full stack via codegen (domain + repo + service + tests).
- Service-layer list_*_for_party methods.
- Bitemporal support.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Add party-level currency and country restrictions (framework) | BACKLOG | 2026-05-20 | ores_refdata_party_currencies_tbl + ores_refdata_party_countries_tbl junction tables to control per-party visibility; full stack via codegen (domain + repo + service + test); currency_service / country_service grow list_currencies_for_party / list_countries_for_party; bitemporal support. |
Decisions
- Framework now, enforcement later
- gets us a feel for party-level RLS at the refdata layer without paying the full implementation cost.
Out of scope
- UI + protocol enforcement (carried forward).
See also
- Party-level RLS isolation (sprint 12) — the broader RLS framework this extends.