v2 Admin Spec — Admin & System
Admin & System
Domain 9 of the Enhanced Candidate A navigation structure. Contains: Admins, Settings (General), Notifications (redirect), Support Links, Issue Queue (NEW).
1. Domain Overview
Admin & System is the catch-all domain for system administration tools. It deliberately receives only items that genuinely don't belong elsewhere — unlike the old Settings section which was a dumping ground for 11+ items. Most former Settings items have been redistributed to their logical domains (Welcome Package → Semester Mgmt, Payment Plans → Billing, etc.).
Key new screen: Issue Queue — borrowed from Candidate B. Creates the student-to-admin communication channel requested in the interview.
2. Screen: Admins
2.1 Purpose
Manage who has backend access. Relocated from People > Admins.
2.2 Entry Points
- Sidebar: Admin & System > Admins
2.3 Data Displayed
| Column | Source |
|---|---|
| Name | user_profile |
users.email |
|
| Role | user_type=1 (Admin) or user_type=5 (View-Only) |
| Status | user_activation_status |
2.4 Existing Capabilities (preserved)
- View all admin users
- Create/edit/delete admin accounts
- Set view-only permission (user_type=5)
2.5 Role Visibility
Admin only.
3. Screen: Settings (General)
3.1 Purpose
General app configuration. Dramatically reduced from the former Settings catch-all.
3.2 Entry Points
- Sidebar: Admin & System > Settings
3.3 Note
This screen now contains ONLY general app settings. Formerly 11 items, now just the core settings that don't belong in any specific domain. The old Settings catch-all has been dissolved:
- Welcome Package → Semester Management
- Email Management → Semester Management
- Tags → Semester Management
- Operations → Semester Management
- Payment Plans → Billing & Payments
- Coupons → Billing & Payments
- Teacher Assignment Criteria → Teacher Management
- Logs → Reporting
- Notifications → Admin & System (separate nav item)
3.4 Existing Capabilities (preserved)
- General app settings
3.5 Role Visibility
Admin only.
4. Screen: Notifications
Notifications has moved to Communication > Push Notifications. See 11-communication.md.
5. Screen: Support Links
5.1 Purpose
Manage help/FAQ links shown to students in the app. Relocated from Students Management grab-bag.
5.2 Entry Points
- Sidebar: Admin & System > Support Links
5.3 Data Displayed
| Column | Source |
|---|---|
| Title | support_links.title |
| URL | support_links.url |
| Order | support_links.order |
5.4 Existing Capabilities (preserved)
- Create/edit/delete help/support links
- Reorder links
5.5 Role Visibility
Admin: Full CRUD. View-Only: View only.
6. Screen: Issue Queue (NEW)
6.1 Purpose
Surface student-reported app issues. Borrowed from Candidate B. Creates the student-to-admin communication channel the admin requested in the interview (Q7, Q9).
Boundary note: Issue Queue is ticketed support, not messaging. For conversational follow-up, use Communication > Private Messages.
6.2 Entry Points
- Sidebar: Admin & System > Issue Queue
- Dashboard: "App Issues" tile click
6.3 Layout
Filter bar + issue list
6.4 Data Displayed
| Column | Source | Sortable |
|---|---|---|
| Student Name | Reporter user | Yes |
| Issue Type | Category (Bug / Content / Account / Other) | Yes |
| Subject | Issue title | Yes |
| Date Reported | Timestamp | Yes |
| Status | Open / In Progress / Resolved / Rejected. When In Progress, status cell shows optional delegation badge: "In Progress (Delegated to CS/IT/Teaching)". | Yes |
| Priority | High / Medium / Low | Yes |
6.5 Actions
| Action | Trigger | Permission | Behavior |
|---|---|---|---|
| View Issue | Row click | All | Opens issue detail (description, screenshots if any, student info). |
| Update Status | Status dropdown on detail | Admin | Moves issue between Open / In Progress. Terminal transitions use the dedicated Resolve / Reject actions below. |
| Assign Priority | Priority dropdown | Admin | Sets priority. |
| View Student | Student name click | All | → Student Detail Page. |
| Take | "Take" button (visible on Open) | Admin | Transitions Open → In Progress, assigns current admin as handler. |
| Delegate | "Delegate" submenu (visible on Open + In Progress) | Admin | Sets delegated_to ∈ {CS, IT, Teaching Staff} and transitions to In Progress if not already. Also moves current admin as co-owner. Admin retains time-to-resolution tracking — delegation is informational (see ADR-006 §2). Re-selecting the same target clears it. |
| Resolve | "Resolve" button | Admin | Transitions to Resolved. Optional resolution note. Clears delegated_to. |
| Reject | "Reject" button (replaces former "Delete") | Admin | Transitions to Rejected. Optional rejection reason. Clears delegated_to. No hard delete — issue remains queryable via the Archive view. |
| Reopen | "Reopen" button (visible on Resolved + Rejected) | Admin | Transitions back to Open (not In Progress). Admin then re-triages. Retains prior resolution/rejection note in history. |
View toggle (top of list):
- Active (default) — Open + In Progress
- Archived — Resolved + Rejected
- All — every state
Backward transitions (In Progress → Open) are allowed. See ADR-006 §4 for the full state-transition diagram.
6.6 States
| State | Display |
|---|---|
| Has issues | Issue list sorted by date (newest first), filtered by view toggle |
| No issues (Active view) | "No active student-reported issues." |
| No issues (Archived view) | "No archived issues yet." |
| Loading/Error | Standard patterns |
6.7 Role Visibility
Admin: Full management. View-Only: View only. Support Staff: View only.
6.8 Note on Implementation
The Issue Queue requires a corresponding student-facing feature in the iOS app for submitting issues. This feature does not exist today and is outside the scope of this admin backend spec. Until the student-facing feature is built, the Issue Queue screen exists but will be empty. It can also be used as a manual issue tracking tool where the admin creates issues on behalf of students who report via email.