HR management & module permissions¶

Midsummer’s access model is built around departments. People belong to departments, departments own modules, and the combination of who you are in the department and what the department grants produces your permission level for each module. This page explains exactly how that works, and how to use HR to manage your staff.

The four permission levels¶

Every request is evaluated down to one of four levels for the module being accessed:

Level	Meaning
`public`	Not signed in, or no role that grants access to this module. The request is treated as anonymous.
`staff`	The user is a member (or leader) of a department that owns this module. Enough to use staff tools (check-in, fulfillment, kiosks).
`admin`	The user can configure this module for the event (create forms, tiers, schedules, etc.).
`superadmin`	The user has full control of this module for the event.

The “clear bar”¶

Module pages declare a minimum level they require (staff, admin, or superadmin). A user passes the check if their computed level is at or above the requirement:

Page requires	Allowed levels
`staff`	`staff`, `admin`, `superadmin`
`admin`	`admin`, `superadmin`
`superadmin`	`superadmin`

If you see a “you don’t have permission” or login prompt, your computed level for that module is below the page’s requirement.

How a level is computed¶

The level is derived from up to three places, evaluated together:

Event admins. If you are listed in the event’s admins, you are treated as a leader of every department in that event.
Department membership. You belong to a department via one of its role fields (below).
Module ownership. The department has a ModuleOwnership record for the module in question, with flags that say what level to grant.

Department roles¶

A department has these slots. The first three are leadership; the rest are membership.

Role (field)	Leadership?
`oversight`	Yes
`lead`	Yes
`second`	Yes
`deputies` (many)	No
`staff` (many)	No
`volunteers` (many)	No

Module ownership flags¶

When a department owns a module, these flags decide the level each kind of member gets:

Flag	Grants
`department_leadership_is_superadmin`	Leaders → `superadmin`
`department_leadership_is_admin`	Leaders → `admin`
`department_staff_is_superadmin`	Staff members → `superadmin`
`department_staff_is_admin`	Staff members → `admin`
`department_volunteer_is_admin`	Volunteers → `admin`

If a department owns a module but grants no admin/superadmin flags, its members still get at least staff. The highest level any qualifying department grants wins (superadmin > admin > staff > public).

Worked examples¶

A check-in volunteer in the Registration department, where that department owns the Register module with no admin flags, gets staff for Register — enough to run check-in, not enough to edit forms.
The Registration lead in the same department, where department_leadership_is_admin is set, gets admin for Register — they can create and edit forms.
An event admin is treated as a leader of all departments, so they pick up whatever each department’s leadership flags grant across every module.

HR management¶

HR actions are special: only department leadership (oversight, lead, second) can perform them. Deputies, staff, and volunteers are intentionally excluded even when their department owns the Staff module, so a volunteer can never edit another person’s personnel file.

Capability	Available to
View a department roster	Leadership of the department (and event admins)
Edit personnel files (HR)	Leadership of the department only
Assign department titles	Leadership of the department
Manage shifts, slots, positions, onboarding	Leadership of the department

Everything HR-relevant is recorded in a staff audit log, and department rosters can be exported to Excel (with title columns and Excel-formula-safe cells).

Titles¶

Each department can keep a title catalog (standard, reorderable titles plus ad-hoc free-text titles) and assign a title to an individual. Titles are display-only labels — they do not by themselves grant permissions — and they appear on the roster and in exports.

Tenant-level access (separate from events)¶

The model above is per event. Separately, the tenant (the organization that owns one or more events) has its own management app, gated by a Membership record with one of:

isTenantSuperuser — full tenant management (events, settings, billing, domains, API tokens, Stripe keys).
isDeveloper — developer access to the tenant management app.

This is unrelated to per-event department permissions: a tenant superuser is not automatically an event admin, and an event admin is not automatically a tenant superuser.

Troubleshooting access¶

If someone can’t reach a module page:

Confirm they are signed in.
Confirm their department owns that module (ModuleOwnership exists).
Confirm the right flag is set for their role (leadership vs. staff vs. volunteer).
For HR specifically, confirm they are leadership (oversight/lead/second), not a deputy/staff/volunteer.
Confirm you’re on the right event — permissions are per event.

If a page is still unreachable after all of the above, it may be a genuine configuration issue; capture any error code shown and look it up in the error reference.