Admin Spec — Admin & System

Admin & System

Domain 9 of the Enhanced Candidate A navigation structure. Contains: Admins, Settings (General), Notifications, 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

2.3 Data Displayed

Column Source
Name user_profile
Email users.email
Role user_type=1 (Admin) or user_type=5 (View-Only)
Status user_activation_status

2.4 Existing Capabilities (preserved)

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

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:

3.4 Existing Capabilities (preserved)

3.5 Role Visibility

Admin only.

4. Screen: Notifications

4.1 Purpose

Send broadcast push notifications. Relocated from Settings.

4.2 Entry Points

4.3 Existing Capabilities (preserved)

4.4 Actions

Action Trigger Permission
Send Notification Form submit Admin only

4.5 Role Visibility

Admin only.

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

5.3 Data Displayed

Column Source
Title support_links.title
URL support_links.url
Order support_links.order

5.4 Existing Capabilities (preserved)

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).

6.2 Entry Points

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 / Closed 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 Changes status
Assign Priority Priority dropdown Admin Sets priority
View Student Student name click All → Student Detail Page
Resolve "Resolve" button Admin Marks as resolved with optional resolution note
Close "Close" button Admin Marks as closed

6.6 States

State Display
Has issues Issue list sorted by date (newest first)
No issues "No student-reported issues. "
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.