Per-camera storage rules were fine when I had two cameras. With eleven they became a maintenance burden: every "let me keep my front yard cam at 30 days but everything else at 14" demanded eleven edits.
The new model
Three layers, in priority order:
- System default. What every new camera gets out of the box.
- Group default. Attach cameras to a named group (e.g. "Outside Cams").
Settings on the group apply to every camera in it.
- Per-camera override. For the one camera that needs to be different.
Settings include retention, recording profile, motion mode, the works. Conflicts always resolve in priority order; the admin UI shows you which layer won and why.
What's named, not per-camera
- Recording profiles ("Default", "Motion")
- Retention tiers (live + archive)
- Motion detector choice (per camera still, but defaults flow from the group)
- Bookmarks scope (own vs. team vs. system)
Hardening that landed alongside
Three HIGH-severity bugs uncovered while building this: a hung policy resolver on cyclic groups (fixed with a depth limit), an inheritance ambiguity on overlap (fixed by always preferring the deeper layer), and an admin-UI race that could save a half-validated policy (fixed with server-side validation). All three fixed and tested before the policy work shipped.
Committed in ed37bd7. The follow-up that adds advanced per-policy storage caps shipped two days later (crumb-advanced-policy-storage).