Story: Build approval requests and notifications
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
One component, ores.inbox, holds the approval requests and the notifications as designed: a relational schema generated from codegen models, with the rules the schema can carry — the one-approval-per-person index, the failed-delivery reason check and the four-eyes trigger — and the notification models generated with it. The service answers the approval and notification operations (PR #2652); the role request as the first kind, and its screens, split to Complete the ores.inbox approvals and notifications at the sprint 26 close on 2026-10-05.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-05 |
On 2026-10-05, at the sprint 26 close, this story was reworded to what it delivered and closed DONE: ores.inbox is a standard codegen component, the approval and notification tables match the accepted schema, and the service answers the approval and notification operations (PR #2652). The remainder is Complete the ores.inbox approvals and notifications, and its two tasks moved there.
3. Acceptance
- ores.inbox is a standard codegen component: overviews, generated CMake, C++, SQL, protocol and web types.
- The approval and notification tables match the accepted schema, with keys and foreign keys and no JSON.
- The service answers the approval lifecycle and the notifications: raise, withdraw and decide a request, the queue and one's own requests, one's own notifications, the unread count, mark read and clear.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Build approval requests and notifications | DONE | 2026-10-04 | 2026-10-04 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Scaffold the ores.inbox component | DONE | 2026-10-04 | 2026-10-05 | The ores.inbox composite with api, core, service and shell parts, and the codegen fixes the new component exposed. |
| Model the approval requests | DONE | 2026-10-04 | 2026-10-05 | Codegen models for the approval kinds, request states, decision types, hold reasons, requests and decisions in ores.inbox, with keys, foreign keys and the four-eyes check. |
| Model the notifications | DONE | 2026-10-04 | 2026-10-05 | Codegen models for the notification kinds, channels, notifications, arguments, recipients, deliveries with the outcome enum, and preferences in ores.inbox. |
| Serve approvals and notifications | DONE | 2026-10-05 | 2026-10-05 | The ores.inbox service operations: raise, withdraw and decide a request, the queue and one's own requests; raise a notification to people or a permission, list one's own, the unread count, mark read and clear, and live arrival. |
5. Decisions
- System lookups are foreign keys into the system tenant. The approval and
notification kinds, states, decision types, channels and the kind's
permission are system reference data; every reference to them is a foreign
key with
:use_system_tenant:. - Closed sets are enums. The delivery outcome is the C++ enum
domain::delivery_outcome, backed by an immutable tenant-less lookup and an enforced database foreign key, as trading's enums are. - Rules live in the schema where they can. The one-approval-per-person rule is a modelled unique index and a failed delivery's reason a modelled check; only the four-eyes rule is a hand-written trigger.
- Fix the generator, not the output. Defects the new component exposed were fixed in the codegen templates and planner, and the drift sweep shows no other component's output changes.