Files
central-unifi/docs/superpowers/specs
jwed c745aa8b2c Spec: Wi-Fi access becomes an explicit allow-list, configured in settings
Two changes from the operator.

Session length and devices-per-role are set in the settings UI, on the existing
Portal settings page rather than a new one. Two presentation decisions that are
really correctness decisions:

  · the role is picked from a DROPDOWN of seeded roles, not typed. match_value is
    compared exactly, so "Student" or "studnet" matches nobody and the failure
    surfaces as a pupil with no Wi-Fi and nothing logged anywhere. A dropdown
    makes an unmatchable value impossible to enter.
  · session length is entered in DAYS with presets. session_minutes stays the
    stored unit, but a term is 172,800 minutes and nobody should type that — the
    same reasoning that presents cron schedules as presets instead of raw strings.

And access is now an explicit allow-list: no role added means no Wi-Fi. That makes
`default` an anti-feature, because a default row matches everybody and turns the
allow-list into a suggestion, so it is removed from the available match types.
resolveMapping() already returns null when nothing matches and null already
produces the "No WiFi access configured for your account." denial, so
deny-by-default is the behaviour as soon as the catch-all cannot be created.

Safe to do now specifically because unifi_vlan_mappings has ZERO rows in every
environment — nothing is revoked from anybody. The same change made after a school
had leaned on a catch-all would cut off every unmapped person at once.

VLAN stays required per row. It was not in the request, so it is called out in the
spec rather than quietly dropped: the network still has to know where to put the
device.
2026-08-21 12:48:47 -04:00
..