# 4. Account Linking — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: account_linking.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 |
|---------|--------------------|----------|
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Link a parent to a child account (one parent to many children; a child to the appropriate guardian(s)) | TC-SA-03-04-001 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Link creation at registration (guardian provided during the minor's signup) or afterward (admin-initiated) | TC-SA-03-04-002 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Guardian identity verification before a link is established | TC-SA-03-04-003 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Consent relationship: the link carries the parental-consent state for the minor | TC-SA-03-04-004 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Parent visibility: the parent sees their linked children's accounts and (per policy) progress/communications | TC-SA-03-04-005 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Unlink with reason (e.g., corrected relationship, guardian change) | TC-SA-03-04-006 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Audit logging of link creation and removal | TC-SA-03-04-007 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: a link is not established without guardian identity verification | TC-SA-03-04-008 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: one parent can link to multiple children; a child links to the appropriate guardian(s) | TC-SA-03-04-001 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: the link carries the consent relationship: the minor's consent state is tied to the verified guardian | TC-SA-03-04-004 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: unlinking requires a reason and, for guardian changes, verification of the new guardian; audit-logged | TC-SA-03-04-006 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: parent visibility is scoped to linked children only; a parent never sees unrelated accounts | TC-SA-03-04-009 |
| 4.1 Link Parent Accounts to Multiple Children's Accounts | Rule: all link changes are audit-logged with the verification method and the acting admin | TC-SA-03-04-007 |
| 4.2 Link Student Accounts to Institute Accounts | Link a student to an institute (at creation, bulk upload, or afterward) | TC-SA-03-04-010 |
| 4.2 Link Student Accounts to Institute Accounts | One student to one primary institute (with a clear primary-institute rule) | TC-SA-03-04-011 |
| 4.2 Link Student Accounts to Institute Accounts | Seat association: the link can carry the student's license seat under the institute | TC-SA-03-04-012 |
| 4.2 Link Student Accounts to Institute Accounts | Institute visibility: the institute sees its linked students per its permissions | TC-SA-03-04-013 |
| 4.2 Link Student Accounts to Institute Accounts | Re-linking: move a student to a different institute (with seat handling) | TC-SA-03-04-014 |
| 4.2 Link Student Accounts to Institute Accounts | Unlink: remove a student from an institute (with seat release) | TC-SA-03-04-015 |
| 4.2 Link Student Accounts to Institute Accounts | Audit logging of link creation, change, and removal | TC-SA-03-04-016 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: a student has one primary institute link; re-linking is a move (old released, new allocated), not a duplicate | TC-SA-03-04-014 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: re-linking and unlinking handle the seat explicitly; no seat is double-allocated | TC-SA-03-04-017 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: the student's own account and progress survive institute changes; only the association changes | TC-SA-03-04-018 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: institute visibility is scoped to linked students; an institute never sees unlinked or other-institute students | TC-SA-03-04-019 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: a re-link to an institute with no available seats is blocked | TC-SA-03-04-020 |
| 4.2 Link Student Accounts to Institute Accounts | Rule: all link changes are audit-logged with the institutes, seat handling, and the acting admin | TC-SA-03-04-016 |
| 4.3 Link Integrity and Validation | Validation at link creation: both accounts exist, identity/relationship verified, constraints satisfied | TC-SA-03-04-021 |
| 4.3 Link Integrity and Validation | Anomaly detection: duplicate parent↔child links, student linked to two institutes, links to deactivated accounts | TC-SA-03-04-022 |
| 4.3 Link Integrity and Validation | Orphaned-link handling: a link whose target account was deactivated/deleted is flagged and resolved | TC-SA-03-04-023 |
| 4.3 Link Integrity and Validation | Referential integrity: links always resolve to valid accounts; broken references are surfaced, not silently followed | TC-SA-03-04-024 |
| 4.3 Link Integrity and Validation | Link consistency report: counts and anomalies across all link types | TC-SA-03-04-025 |
| 4.3 Link Integrity and Validation | Audit logging of validation outcomes and anomaly resolutions | TC-SA-03-04-026 |
| 4.3 Link Integrity and Validation | Rule: validation at creation prevents most anomalies; a second primary-institute link or a link without verification is blocked at the source | TC-SA-03-04-027 |
| 4.3 Link Integrity and Validation | Rule: anomalies that do occur are surfaced in the consistency report, not hidden | TC-SA-03-04-022 |
| 4.3 Link Integrity and Validation | Rule: orphaned links are flagged and resolved; they are never silently followed | TC-SA-03-04-023 |
| 4.3 Link Integrity and Validation | Rule: seat integrity is part of link integrity: a student never holds two seats; a released seat returns to the pool | TC-SA-03-04-028 |
| 4.3 Link Integrity and Validation | Rule: anomaly resolutions are deliberate, reason-recorded, and audit-logged | TC-SA-03-04-026 |
| 4.3 Link Integrity and Validation | Rule: the consistency report is recurring, so link health is continuously verified | TC-SA-03-04-029 |

## 4.1 Link Parent Accounts to Multiple Children's Accounts

### TC-SA-03-04-001 — A parent can be linked to multiple children; a child to the appropriate guardian(s)
**Type:** Positive
**Covers:** 4.1 → Link a parent to a child account (one parent to many children; a child to the appropriate guardian(s)); Rule: one parent can link to multiple children; a child links to the appropriate guardian(s) per the relationship
**Preconditions:** A parent account and three minor student accounts.
**Steps:**
1. Link the parent to each of the three children (with guardian verification).
2. Open the parent's record and verify all three linked children.
3. Open each child's record and verify the parent link.
**Expected Result:** The parent is linked to all three children; each child shows the appropriate guardian — one parent to many children works.
**Priority:** Critical

### TC-SA-03-04-002 — Link creation at registration or afterward (admin-initiated)
**Type:** Positive
**Covers:** 4.1 → Link creation at registration (guardian provided during the minor's signup) or afterward (admin-initiated)
**Preconditions:** One minor registers with a guardian email; another minor's guardian link is created afterward by the Super Admin.
**Steps:**
1. Complete the first minor's registration with the guardian's email — verify the link is proposed and established after guardian verification.
2. For the second minor, have the Super Admin initiate the link afterward (with guardian verification).
**Expected Result:** Both paths work: the registration-time link and the admin-initiated link are established identically (both require guardian verification).
**Priority:** High

### TC-SA-03-04-003 — Guardian identity verification is required before a link is established
**Type:** Positive
**Covers:** 4.1 → Guardian identity verification before a link is established (see Authentication & Access)
**Preconditions:** A parent↔child link is being proposed; the guardian has not yet verified.
**Steps:**
1. Propose the link.
2. Verify the link is pending (not established) until the guardian verifies.
3. Complete the guardian's OTP verification and relationship confirmation.
4. Verify the link is established.
**Expected Result:** The link is not established until the guardian verifies their identity (OTP) and confirms the relationship; after verification, the link is established.
**Priority:** Critical

### TC-SA-03-04-004 — The link carries the parental-consent state for the minor
**Type:** Positive
**Covers:** 4.1 → Consent relationship: the link carries the parental-consent state for the minor; Rule: the minor's consent state is tied to the verified guardian
**Preconditions:** A parent↔child link is established for a minor.
**Steps:**
1. Capture the parental consent against the child's account.
2. Open the child's record and verify the consent state is tied to the verified guardian.
**Expected Result:** The consent state is carried on the link and tied to the verified guardian — the minor's consent is attributable to the correct guardian.
**Priority:** Critical

### TC-SA-03-04-005 — Parent visibility: the parent sees their linked children's accounts and (per policy) progress/communications
**Type:** Positive
**Covers:** 4.1 → Parent visibility: the parent sees their linked children's accounts and (per policy) progress/communications
**Preconditions:** A parent is linked to two children with progress data.
**Steps:**
1. Log in as the parent.
2. Verify the parent sees both linked children's accounts.
3. Verify the parent sees (per policy) the children's progress and communications.
**Expected Result:** The parent sees exactly their linked children's accounts and, per policy, their progress and communications.
**Priority:** High

### TC-SA-03-04-006 — Unlink requires a reason and, for guardian changes, verification of the new guardian; it is audit-logged
**Type:** Positive
**Covers:** 4.1 → Unlink with reason (e.g., corrected relationship, guardian change); Rule: unlinking requires a reason and, for guardian changes, verification of the new guardian; it is audit-logged
**Preconditions:** A parent↔child link exists; a guardian change is requested.
**Steps:**
1. Attempt to unlink without a reason.
2. Provide the reason "guardian change" and verify the new guardian's identity and authority.
3. Complete the unlink and re-capture consent from the new guardian.
4. Verify the audit entry.
**Expected Result:** The unlink is blocked without a reason; for a guardian change, the new guardian is verified; the unlink is audit-logged with the verification method and the acting admin.
**Priority:** High

### TC-SA-03-04-007 — All link changes are audit-logged with the verification method and the acting admin
**Type:** Positive
**Covers:** 4.1 → Audit logging of link creation and removal; Rule: all link changes are audit-logged with the verification method and the acting admin
**Preconditions:** A link creation and a link removal have occurred.
**Steps:**
1. Open the audit trail and filter by "link change".
2. Verify each entry.
**Expected Result:** Both the creation and the removal are audit-logged with the verification method (e.g., OTP) and the acting admin.
**Priority:** Critical

### TC-SA-03-04-008 — An unverified link is not accepted
**Type:** Negative
**Covers:** 4.1 → Rule: a link is not established without guardian identity verification; an unverified link is not accepted
**Preconditions:** A parent↔child link is proposed; the guardian declines or fails verification.
**Steps:**
1. Propose the link.
2. Have the guardian fail the OTP verification (wrong code three times).
3. Check the link state.
**Expected Result:** The link is not established — an unverified link is not accepted; the link remains pending or is rejected.
**Priority:** Critical

### TC-SA-03-04-009 — Parent visibility is scoped to linked children only; a parent never sees unrelated accounts
**Type:** Negative
**Covers:** 4.1 → Rule: parent visibility is scoped to linked children only; a parent never sees unrelated accounts
**Preconditions:** A parent is linked to two children; a third child (unrelated) exists.
**Steps:**
1. Log in as the parent.
2. Attempt to view the unrelated third child's account.
**Expected Result:** The parent sees only their two linked children; the unrelated account is not visible — visibility is strictly scoped.
**Priority:** Critical

## 4.2 Link Student Accounts to Institute Accounts

### TC-SA-03-04-010 — A student can be linked to an institute at creation, bulk upload, or afterward
**Type:** Positive
**Covers:** 4.2 → Link a student to an institute (at creation, bulk upload, or afterward)
**Preconditions:** One student is created individually, one via bulk upload, and one is linked afterward.
**Steps:**
1. Create a student account with the institute link at creation — verify the link.
2. Bulk-upload a student — verify the link is created automatically.
3. Link a third student to the institute afterward — verify the link.
**Expected Result:** All three paths establish the student↔institute link correctly.
**Priority:** High

### TC-SA-03-04-011 — One student to one primary institute (clear primary-institute rule)
**Type:** Positive
**Covers:** 4.2 → One student to one primary institute (with a clear primary-institute rule)
**Preconditions:** A student is linked to Institute A.
**Steps:**
1. Open the student's record and verify the primary institute is Institute A.
2. Attempt to create a second primary-institute link to Institute B without re-linking.
**Expected Result:** The student has exactly one primary institute; a second primary link is not created without a re-link (which is a move, not a duplicate).
**Priority:** Critical

### TC-SA-03-04-012 — The link can carry the student's license seat under the institute
**Type:** Positive
**Covers:** 4.2 → Seat association: the link can carry the student's license seat under the institute
**Preconditions:** An institute with available seats; a student is linked with a seat.
**Steps:**
1. Link the student to the institute with a seat.
2. Verify the seat is allocated under the institute's license.
3. Verify the link carries the seat association.
**Expected Result:** The link carries the student's license seat; the seat is allocated under the institute's license and visible in the seat list.
**Priority:** High

### TC-SA-03-04-013 — Institute visibility: the institute sees its linked students per its permissions
**Type:** Positive
**Covers:** 4.2 → Institute visibility: the institute sees its linked students per its permissions
**Preconditions:** An institute is linked to 200 students.
**Steps:**
1. Log in as the institute admin.
2. Verify the institute sees its 200 linked students in its directory.
**Expected Result:** The institute sees exactly its linked students, per its permissions.
**Priority:** High

### TC-SA-03-04-014 — Re-linking moves a student to a different institute with seat handling
**Type:** Positive
**Covers:** 4.2 → Re-linking: move a student to a different institute (with seat handling); Rule: a student has one primary institute link; re-linking is a move (old released, new allocated), not a duplicate
**Preconditions:** A student is linked to Institute A with a seat; Institute B has available seats.
**Steps:**
1. Initiate the re-link to Institute B.
2. Verify the seat is released under Institute A and allocated under Institute B.
3. Verify the student has exactly one primary institute (B).
**Expected Result:** The re-link is a move: the old link (A) is released, the new link (B) is allocated, and the seat moves with the student — no duplicate.
**Priority:** Critical

### TC-SA-03-04-015 — Unlink removes a student from an institute with seat release
**Type:** Positive
**Covers:** 4.2 → Unlink: remove a student from an institute (with seat release)
**Preconditions:** A student is linked to an institute with a seat.
**Steps:**
1. Unlink the student from the institute.
2. Verify the seat is released back to the institute's license pool.
3. Verify the student account remains (only the association is removed).
**Expected Result:** The student is unlinked; the seat is released to the pool; the student's own account survives — only the institute association is removed.
**Priority:** High

### TC-SA-03-04-016 — All link changes are audit-logged with the institutes, seat handling, and the acting admin
**Type:** Positive
**Covers:** 4.2 → Audit logging of link creation, change, and removal; Rule: all link changes are audit-logged with the institutes, seat handling, and the acting admin
**Preconditions:** A link creation, a re-link, and an unlink have occurred.
**Steps:**
1. Open the audit trail and filter by "institute link".
2. Verify each entry.
**Expected Result:** All three changes are audit-logged with the institutes involved, the seat handling, and the acting admin.
**Priority:** Critical

### TC-SA-03-04-017 — Re-linking and unlinking handle the seat explicitly; no seat is double-allocated
**Type:** Negative
**Covers:** 4.2 → Rule: re-linking and unlinking handle the seat explicitly: a seat is released before or as part of the move, so no seat is double-allocated
**Preconditions:** A student holds a seat under Institute A.
**Steps:**
1. Re-link the student to Institute B.
2. Check the seat state under both institutes.
**Expected Result:** The seat is released under A and allocated under B — the student never holds two seats; no double-allocation.
**Priority:** Critical

### TC-SA-03-04-018 — The student's own account and progress survive institute changes
**Type:** Positive
**Covers:** 4.2 → Rule: the student's own account and progress survive institute changes; only the association changes
**Preconditions:** A student has course progress under Institute A and is re-linked to Institute B.
**Steps:**
1. Re-link the student to Institute B.
2. Verify the student's account and progress are preserved.
3. Verify the old institute no longer sees the student; the new institute does.
**Expected Result:** The student's account and progress survive; only the institute association changes — the old institute loses visibility, the new institute gains it.
**Priority:** High

### TC-SA-03-04-019 — Institute visibility is scoped to linked students; an institute never sees unlinked or other-institute students
**Type:** Negative
**Covers:** 4.2 → Rule: institute visibility is scoped to linked students; an institute never sees unlinked or other-institute students
**Preconditions:** Institute A is linked to 100 students; Institute B is linked to 50; one student is unlinked.
**Steps:**
1. Log in as Institute A's admin.
2. Attempt to view Institute B's students and the unlinked student.
**Expected Result:** Institute A sees only its 100 linked students — not Institute B's students and not the unlinked student.
**Priority:** Critical

### TC-SA-03-04-020 — A re-link to an institute with no available seats is blocked
**Type:** Negative
**Covers:** 4.2 → Rule: a re-link to an institute with no available seats is blocked (the seat must be available first)
**Preconditions:** Institute B has 0 available seats; a student is to be re-linked to B.
**Steps:**
1. Initiate the re-link to Institute B.
**Expected Result:** The re-link is blocked with a clear message — no available seats under Institute B's license.
**Priority:** Critical

## 4.3 Link Integrity and Validation

### TC-SA-03-04-021 — Validation at link creation: both accounts exist, identity/relationship verified, constraints satisfied
**Type:** Positive
**Covers:** 4.3 → Validation at link creation: both accounts exist, identity/relationship verified, constraints satisfied (one primary institute, seat available)
**Preconditions:** A valid parent↔child link and a valid student↔institute link are being created.
**Steps:**
1. Create the parent↔child link — verify both accounts exist, the guardian is verified, and the relationship is correct.
2. Create the student↔institute link — verify both accounts exist, the primary-institute constraint is satisfied, and a seat is available.
**Expected Result:** Both links pass validation at creation — all constraints are checked and satisfied.
**Priority:** Critical

### TC-SA-03-04-022 — Anomaly detection: duplicate parent↔child links, student linked to two institutes, links to deactivated accounts
**Type:** Positive
**Covers:** 4.3 → Anomaly detection: duplicate parent↔child links, student linked to two institutes, links to deactivated accounts; Rule: anomalies that do occur are surfaced in the consistency report, not hidden
**Preconditions:** The system contains: 3 duplicate parent↔child links, 1 student linked to two institutes, 2 links pointing to deactivated accounts.
**Steps:**
1. Run the link consistency report.
2. Verify all anomalies are detected and listed.
**Expected Result:** The report highlights all anomalies: the 3 duplicate parent↔child links, the 1 student linked to two institutes, and the 2 links to deactivated accounts.
**Priority:** Critical

### TC-SA-03-04-023 — Orphaned links (target deactivated/deleted) are flagged and resolved; never silently followed
**Type:** Positive
**Covers:** 4.3 → Orphaned-link handling: a link whose target account was deactivated/deleted is flagged and resolved; Rule: orphaned links are flagged and resolved; they are never silently followed
**Preconditions:** Two links point to deactivated accounts.
**Steps:**
1. Run the consistency report and locate the orphaned links.
2. Resolve each: where the relationship is historical, mark the link resolved; where it should be active, review the account for re-activation.
3. Verify the orphaned links are not silently followed.
**Expected Result:** Both orphaned links are flagged and resolved deliberately — none is silently followed.
**Priority:** High

### TC-SA-03-04-024 — Referential integrity: links always resolve to valid accounts; broken references are surfaced
**Type:** Positive
**Covers:** 4.3 → Referential integrity: links always resolve to valid accounts; broken references are surfaced, not silently followed
**Preconditions:** A link points to a deleted account (broken reference).
**Steps:**
1. Attempt to navigate the broken link.
2. Verify the broken reference is surfaced, not silently followed.
**Expected Result:** The broken reference is surfaced (flagged in the consistency report) — it is not silently followed to a non-existent account.
**Priority:** High

### TC-SA-03-04-025 — Link consistency report shows counts and anomalies across all link types
**Type:** Positive
**Covers:** 4.3 → Link consistency report: counts and anomalies across all link types
**Preconditions:** Links of all types exist (parent↔child, student↔institute) with some anomalies.
**Steps:**
1. Run the link consistency report.
2. Verify the total link counts by type and the anomaly highlights.
**Expected Result:** The report shows total links by type and highlights all anomalies — a complete view of link health.
**Priority:** High

### TC-SA-03-04-026 — Anomaly resolutions are deliberate, reason-recorded, and audit-logged
**Type:** Positive
**Covers:** 4.3 → Audit logging of validation outcomes and anomaly resolutions; Rule: anomaly resolutions are deliberate, reason-recorded, and audit-logged
**Preconditions:** An anomaly (duplicate parent↔child link) is resolved.
**Steps:**
1. Resolve the anomaly with a reason.
2. Verify the audit entry.
**Expected Result:** The resolution is audit-logged with the link, the action, the reason, and the acting admin.
**Priority:** Critical

### TC-SA-03-04-027 — Validation at creation blocks a second primary-institute link or a link without verification
**Type:** Negative
**Covers:** 4.3 → Rule: validation at creation prevents most anomalies: a second primary-institute link or a link without verification is blocked at the source
**Preconditions:** A student already has a primary institute; a parent↔child link is proposed without guardian verification.
**Steps:**
1. Attempt to create a second primary-institute link for the student.
2. Attempt to create the parent↔child link without guardian verification.
**Expected Result:** Both are blocked at the source — the second primary link and the unverified link are not created.
**Priority:** Critical

### TC-SA-03-04-028 — Seat integrity: a student never holds two seats; a released seat returns to the pool
**Type:** Positive
**Covers:** 4.3 → Rule: seat integrity is part of link integrity: a student never holds two seats, and a released seat returns to the pool
**Preconditions:** A student holds one seat; the student is unlinked.
**Steps:**
1. Verify the student holds exactly one seat before the unlink.
2. Unlink the student.
3. Verify the seat returns to the institute's available pool.
**Expected Result:** The student never holds two seats; after the unlink, the seat returns to the pool — seat integrity is maintained.
**Priority:** Critical

### TC-SA-03-04-029 — The consistency report is recurring, so link health is continuously verified
**Type:** Positive
**Covers:** 4.3 → Rule: the consistency report is recurring, so link health is continuously verified, not only on demand
**Preconditions:** A recurring run of the consistency report is configured.
**Steps:**
1. Configure the recurring run.
2. Introduce a new anomaly (e.g., a duplicate link via an edge case).
3. Verify the recurring run catches the new anomaly.
**Expected Result:** The recurring run detects the new anomaly — link health is continuously verified, not only on demand.
**Priority:** Medium