# 1. User Directory

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

---

## 1. User Directory

### 1.1 View All User Accounts Across All Types
**What it does:** Provides a single, unified directory of every account on the platform — Sub Admins, Students, Parents, Affiliates, and Institutes — with each account's key attributes (name, contact, type, status, roles, institute affiliation, membership state, and last activity). The directory is the Super Administrator's primary surface for finding, understanding, and acting on any account, and it respects the Super Admin's full access (no scoping).

**Sub-features:**
- Unified list of all account types with a type column and type filter
- Account summary fields: name, email, phone, type, status, roles, institute, membership plan, registration date, last activity
- Row actions: open the full account record, quick status change, quick role view
- Full account record: profile, verification state, roles and permissions, sessions, activity history, consent records, subscription state
- Pagination and sorting on all columns
- Column customization (show/hide fields)
- Export of the filtered directory view

**Super Administrator User Journey:**
1. Super Admin opens the User Directory. The default view lists all accounts with type, status, and last-activity columns.
2. Filters by type "Institute" to review all institute accounts: name, contact, license seat count, status.
3. Clicks an institute row to open its full record: profile, verification state, linked staff and student counts, license details, and activity history.
4. Returns to the directory, sorts by "last activity" ascending to find stale accounts, and reviews the oldest entries.
5. Opens a stale student account's record: checks its membership state (expired 3 months ago), sessions (none recent), and institute link.
6. Decides the account is dormant; notes it for the institute to confirm (the seat may be reclaimable — see License & Seat Management).
7. Exports the filtered view (stale student accounts) to share with the institute's admin contact.
8. The directory reflects live state: status changes, role changes, and verification updates made elsewhere appear without refresh.

**Rules & Edge Cases:**
- The directory is unscoped for the Super Administrator (full access); other roles see scoped views per their permissions.
- Sensitive fields (full phone, date of birth) are shown per the privacy display policy and their viewing is audit-logged where required.
- The directory shows current state; historical state is available through the audit trail.
- Exports respect the same field visibility as the on-screen view and the export action is audit-logged.
- Row actions are gated by permission (a role without status-change permission sees the record but not the action).
- Large directories are paginated; filters and sorts apply server-side for consistent results.

### 1.2 Search Users
**What it does:** Finds specific accounts quickly by name, email, phone, or other attributes, with exact and partial matching across the directory. Search is the fast path to a single account, complementing the filter-based browsing.

**Sub-features:**
- Search by name, email, phone (exact and partial match)
- Search within a filtered set (e.g., search "Rahul" within type=Student, status=Active)
- Instant results with type and status indicators
- Disambiguation for common names (show type, institute, and email to distinguish)
- Recent searches and saved searches
- Deep link from a search result to the full account record

**Super Administrator User Journey:**
1. A support ticket references a student by email. Super Admin pastes the email into the directory search and gets the exact account in one result.
2. Opens the account record directly from the result and reviews the ticket's context (membership, institute, recent activity).
3. For a parent who reported an issue with their child's account, Super Admin searches the parent's name. Two parents share the name; the results show type, institute, and email to disambiguate.
4. Selects the correct parent (matching institute and email) and opens the record, then follows the parent→child links to the child's account.
5. Saves the search ("parent name + institute") for reuse, since this institute has multiple similar parent names.
6. Re-runs the saved search later to find another child of the same parent.
7. Reviews the recent-searches list to jump back to accounts checked earlier in the same investigation.
8. Every account opened from search is the same full record as reached by browsing — no difference in access or detail.

**Rules & Edge Cases:**
- Search matches are case-insensitive for names and emails; phone matching ignores formatting differences.
- Searching a partial email or phone returns candidates; the user confirms the exact account before acting.
- Search results respect the same field visibility and audit rules as the directory view.
- Saved searches store the query, not the results; re-running reflects current data.
- Search does not bypass permissions: a role cannot search for or open records outside its scope.
- Deep links to account records are permission-checked on open (a shared link does not grant access).

### 1.3 Filter Users by Type, Status, and Attributes
**What it does:** Narrows the directory to a meaningful subset using combinable filters — account type, status, institute, membership state, role, verification state, registration date range, and last-activity window. Filters are the tool for cohort-level work: reviewing all suspended accounts, all unverified students, all seats under a license.

**Sub-features:**
- Filter by type (Sub Admin, Student, Parent, Affiliate, Institute)
- Filter by status (Active, Suspended, Deactivated, Pending verification)
- Filter by institute, membership plan/state, role, verification state
- Filter by date ranges (registered between, last active within)
- Combinable filters (AND logic) with a clear active-filter summary
- Saved filter presets for recurring views
- Count of matching records always visible
- Export of the filtered set

**Super Administrator User Journey:**
1. Super Admin needs to review all suspended accounts before the monthly compliance check. Opens the directory, sets status=Suspended, and sees the count (14).
2. Adds a filter: registered within the last 90 days, to separate recent suspensions (likely onboarding issues) from older ones (likely policy violations).
3. Reviews each of the 5 recent suspensions: opens the records, checks the suspension reason and any appeal, and resolves or escalates each.
4. Saves the filter preset "Suspended — last 90 days" for the monthly check.
5. For an institute onboarding, filters type=Student + institute=[new institute] + status=Pending verification to see which of the bulk-registered students still need verification.
6. Exports that filtered set to follow up with the institute on the unverified students.
7. Reviews the active-filter summary to confirm the exact cohort before acting on it (prevents acting on the wrong set).
8. The count and the filtered set update live as accounts change state.

**Rules & Edge Cases:**
- Filters combine with AND logic; the active-filter summary is always visible so the cohort is unambiguous.
- The matching count is shown before any action, so bulk operations target a known set.
- Saved presets store the filter definition, not the results; re-running reflects current data.
- Exports of filtered sets respect field visibility and are audit-logged.
- Filters apply server-side; results are consistent regardless of page size.
- A filter that matches zero records shows an empty state with the active filters, not an error.

### 1.4 Account Record Detail View
**What it does:** The full, consolidated view of a single account: identity and contact, verification and consent state, roles and effective permissions, sessions, membership and subscription state, institute/license links, and the account's activity history. It is the reference point for any account decision and aggregates data that otherwise lives across modules.

**Sub-features:**
- Identity and contact: name, email, phone, date of birth (per display policy), address
- Verification state: email, phone, age, parental consent (for minors)
- Roles and effective permissions summary (link to the full permission view)
- Sessions: current active sessions and recent session history
- Membership: current plan, status, renewal date, payment history summary
- Links: parent↔child links, student↔institute link, license seat
- Activity history: logins, status changes, role changes, support interactions
- Quick actions: change status, assign role, view permissions, open support context
- Audit entries for the account (who changed what, when)

**Super Administrator User Journey:**
1. Super Admin opens a student account's record from the directory. The view shows identity, verification (email verified, phone verified), roles (Student), membership (active, renews in 20 days), and the institute link.
2. Reviews the sessions tab: one active session on the student's phone, last activity 2 hours ago — normal.
3. Checks the activity history: recent logins, a course enrollment last week, no status or role changes.
4. For a flagged account, the same view surfaces the anomaly: a session from an unfamiliar location 3 days ago. Super Admin opens the session detail and cross-references the login log.
5. Takes action from the quick actions: force logout of the suspicious session (routed to the session control), and reviews whether to trigger a password reset.
6. Reviews the audit entries tab: every change to this account (registration, verification, enrollment, the session termination) is listed with actor and timestamp.
7. For a parent account, follows the parent→child links to review each child's record without re-searching.
8. Closes the record; every action taken from it is already audit-logged with this account as the target.

**Rules & Edge Cases:**
- The record aggregates live data from across modules; it is a view, not a separate store.
- Sensitive fields follow the privacy display policy; viewing them is audit-logged where required.
- Quick actions are permission-gated and each routes to the owning module's flow (with its own confirmations and audit).
- The activity history and audit entries are append-only; the record shows current state plus immutable history.
- Links (parent↔child, student↔institute) are navigable in both directions from the record.
- The record is the canonical place to answer "what is the full picture of this account?"