# 1. Review Queue

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 1. Review Queue

### 1.1 View Newly Uploaded Content Pending Review
**What it does:** Presents the review queue: the newly uploaded content that is pending review, in one place, so the Super Administrator (and the designated reviewers) can see what is waiting to be reviewed and act on it. The queue is the entry point to the approval workflow — content enters here on upload and leaves it once it is approved, rejected, or flagged.

**Sub-features:**
- Review queue: the list of content pending review
- Queue entry: content enters the queue on upload (before it is live)
- Queue item detail: the content, the creator, the upload time, and the status
- Queue ordering: the items ordered (by upload time, by priority)
- Queue count: the number of items pending (the workload visible)
- Queue aging: the time an item has been pending (the stale items visible)
- Audit logging of the queue actions

**Super Administrator User Journey:**
1. Content owners upload new content; each upload enters the review queue (it is not live until reviewed).
2. Super Admin opens the review queue: the list of the content pending review, with the creator, the upload time, and the status.
3. Reviews the queue count (the workload) and the ordering (the oldest first, so the stale items are not buried).
4. Identifies the aging items (the ones pending the longest); they are prioritized (a long-pending item is a delay).
5. Opens a queue item: the content, the creator, and the context (the course/topic it is for), so the review is informed.
6. Acts on the item (review, approve, reject, or flag — see the other feature groups); the item leaves the queue on the action.
7. Reviews the queue after the actions: the count reduced, the remaining items the next to handle; the queue is worked down.
8. The queue actions are audit-logged with the content, the actor, and the timestamp.

**Rules & Edge Cases:**
- Content enters the queue on upload; it is not live until it is reviewed and approved.
- The queue shows the content, the creator, the upload time, and the status; the item is self-describing.
- The ordering and the aging make the stale items visible; a long-pending item is a delay, not a silent wait.
- An item leaves the queue on the action (approve/reject/flag); it is not both in the queue and acted on.
- The queue count is the workload; it is visible so the review load is managed.
- Queue actions are audit-logged with the content, actor, and timestamp.

### 1.2 Filter by Content Type, Subject, and Creator
**What it does:** Filters the review queue by the content type, the subject, and the creator, so the Super Administrator (or a reviewer) can narrow the queue to the items they are responsible for or interested in. Filtering makes a large queue manageable — a reviewer handles their subject, a type-specific reviewer handles their type, and the Super Admin can isolate a creator's submissions.

**Sub-features:**
- Type filter: the queue filtered by the content type (video, document, flashcard, etc.)
- Subject filter: the queue filtered by the subject
- Creator filter: the queue filtered by the creator
- Combined filters: the filters combined (the type and the subject and the creator)
- Filtered view: the queue shown for the filter set
- Filter reset: the filters cleared (the full queue restored)
- Audit logging of the filtered reviews (where applicable)

**Super Administrator User Journey:**
1. The queue is large. Super Admin filters by the subject (the subject they are reviewing today); the queue narrows to that subject's items.
2. For a type-specific review (the video uploads), Super Admin filters by the content type (video); the queue narrows to the videos.
3. For a creator's submissions (a new content owner's first batch), Super Admin filters by the creator; the queue narrows to that creator's items.
4. Combines the filters (the subject and the type and the creator) to isolate a specific set; the filtered view is the exact items.
5. Works down the filtered queue (the reviews, the approvals, the rejections); the items are handled in the narrowed set.
6. Resets the filters (the full queue restored) to see the overall state (the remaining workload across all subjects/types/creators).
7. For a reviewer, the filter is their scope (their subject); they work their filtered queue, and the Super Admin sees the per-reviewer progress.
8. The filtered reviews are audit-logged where applicable (the content, the filter, the actor, the timestamp).

**Rules & Edge Cases:**
- The filters are by the content type, the subject, and the creator; they can be combined.
- A filtered view is the queue for the filter set; it is a subset, not a different queue.
- A filter reset restores the full queue; the filters are not sticky.
- A reviewer's scope is their filter (their subject/type); they work their subset, and the overall state is visible to the Super Admin.
- A filtered review is still a review; the action (approve/reject/flag) is the same, scoped to the filtered item.
- Filtered reviews are audit-logged where applicable.
