feat(admin): super-admin UI for session policy ceilings (SESSION_*_MINUTES_MIN/MAX) #170

New Issue

chihlasm · 2026-05-14T00:13:51Z

chihlasm commented

2026-05-14 00:13:51 +00:00

Follow-up from PR #168 (session-expiration-policy).

Motivation

PR #168 ships Settings.SESSION_IDLE_MINUTES_MIN/MAX and SESSION_ABSOLUTE_MINUTES_MIN/MAX as env-var ceilings (15min..30d idle, 1h..90d absolute). Per-account owners can only set values within these bounds. Today the only way to change the bounds is to redeploy with new env vars — fine for self-managed deployments, awkward for a hosted multi-tenant instance where a customer asks for a higher absolute ceiling and we dont want to ship a deploy for them.

Scope

New super-admin endpoint surface alongside existing admin/settings.py. Persist override values in the existing settings table or a new system_session_policy row.
UI under /admin/settings (or new /admin/session-policy): four inputs for the four bounds, with a one-line summary of how many accounts are currently using overrides within the existing bounds (helpful for understanding blast radius before tightening).
Validation: new MIN cant be set above any existing account override; new MAX cant be set below any existing account override. Display the conflicting account names so the super-admin can decide whether to coordinate or force-narrow those accounts policies.
Audit event: admin.session_policy_bounds_update.

Why deferred from #168

Plan §9 follow-up #1. Env-var ceilings were sufficient for v1 — bounds are unlikely to need adjustment in pilot. Revisit when a customer actually asks for a wider window than the env caps allow, or when we onboard a customer with tighter compliance needs than the env floor permits.

Dependencies

None. Lands cleanly on top of PR #168.

Effort

~half a day. Single page + 1 GET + 1 PATCH + audit-event type.

Follow-up from PR #168 (session-expiration-policy). ## Motivation PR #168 ships `Settings.SESSION_IDLE_MINUTES_MIN/MAX` and `SESSION_ABSOLUTE_MINUTES_MIN/MAX` as env-var ceilings (15min..30d idle, 1h..90d absolute). Per-account owners can only set values within these bounds. Today the only way to change the bounds is to redeploy with new env vars — fine for self-managed deployments, awkward for a hosted multi-tenant instance where a customer asks for a higher absolute ceiling and we dont want to ship a deploy for them. ## Scope - New super-admin endpoint surface alongside existing `admin/settings.py`. Persist override values in the existing settings table or a new `system_session_policy` row. - UI under `/admin/settings` (or new `/admin/session-policy`): four inputs for the four bounds, with a one-line summary of how many accounts are currently using overrides within the existing bounds (helpful for understanding blast radius before tightening). - Validation: new MIN cant be set above any existing account override; new MAX cant be set below any existing account override. Display the conflicting account names so the super-admin can decide whether to coordinate or force-narrow those accounts policies. - Audit event: `admin.session_policy_bounds_update`. ## Why deferred from #168 Plan §9 follow-up #1. Env-var ceilings were sufficient for v1 — bounds are unlikely to need adjustment in pilot. Revisit when a customer actually asks for a wider window than the env caps allow, or when we onboard a customer with tighter compliance needs than the env floor permits. ## Dependencies None. Lands cleanly on top of PR #168. ## Effort ~half a day. Single page + 1 GET + 1 PATCH + audit-event type.

chihlasm referenced this issue

2026-05-14 00:31:39 +00:00

feat(auth): session expiration policy (3d idle / 14d absolute) + per-account override + bulk revoke #168

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: chihlasm/resolutionflow#170