Expand description
Case orchestration: filters, list/get, and the guarded mutation plans.
Structs§
- Attach
Group - Attach
Plan - Case
Edit Report - Case
Filter - Case
List - Comment
Plan - Create
Plan - Delete
Plan - Resolved
Case - Status
Plan
Constants§
- PAGE_
SIZE - The
_findroute’s per-page cap.
Functions§
- apply_
attach - One comments POST per rule group (the API takes one
ruleper comment). A failed group must not discard the groups that already attached: a?on the first error would report only the raw error while leaving earlier groups attached, and a retry would then double-attach them. Accumulate per-group outcomes instead, so a partial failure renders as counts plus per-group detail rather than an opaque error. - apply_
comment - apply_
create - apply_
delete - apply_
status - case_
row - The compact case row for list output and mutation reports: stable columns
in a fixed order (
preserve_ordermakes this the render contract). - export
- The
--outpath: every page, unlesslimitstops it early. - export_
with_ page_ size - The paging loop with an explicit page size, exposed for tests. Stops
paging as soon as
limitrows are in hand, mirroringalerts_ops::export’s shape. - find_
query - Deterministic query string for
GET /api/cases/_find. Key order is fixed so tests and fixtures are stable. - get_one
- list
- One bounded peek: page until
limit + 1rows are in hand or the server runs out, then truncate. - plan_
attach - Resolve the case (for its title) and every alert (id, index, rule),
fail-closed on any missing alert, then group by rule — the comments route
takes one
ruleobject per comment. - plan_
comment - plan_
create - plan_
delete - The 0.4 area’s only destructive verb: the preview names each title.
- plan_
status - Fetch each case for its version, mark already-in-state rows, and PATCH only the rest. A no-op set still previews and reports zero updates.