Course Administration¶

Audience: course_admin (per-course) and tenant_admin (tenant-wide) operators.

Scope: Day-to-day admin tasks on a single course — roster management, analytics, course-admin assignments, audit visibility. Detailed RBAC and the impersonation contract live in reference/user-management.md and development/auth.md.

The LMS does not edit course content. Authoring lives in apps/cms. This guide covers the operational surfaces that ship today.

Roles¶

Course Dashboard¶

/admin/courses/\[slug\]/dashboard:

• Roster — enrolled learners with status (active / completed / pending / cancelled).
• Per-entry analytics — completion rate, average quiz score, attempt counts.
• Recent activity — last quiz attempts, completions.

Course admins see only their assigned courses. Tenant admins see all courses in their tenant. Super admins see across tenants when they explicitly use withTenantOverride().

Query shapes and caching live in reference/analytics.md.

Course-Admin Assignments¶

tenant_admin and super_admin manage assignments at /admin/courses/\[slug\]/admins:

1. Search for a target user (must already exist in the tenant).
2. Assign — writes a course_admin_assignments row.
3. The user is signed out everywhere on next request (token-version bump). On re-sign-in their JWT carries the new assignment.

To revoke, remove the row from the same surface. Revocation also bumps token_version so the JWT claim is refreshed.

Course admins themselves cannot assign other course admins — only tenant_admin and above can.

Roster Operations¶

From the course dashboard:

• View any learner's progress (entries completed, quiz attempts).
• Reset a quiz attempt only via a tenant-admin escalation; course admins file a request, tenant admins act.
• Send a password-reset email to a learner who is locked out (uses the consumed-token credentials path).

All mutating actions write audit_log rows.

Auditing¶

/admin/audit is tenant-scoped for tenant_admin and global for super_admin. Common filters:

• By actor (e.g. all impersonations triggered by a given super-admin).
• By action prefix (auth.impersonate.*, enrollment.*, users.role_changed).
• By target user or course slug.

course_admin does not have audit access in V1. Concerns about a specific learner action should be escalated to tenant_admin.

For super_admin support sessions, see Impersonation before filtering the related auth.impersonate.* events.

Common Workflows¶

Investigate an enrolment that "didn't take"¶

1. Open /admin/audit and filter by enrollment.* for the learner.
2. Verify the upsert ran and the row was scoped to the right tenant.
3. Check the learner's session in /admin/users/\[id\]. If their tenant_id differs from the course tenant, they enrolled on the wrong subdomain.

Reset a learner's quiz progress (tenant_admin)¶

1. Identify the entry slug and learner.
2. Use the admin action on /admin/courses/\[slug\]/dashboard (when present) or escalate to engineering. Direct DB edits must write audit_log entries with actor_user_id = <admin>.

Onboard a course admin¶

1. Confirm the user has a tenant account.
2. Promote to course_admin via /admin/users/\[id\].
3. Assign the specific course at /admin/courses/\[slug\]/admins.
4. Ask the user to refresh — their next request picks up the new claim.

Related References¶

• User Management & Access
• Course Enrollment System
• Analytics
• Admin Panel
• Impersonation
• Authentication