Admin overview
What admins do in this app and a map of the admin surface.
What admins are responsible for
- Defining roles and what it takes to get approved for each one.
- Reviewing applications as new people join and approving them onto the roster.
- Keeping the directory current — new addresses, deactivations, role changes.
- Organizing groups (families, households, couples) so the scheduler doesn’t rotate two members of the same household onto the same Sunday by accident.
- Building and publishing a quarter at a time — generate a draft, review, edit, publish.
- Managing the weekly reminder campaign and, when needed, ad-hoc announcements.
- Handling edge cases — applicants asking questions, volunteers in a bind, a whole family out for a weekend.
Regular volunteers never see the /admin/* section at all.
Admin pages at a glance
| Path | What it’s for |
|---|---|
/admin | Dashboard — live counts, recent swaps/coverage, last cron fire, unfilled-slot warnings. |
/admin/applicants | Pending applications + the checklist. |
/admin/roles | CRUD on roles and their application checklists. |
/admin/groups | Families / households / couples — scheduler avoids scheduling group-mates on the same Sunday. |
/admin/directory | All users; detail pages with history, eligibility, fairness stats. |
/admin/quarter/<quarter> | Generate, edit, and publish a quarter’s draft. |
/admin/service/<date> | Single-Sunday view — reassign on the fly, resend reminders. |
/admin/email | Outbox — every email the system has sent or scheduled. |
/admin/audit | Filterable timeline of every admin-side change. |
Permissions model
Right now there’s a single admin flag per user. Anyone with that flag can do everything. If that ends up being too coarse (e.g. you want role-editors separate from campaign-senders), we’ll split it out later — the audit log will tell us who actually touches what before we design roles.