Problem
A single OTS instance often serves multiple disjoint events (e.g., separate festivals or training exercises) using groups/channels for isolation on the CoT socket. The REST list endpoints, however, return data across all groups. Clients have to filter client-side using ad-hoc heuristics like recency windows, which is brittle and leaks data across event boundaries.
Proposal
Add a group query parameter (matching the group's name) to:
/api/eud?group=jazz-festival-delft-2026/api/point?group=…/api/markers?group=…
Return only entities whose creator (or, for points and CoTs, sender) is a member of the specified group. Honor the same group-membership rules already enforced for CoT socket routing.
Why
Brings REST API isolation in line with socket-level isolation. Without this, building per-event clients on top of OTS requires either a dedicated server per event or unreliable client-side filtering.
Problem
A single OTS instance often serves multiple disjoint events (e.g., separate festivals or training exercises) using groups/channels for isolation on the CoT socket. The REST list endpoints, however, return data across all groups. Clients have to filter client-side using ad-hoc heuristics like recency windows, which is brittle and leaks data across event boundaries.
Proposal
Add a
groupquery parameter (matching the group'sname) to:/api/eud?group=jazz-festival-delft-2026/api/point?group=…/api/markers?group=…Return only entities whose creator (or, for points and CoTs, sender) is a member of the specified group. Honor the same group-membership rules already enforced for CoT socket routing.
Why
Brings REST API isolation in line with socket-level isolation. Without this, building per-event clients on top of OTS requires either a dedicated server per event or unreliable client-side filtering.