# 1. User Directory — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: user_directory.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature,
  expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 1.1 View All User Accounts Across All Types | Unified list of all account types with a type column and type filter | TC-SA-03-01-001 |
| 1.1 View All User Accounts Across All Types | Account summary fields: name, email, phone, type, status, roles, institute, membership plan, registration date, last activity | TC-SA-03-01-002 |
| 1.1 View All User Accounts Across All Types | Row actions: open the full account record, quick status change, quick role view | TC-SA-03-01-003 |
| 1.1 View All User Accounts Across All Types | Full account record: profile, verification state, roles and permissions, sessions, activity history, consent records, subscription state | TC-SA-03-01-004 |
| 1.1 View All User Accounts Across All Types | Pagination and sorting on all columns | TC-SA-03-01-005 |
| 1.1 View All User Accounts Across All Types | Column customization (show/hide fields) | TC-SA-03-01-006 |
| 1.1 View All User Accounts Across All Types | Export of the filtered directory view | TC-SA-03-01-007 |
| 1.1 View All User Accounts Across All Types | Rule: unscoped for the Super Administrator; other roles see scoped views | TC-SA-03-01-008 |
| 1.1 View All User Accounts Across All Types | Rule: sensitive fields shown per privacy display policy; viewing audit-logged | TC-SA-03-01-009 |
| 1.1 View All User Accounts Across All Types | Rule: directory shows current state; historical state via audit trail | TC-SA-03-01-010 |
| 1.1 View All User Accounts Across All Types | Rule: exports respect field visibility; export action audit-logged | TC-SA-03-01-007 |
| 1.1 View All User Accounts Across All Types | Rule: row actions gated by permission | TC-SA-03-01-011 |
| 1.1 View All User Accounts Across All Types | Rule: large directories paginated; filters/sorts server-side | TC-SA-03-01-005 |
| 1.2 Search Users | Search by name, email, phone (exact and partial match) | TC-SA-03-01-012 |
| 1.2 Search Users | Search within a filtered set | TC-SA-03-01-013 |
| 1.2 Search Users | Instant results with type and status indicators | TC-SA-03-01-014 |
| 1.2 Search Users | Disambiguation for common names (type, institute, email) | TC-SA-03-01-015 |
| 1.2 Search Users | Recent searches and saved searches | TC-SA-03-01-016 |
| 1.2 Search Users | Deep link from a search result to the full account record | TC-SA-03-01-017 |
| 1.2 Search Users | Rule: case-insensitive names/emails; phone matching ignores formatting | TC-SA-03-01-018 |
| 1.2 Search Users | Rule: partial matches return candidates; user confirms before acting | TC-SA-03-01-019 |
| 1.2 Search Users | Rule: results respect field visibility and audit rules | TC-SA-03-01-020 |
| 1.2 Search Users | Rule: saved searches store the query, not results | TC-SA-03-01-016 |
| 1.2 Search Users | Rule: search does not bypass permissions | TC-SA-03-01-021 |
| 1.2 Search Users | Rule: deep links permission-checked on open | TC-SA-03-01-022 |
| 1.3 Filter Users by Type, Status, and Attributes | Filter by type | TC-SA-03-01-023 |
| 1.3 Filter Users by Type, Status, and Attributes | Filter by status | TC-SA-03-01-024 |
| 1.3 Filter Users by Type, Status, and Attributes | Filter by institute, membership plan/state, role, verification state | TC-SA-03-01-025 |
| 1.3 Filter Users by Type, Status, and Attributes | Filter by date ranges (registered between, last active within) | TC-SA-03-01-026 |
| 1.3 Filter Users by Type, Status, and Attributes | Combinable filters (AND logic) with a clear active-filter summary | TC-SA-03-01-027 |
| 1.3 Filter Users by Type, Status, and Attributes | Saved filter presets for recurring views | TC-SA-03-01-028 |
| 1.3 Filter Users by Type, Status, and Attributes | Count of matching records always visible | TC-SA-03-01-029 |
| 1.3 Filter Users by Type, Status, and Attributes | Export of the filtered set | TC-SA-03-01-030 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: AND logic; active-filter summary always visible | TC-SA-03-01-027 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: matching count shown before any action | TC-SA-03-01-029 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: presets store the definition, not results | TC-SA-03-01-028 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: exports respect field visibility; audit-logged | TC-SA-03-01-030 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: filters server-side; consistent regardless of page size | TC-SA-03-01-031 |
| 1.3 Filter Users by Type, Status, and Attributes | Rule: zero-match filter shows empty state with active filters | TC-SA-03-01-032 |
| 1.4 Account Record Detail View | Identity and contact: name, email, phone, DOB (per display policy), address | TC-SA-03-01-033 |
| 1.4 Account Record Detail View | Verification state: email, phone, age, parental consent | TC-SA-03-01-034 |
| 1.4 Account Record Detail View | Roles and effective permissions summary (link to full permission view) | TC-SA-03-01-035 |
| 1.4 Account Record Detail View | Sessions: current active sessions and recent session history | TC-SA-03-01-036 |
| 1.4 Account Record Detail View | Membership: current plan, status, renewal date, payment history summary | TC-SA-03-01-037 |
| 1.4 Account Record Detail View | Links: parent↔child, student↔institute, license seat | TC-SA-03-01-038 |
| 1.4 Account Record Detail View | Activity history: logins, status changes, role changes, support interactions | TC-SA-03-01-039 |
| 1.4 Account Record Detail View | Quick actions: change status, assign role, view permissions, open support context | TC-SA-03-01-040 |
| 1.4 Account Record Detail View | Audit entries for the account (who changed what, when) | TC-SA-03-01-041 |
| 1.4 Account Record Detail View | Rule: aggregates live data; a view, not a separate store | TC-SA-03-01-042 |
| 1.4 Account Record Detail View | Rule: sensitive fields per privacy display policy; viewing audit-logged | TC-SA-03-01-043 |
| 1.4 Account Record Detail View | Rule: quick actions permission-gated; route to owning module's flow | TC-SA-03-01-044 |
| 1.4 Account Record Detail View | Rule: activity history and audit entries append-only | TC-SA-03-01-045 |
| 1.4 Account Record Detail View | Rule: links navigable in both directions | TC-SA-03-01-046 |
| 1.4 Account Record Detail View | Rule: canonical place for the full picture of an account | TC-SA-03-01-047 |

## 1.1 View All User Accounts Across All Types

### TC-SA-03-01-001 — Unified list shows all five account types with a type column and type filter
**Type:** Positive
**Covers:** 1.1 → Unified list of all account types with a type column and type filter
**Preconditions:** The platform has at least one account of each type (Sub Admin, Student, Parent, Affiliate, Institute).
**Steps:**
1. Open the User Directory.
2. Verify the list contains accounts of all five types and that a "type" column is present.
3. Apply the type filter for each type in turn.
**Expected Result:** All five types appear in the unified list; the type filter isolates exactly the accounts of the selected type.
**Priority:** Critical

### TC-SA-03-01-002 — Account summary fields are all present and accurate
**Type:** Positive
**Covers:** 1.1 → Account summary fields: name, email, phone, type, status, roles, institute, membership plan, registration date, last activity
**Preconditions:** A known student account with a complete profile, an institute link, and an active membership.
**Steps:**
1. Open the directory and locate the known student account.
2. Compare each summary field (name, email, phone, type, status, roles, institute, membership plan, registration date, last activity) against the account's actual values.
**Expected Result:** Every summary field matches the account's true value — no missing, stale, or misattributed fields.
**Priority:** Critical

### TC-SA-03-01-003 — Row actions: open record, quick status change, quick role view
**Type:** Positive
**Covers:** 1.1 → Row actions: open the full account record, quick status change, quick role view
**Preconditions:** Super Admin logged in; a suspended account and an active account are visible.
**Steps:**
1. On an account row, use the action to open the full account record.
2. Use the quick status change on the suspended account (with reason) and verify the state change.
3. Use the quick role view on an account holding two roles.
**Expected Result:** All three row actions work: the record opens, the status change applies (and is audited), and the role view lists the account's roles.
**Priority:** High

### TC-SA-03-01-004 — Full account record contains all seven sections
**Type:** Positive
**Covers:** 1.1 → Full account record: profile, verification state, roles and permissions, sessions, activity history, consent records, subscription state
**Preconditions:** A student account with verification completed, a role, active sessions, consent records, and an active subscription.
**Steps:**
1. Open the account's full record.
2. Verify each section is present and populated: profile, verification state, roles and permissions, sessions, activity history, consent records, subscription state.
**Expected Result:** All seven sections are present with correct data — the record is complete.
**Priority:** Critical

### TC-SA-03-01-005 — Pagination and sorting work on all columns, server-side
**Type:** Positive
**Covers:** 1.1 → Pagination and sorting on all columns; Rule: large directories paginated; filters/sorts server-side
**Preconditions:** The directory contains more accounts than one page.
**Steps:**
1. Sort by each column (ascending and descending) in turn.
2. Navigate through multiple pages.
3. Verify the total count and page consistency.
**Expected Result:** Every column sorts correctly in both directions; pagination is stable and server-side — results are consistent regardless of page size.
**Priority:** High

### TC-SA-03-01-006 — Column customization: show/hide fields persists
**Type:** Positive
**Covers:** 1.1 → Column customization (show/hide fields)
**Preconditions:** Super Admin logged in.
**Steps:**
1. Hide the "phone" and "registration date" columns.
2. Verify the columns disappear from the view.
3. Reload the directory and re-show the columns.
**Expected Result:** Columns can be hidden and shown; the customization is applied consistently and does not corrupt the view.
**Priority:** Medium

### TC-SA-03-01-007 — Export of the filtered directory view respects field visibility and is audit-logged
**Type:** Positive
**Covers:** 1.1 → Export of the filtered directory view; Rule: exports respect the same field visibility as the on-screen view and the export action is audit-logged
**Preconditions:** A filtered directory view is active (e.g., type=Institute) with a hidden column.
**Steps:**
1. Export the filtered view.
2. Verify the export contains exactly the filtered rows and only the visible fields.
3. Check the audit trail for the export action.
**Expected Result:** The export matches the on-screen view (same rows, same visible fields — hidden columns excluded); the export action is audit-logged.
**Priority:** High

### TC-SA-03-01-008 — The directory is unscoped for the Super Admin; scoped for other roles
**Type:** Positive
**Covers:** 1.1 → Rule: the directory is unscoped for the Super Administrator (full access); other roles see scoped views per their permissions
**Preconditions:** Super Admin and a scoped sub-admin (e.g., an institute admin) are both logged in at different times.
**Steps:**
1. As Super Admin, open the directory and count the total accounts.
2. As the scoped sub-admin, open the directory and count the visible accounts.
**Expected Result:** The Super Admin sees all accounts (unscoped); the sub-admin sees only the accounts within its scope.
**Priority:** Critical

### TC-SA-03-01-009 — Sensitive fields follow the privacy display policy; viewing is audit-logged
**Type:** Positive
**Covers:** 1.1 → Rule: sensitive fields (full phone, date of birth) are shown per the privacy display policy and their viewing is audit-logged where required
**Preconditions:** The privacy display policy masks full phone/DOB by default.
**Steps:**
1. Open the directory and observe the phone and DOB columns.
2. Reveal a sensitive field where the policy allows.
3. Check the audit trail for the reveal/viewing event.
**Expected Result:** Sensitive fields are displayed exactly per the privacy display policy; the viewing event is audit-logged where required.
**Priority:** High

### TC-SA-03-01-010 — The directory shows current state; historical state is in the audit trail
**Type:** Edge
**Covers:** 1.1 → Rule: the directory shows current state; historical state is available through the audit trail
**Preconditions:** An account's status changed from Active to Suspended yesterday.
**Steps:**
1. Open the directory and check the account's status today.
2. Query the audit trail for the account's status as of yesterday.
**Expected Result:** The directory shows only the current state (Suspended); the prior state (Active) is recoverable from the audit trail.
**Priority:** Medium

### TC-SA-03-01-011 — Row actions are gated by permission
**Type:** Negative
**Covers:** 1.1 → Rule: row actions are gated by permission (a role without status-change permission sees the record but not the action)
**Preconditions:** A sub-admin role without status-change permission is logged in.
**Steps:**
1. Open the directory as the sub-admin.
2. Attempt to open an account record.
3. Attempt to use the quick status change action.
**Expected Result:** The record opens (view permission granted) but the status-change action is not available — the action is gated by permission.
**Priority:** High

## 1.2 Search Users

### TC-SA-03-01-012 — Search by name, email, and phone with exact and partial matching
**Type:** Positive
**Covers:** 1.2 → Search by name, email, phone (exact and partial match)
**Preconditions:** Known accounts with distinct names, emails, and phones.
**Steps:**
1. Search by exact email → expect the single matching account.
2. Search by partial name (e.g., "Rahul") → expect all accounts with that substring.
3. Search by exact phone and by partial phone.
**Expected Result:** Exact searches return the exact match; partial searches return all candidates containing the substring — for all three fields.
**Priority:** Critical

### TC-SA-03-01-013 — Search within a filtered set
**Type:** Positive
**Covers:** 1.2 → Search within a filtered set (e.g., search "Rahul" within type=Student, status=Active)
**Preconditions:** Multiple accounts named "Rahul" across types/statuses; a filter type=Student + status=Active is applied.
**Steps:**
1. Apply the filter type=Student, status=Active.
2. Search "Rahul" within the filtered set.
**Expected Result:** Only "Rahul" accounts that are Students and Active are returned — the search is scoped to the filtered set.
**Priority:** High

### TC-SA-03-01-014 — Instant results with type and status indicators
**Type:** Positive
**Covers:** 1.2 → Instant results with type and status indicators
**Preconditions:** Search terms that match multiple accounts of different types/statuses.
**Steps:**
1. Type a search term that matches several accounts.
2. Observe the result rendering.
**Expected Result:** Results appear instantly (no manual submit required) and each result shows its type and status indicators.
**Priority:** Medium

### TC-SA-03-01-015 — Disambiguation for common names shows type, institute, and email
**Type:** Positive
**Covers:** 1.2 → Disambiguation for common names (show type, institute, and email to distinguish)
**Preconditions:** Two parent accounts share the same name but differ in institute and email.
**Steps:**
1. Search the common name.
2. Review the disambiguation details on each result.
**Expected Result:** Both results are shown with type, institute, and email — enough to distinguish and select the correct account.
**Priority:** High

### TC-SA-03-01-016 — Recent searches and saved searches work; saved searches store the query, not results
**Type:** Positive
**Covers:** 1.2 → Recent searches and saved searches; Rule: saved searches store the query, not the results; re-running reflects current data
**Preconditions:** A search has been performed and saved.
**Steps:**
1. Verify the recent-searches list contains the performed search.
2. Save a search ("parent name + institute").
3. Change the underlying data (e.g., a matching account's status changes).
4. Re-run the saved search.
**Expected Result:** Recent searches are listed; the saved search re-runs the stored query against current data — the result reflects the change, proving the query (not a snapshot) was stored.
**Priority:** Medium

### TC-SA-03-01-017 — Deep link from a search result opens the full account record
**Type:** Positive
**Covers:** 1.2 → Deep link from a search result to the full account record
**Preconditions:** A search result is displayed.
**Steps:**
1. Copy the deep link for a search result.
2. Open the link in a new session.
**Expected Result:** The deep link opens the same full account record as reached by browsing — no difference in access or detail.
**Priority:** Medium

### TC-SA-03-01-018 — Case-insensitive name/email matching; phone matching ignores formatting
**Type:** Edge
**Covers:** 1.2 → Rule: search matches are case-insensitive for names and emails; phone matching ignores formatting differences
**Preconditions:** An account with email "Rahul.Sharma@Example.com" and phone "+91 98765 43210".
**Steps:**
1. Search "rahul.sharma@example.com" (lowercase).
2. Search the phone as "9876543210" (no formatting).
**Expected Result:** Both searches find the account — case and phone formatting differences do not prevent a match.
**Priority:** High

### TC-SA-03-01-019 — Partial email/phone searches return candidates for confirmation
**Type:** Edge
**Covers:** 1.2 → Rule: searching a partial email or phone returns candidates; the user confirms the exact account before acting
**Preconditions:** Multiple accounts share a phone prefix.
**Steps:**
1. Search a partial phone that matches several accounts.
2. Attempt to act on the result set without selecting a specific account.
**Expected Result:** Candidates are returned; no bulk action is possible without confirming the exact account.
**Priority:** Medium

### TC-SA-03-01-020 — Search results respect field visibility and audit rules
**Type:** Positive
**Covers:** 1.2 → Rule: search results respect the same field visibility and audit rules as the directory view
**Preconditions:** The privacy display policy masks sensitive fields.
**Steps:**
1. Search for an account and inspect the sensitive fields in the result.
2. Compare the masking with the directory view.
**Expected Result:** Search results apply the same field visibility (masking) and audit rules as the directory view.
**Priority:** Medium

### TC-SA-03-01-021 — Search does not bypass permissions
**Type:** Negative
**Covers:** 1.2 → Rule: search does not bypass permissions; a role cannot search for or open records outside its scope
**Preconditions:** A scoped sub-admin is logged in; an account exists outside its scope.
**Steps:**
1. As the sub-admin, search for the out-of-scope account by exact email.
2. Attempt to open the record if it appears.
**Expected Result:** The out-of-scope account is not returned (or cannot be opened) — search respects the role's scope.
**Priority:** Critical

### TC-SA-03-01-022 — Deep links are permission-checked on open
**Type:** Negative
**Covers:** 1.2 → Rule: deep links to account records are permission-checked on open (a shared link does not grant access)
**Preconditions:** A deep link to an account record is copied; a second user without permission to that account exists.
**Steps:**
1. Share the deep link with the second user.
2. Have the second user open the link.
**Expected Result:** The link is permission-checked on open — the second user is denied access to the record.
**Priority:** High

## 1.3 Filter Users by Type, Status, and Attributes

### TC-SA-03-01-023 — Filter by each account type
**Type:** Positive
**Covers:** 1.3 → Filter by type (Sub Admin, Student, Parent, Affiliate, Institute)
**Preconditions:** Accounts exist for all five types.
**Steps:**
1. Apply the type filter for each of the five types in turn.
2. Verify the returned set.
**Expected Result:** Each type filter returns exactly the accounts of that type — no cross-type leakage.
**Priority:** High

### TC-SA-03-01-024 — Filter by each status
**Type:** Positive
**Covers:** 1.3 → Filter by status (Active, Suspended, Deactivated, Pending verification)
**Preconditions:** Accounts exist in all four statuses.
**Steps:**
1. Apply the status filter for each of the four statuses in turn.
2. Verify the returned set.
**Expected Result:** Each status filter returns exactly the accounts in that status.
**Priority:** High

### TC-SA-03-01-025 — Filter by institute, membership plan/state, role, verification state
**Type:** Positive
**Covers:** 1.3 → Filter by institute, membership plan/state, role, verification state
**Preconditions:** Accounts span multiple institutes, plans, roles, and verification states.
**Steps:**
1. Filter by a specific institute → verify only that institute's accounts.
2. Filter by membership plan/state, role, and verification state in turn.
**Expected Result:** Each attribute filter returns exactly the matching accounts.
**Priority:** High

### TC-SA-03-01-026 — Filter by date ranges: registered between, last active within
**Type:** Positive
**Covers:** 1.3 → Filter by date ranges (registered between, last active within)
**Preconditions:** Accounts registered across different dates with varying last-activity times.
**Steps:**
1. Filter "registered between [D1] and [D2]" → verify the set.
2. Filter "last active within [window]" → verify the set.
**Expected Result:** Both date-range filters return exactly the accounts within the specified ranges.
**Priority:** Medium

### TC-SA-03-01-027 — Combinable filters use AND logic with a visible active-filter summary
**Type:** Positive
**Covers:** 1.3 → Combinable filters (AND logic) with a clear active-filter summary; Rule: filters combine with AND logic; the active-filter summary is always visible
**Preconditions:** Filters for type, status, and date range are available.
**Steps:**
1. Apply type=Student AND status=Pending verification AND registered within 90 days.
2. Verify the result set is the intersection.
3. Verify the active-filter summary displays all three filters.
**Expected Result:** The result is the AND intersection of all filters; the active-filter summary is always visible and unambiguous.
**Priority:** Critical

### TC-SA-03-01-028 — Saved filter presets store the definition, not results
**Type:** Positive
**Covers:** 1.3 → Saved filter presets for recurring views; Rule: saved presets store the filter definition, not the results; re-running reflects current data
**Preconditions:** A filter preset "Suspended — last 90 days" is saved.
**Steps:**
1. Save the preset.
2. Change the underlying data (a new account is suspended).
3. Re-run the preset.
**Expected Result:** The preset re-applies the stored filter definition against current data — the new suspended account appears.
**Priority:** Medium

### TC-SA-03-01-029 — The matching count is always visible before any action
**Type:** Positive
**Covers:** 1.3 → Count of matching records always visible; Rule: the matching count is shown before any action, so bulk operations target a known set
**Preconditions:** A filter is applied that matches a known number of accounts.
**Steps:**
1. Apply the filter.
2. Verify the matching count is displayed before selecting any accounts.
**Expected Result:** The count of matching records is always visible — the cohort size is known before any action.
**Priority:** High

### TC-SA-03-01-030 — Export of the filtered set respects field visibility and is audit-logged
**Type:** Positive
**Covers:** 1.3 → Export of the filtered set; Rule: exports of filtered sets respect field visibility and are audit-logged
**Preconditions:** A filtered set is active with a hidden sensitive column.
**Steps:**
1. Export the filtered set.
2. Verify the rows and visible fields match the on-screen view.
3. Check the audit trail for the export.
**Expected Result:** The export contains exactly the filtered set with the same field visibility; the export is audit-logged.
**Priority:** Medium

### TC-SA-03-01-031 — Filters apply server-side; results are consistent regardless of page size
**Type:** Edge
**Covers:** 1.3 → Rule: filters apply server-side; results are consistent regardless of page size
**Preconditions:** A filter matches a set larger than one page.
**Steps:**
1. Apply the filter with the default page size and record the count.
2. Change the page size and re-apply the filter.
**Expected Result:** The count and the set are identical regardless of page size — filtering is server-side and consistent.
**Priority:** Medium

### TC-SA-03-01-032 — A zero-match filter shows an empty state with the active filters
**Type:** Edge
**Covers:** 1.3 → Rule: a filter that matches zero records shows an empty state with the active filters, not an error
**Preconditions:** A filter combination that matches no accounts (e.g., type=Institute + status=Pending verification + a date range with no institutes).
**Steps:**
1. Apply the zero-match filter combination.
2. Observe the view.
**Expected Result:** An empty state is shown with the active filters listed — no error, no crash.
**Priority:** Medium

## 1.4 Account Record Detail View

### TC-SA-03-01-033 — Identity and contact section shows all fields per display policy
**Type:** Positive
**Covers:** 1.4 → Identity and contact: name, email, phone, date of birth (per display policy), address
**Preconditions:** An account with a complete identity and contact profile.
**Steps:**
1. Open the account record.
2. Verify the identity and contact section: name, email, phone, DOB (per display policy), address.
**Expected Result:** All identity/contact fields are present and accurate; DOB follows the privacy display policy.
**Priority:** High

### TC-SA-03-01-034 — Verification state shows email, phone, age, and parental consent
**Type:** Positive
**Covers:** 1.4 → Verification state: email, phone, age, parental consent (for minors)
**Preconditions:** A minor student account with email verified, phone verified, age verified, and parental consent captured.
**Steps:**
1. Open the account record.
2. Verify the verification state section shows each verification dimension and its state.
**Expected Result:** The verification state section accurately reflects email, phone, age, and parental consent states.
**Priority:** High

### TC-SA-03-01-035 — Roles and effective permissions summary links to the full permission view
**Type:** Positive
**Covers:** 1.4 → Roles and effective permissions summary (link to the full permission view)
**Preconditions:** An account holding two roles.
**Steps:**
1. Open the account record.
2. Verify the roles and effective permissions summary lists both roles.
3. Follow the link to the full permission view.
**Expected Result:** The summary lists the roles and effective permissions; the link opens the full permission view (Module 2) for the account.
**Priority:** High

### TC-SA-03-01-036 — Sessions section shows current active sessions and recent history
**Type:** Positive
**Covers:** 1.4 → Sessions: current active sessions and recent session history
**Preconditions:** An account with one active session and prior session history.
**Steps:**
1. Open the account record.
2. Verify the sessions section shows the active session (device, location, last activity) and recent history.
**Expected Result:** The active session and recent session history are displayed accurately.
**Priority:** High

### TC-SA-03-01-037 — Membership section shows plan, status, renewal date, and payment history summary
**Type:** Positive
**Covers:** 1.4 → Membership: current plan, status, renewal date, payment history summary
**Preconditions:** An account with an active membership and payment history.
**Steps:**
1. Open the account record.
2. Verify the membership section: current plan, status, renewal date, payment history summary.
**Expected Result:** All membership fields are present and match the billing records.
**Priority:** High

### TC-SA-03-01-038 — Links section shows parent↔child, student↔institute, and license seat
**Type:** Positive
**Covers:** 1.4 → Links: parent↔child links, student↔institute link, license seat
**Preconditions:** A minor student linked to a parent, an institute, and a license seat.
**Steps:**
1. Open the student's record.
2. Verify the links section shows the parent link, the institute link, and the license seat.
**Expected Result:** All three link types are displayed with the correct targets.
**Priority:** High

### TC-SA-03-01-039 — Activity history lists logins, status changes, role changes, and support interactions
**Type:** Positive
**Covers:** 1.4 → Activity history: logins, status changes, role changes, support interactions
**Preconditions:** An account with recent logins, a status change, a role change, and a support interaction.
**Steps:**
1. Open the account record.
2. Verify the activity history lists each event type with timestamps.
**Expected Result:** All four event types appear in the activity history with correct timestamps.
**Priority:** High

### TC-SA-03-01-040 — Quick actions: change status, assign role, view permissions, open support context
**Type:** Positive
**Covers:** 1.4 → Quick actions: change status, assign role, view permissions, open support context
**Preconditions:** Super Admin logged in; an account record is open.
**Steps:**
1. Use the quick action to change status (with reason).
2. Use the quick action to assign a role.
3. Use the quick action to view permissions.
4. Use the quick action to open the support context.
**Expected Result:** All four quick actions work and route to the owning module's flow with its confirmations and audit.
**Priority:** High

### TC-SA-03-01-041 — Audit entries tab lists every change with actor and timestamp
**Type:** Positive
**Covers:** 1.4 → Audit entries for the account (who changed what, when)
**Preconditions:** An account with multiple recorded changes (registration, verification, enrollment, session termination).
**Steps:**
1. Open the account record's audit entries tab.
2. Verify each change is listed with the actor and timestamp.
**Expected Result:** Every change to the account is listed with who changed what and when — the full audit chain is visible.
**Priority:** Critical

### TC-SA-03-01-042 — The record aggregates live data; it is a view, not a separate store
**Type:** Edge
**Covers:** 1.4 → Rule: the record aggregates live data from across modules; it is a view, not a separate store
**Preconditions:** An account's membership state is about to change in the billing module.
**Steps:**
1. Open the account record and note the membership state.
2. Change the membership state in the billing module.
3. Re-open the account record.
**Expected Result:** The record reflects the new membership state immediately — it aggregates live data, not a cached copy.
**Priority:** Medium

### TC-SA-03-01-043 — Sensitive fields in the record follow the privacy display policy; viewing is audit-logged
**Type:** Positive
**Covers:** 1.4 → Rule: sensitive fields follow the privacy display policy; viewing them is audit-logged where required
**Preconditions:** The privacy display policy masks DOB by default.
**Steps:**
1. Open the account record and observe the DOB field.
2. Reveal the DOB where the policy allows.
3. Check the audit trail for the viewing event.
**Expected Result:** The DOB is masked per policy; revealing it is audit-logged where required.
**Priority:** Medium

### TC-SA-03-01-044 — Quick actions are permission-gated and route to the owning module's flow
**Type:** Negative
**Covers:** 1.4 → Rule: quick actions are permission-gated and each routes to the owning module's flow (with its own confirmations and audit)
**Preconditions:** A sub-admin without status-change permission opens an account record.
**Steps:**
1. As the sub-admin, attempt the change-status quick action.
2. As the Super Admin, use the quick action and verify it routes to the status flow with confirmation.
**Expected Result:** The sub-admin's action is unavailable (gated); the Super Admin's action routes to the owning module's flow with its confirmation and audit.
**Priority:** High

### TC-SA-03-01-045 — Activity history and audit entries are append-only
**Type:** Negative
**Covers:** 1.4 → Rule: the activity history and audit entries are append-only; the record shows current state plus immutable history
**Preconditions:** An account with existing activity history and audit entries.
**Steps:**
1. Attempt to edit an existing activity history entry.
2. Attempt to delete an existing audit entry.
**Expected Result:** Both attempts fail — the history and audit entries are append-only and immutable.
**Priority:** Critical

### TC-SA-03-01-046 — Links are navigable in both directions
**Type:** Positive
**Covers:** 1.4 → Rule: links (parent↔child, student↔institute) are navigable in both directions from the record
**Preconditions:** A parent linked to a child; a student linked to an institute.
**Steps:**
1. From the parent's record, navigate to the child's record.
2. From the child's record, navigate back to the parent's record.
3. Repeat for the student↔institute link in both directions.
**Expected Result:** Every link is navigable in both directions — no dead ends.
**Priority:** Medium

### TC-SA-03-01-047 — The record is the canonical place for the full picture of an account
**Type:** Positive
**Covers:** 1.4 → Rule: the record is the canonical place to answer "what is the full picture of this account?"
**Preconditions:** An account with data spread across modules (verification, roles, sessions, membership, links, activity).
**Steps:**
1. Open the account record.
2. Verify every dimension of the account's state is reachable from the record without leaving it.
**Expected Result:** The full picture — identity, verification, roles, sessions, membership, links, activity, audit — is consolidated in the record.
**Priority:** Medium