Publish share-selection group membership in capabilities

GET /api/meta/capabilities dropped group membership at the wire: it
shipped a flat group-id list and a flat leaf list with no boundary
between them, so a native client could not tell which leaves live
under which group, or which group is the fenced sensitive tier. That
made it unsafe for the client to offer a "select all" affordance for
any group, since it could not mirror the server's fence against
bundling more than one sensitive leaf behind a single control.

Add SHARE_GROUPS to the report-selection catalogue, derived from the
existing REPORT_GROUPS/MEASUREMENT_LEAF_GROUP/STRUCTURED_LEAF_GROUP
maps: each group now carries its member leaf ids, and the group whose
id equals SENSITIVE_GROUP_ID carries sensitive: true. share.groups in
the capabilities response now ships this shape instead of bare ids;
share.leaves is unchanged. Update the OpenAPI schema and regenerate
docs/api/openapi.yaml.

Add an invariant test asserting every leaf in the flat leaves set
appears in exactly one group and no group carries a leaf outside that
set, plus a check that exactly one group is flagged sensitive.
This commit is contained in:
Marc-André Bombeck committed 2026-07-30 19:54:49 +02:00
1 parent b767cff187
commit c9c824ca4d
6 files changed
+139 -11

No files matched your search

+18 -2
View File
@@ -16096,8 +16096,24 @@ components:
groups:
type: array
items:
type: string
description: Selection group ids, in presentation order.
type: object
properties:
id:
type: string
description: Group id.
leaves:
type: array
items:
type: string
description: Member leaf ids, in the order the panel renders them.
sensitive:
description: "Present and true only on the fenced tier: no single control may switch on more than one of its leaves."
type: boolean
required:
- id
- leaves
additionalProperties: false
description: Selection groups, in presentation order, each carrying its member leaf ids.
leaves:
type: array
items: