# 2. Role Assignment — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: role_assignment.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 |
|---------|--------------------|----------|
| 2.1 Assign Roles to User Accounts | Assign one or more roles from the user record or the role's holder view | TC-SA-02-02-001, TC-SA-02-02-002 |
| 2.1 Assign Roles to User Accounts | Bulk assignment: apply a role to a selected group of users | TC-SA-02-02-003 |
| 2.1 Assign Roles to User Accounts | Active-role-only picker | TC-SA-02-02-004 |
| 2.1 Assign Roles to User Accounts | Immediate effect: access updates on the next request | TC-SA-02-02-005 |
| 2.1 Assign Roles to User Accounts | Optional notification to the user on assignment (per policy) | TC-SA-02-02-006 |
| 2.1 Assign Roles to User Accounts | Audit logging of every assignment with actor, user, role, timestamp | TC-SA-02-02-007 |
| 2.1 Assign Roles to User Accounts | Rule: only active roles assignable; archived excluded | TC-SA-02-02-004 |
| 2.1 Assign Roles to User Accounts | Rule: multiple roles allowed; effective access is the union | TC-SA-02-02-008 |
| 2.1 Assign Roles to User Accounts | Rule: takes effect on next request; no re-login | TC-SA-02-02-005 |
| 2.1 Assign Roles to User Accounts | Rule: bulk assignments require a confirmed preview | TC-SA-02-02-009 |
| 2.1 Assign Roles to User Accounts | Rule: bulk assignments logged as a batch with the member list | TC-SA-02-02-010 |
| 2.1 Assign Roles to User Accounts | Rule: assignment does not create the user account | TC-SA-02-02-011 |
| 2.2 Reassign or Remove Roles | Remove a single role from a user | TC-SA-02-02-012 |
| 2.2 Reassign or Remove Roles | Reassign: replace one role with another in a single action | TC-SA-02-02-013 |
| 2.2 Reassign or Remove Roles | Review the user's full role set before and after | TC-SA-02-02-014 |
| 2.2 Reassign or Remove Roles | Guardrail: cannot be left with no roles if at least one is required | TC-SA-02-02-015 |
| 2.2 Reassign or Remove Roles | Immediate effect on the next request | TC-SA-02-02-016 |
| 2.2 Reassign or Remove Roles | Audit logging with before/after role sets | TC-SA-02-02-017 |
| 2.2 Reassign or Remove Roles | Rule: removal revokes on next request; in-progress actions complete | TC-SA-02-02-018 |
| 2.2 Reassign or Remove Roles | Rule: reassignment is atomic | TC-SA-02-02-019 |
| 2.2 Reassign or Remove Roles | Rule: removing the last role is blocked where policy requires one | TC-SA-02-02-015 |
| 2.2 Reassign or Remove Roles | Rule: every change audit-logged with before/after sets | TC-SA-02-02-017 |
| 2.2 Reassign or Remove Roles | Rule: removal does not deactivate the account | TC-SA-02-02-020 |
| 2.2 Reassign or Remove Roles | Rule: changes take effect without re-login | TC-SA-02-02-016 |
| 2.3 Track Role Holders | Role → Users view with account status and last-activity | TC-SA-02-02-021 |
| 2.3 Track Role Holders | User → Roles view with each role's permission summary | TC-SA-02-02-022 |
| 2.3 Track Role Holders | Filters: by role, user type, account status, institute | TC-SA-02-02-023 |
| 2.3 Track Role Holders | Search by user name/email or role name | TC-SA-02-02-024 |
| 2.3 Track Role Holders | Export of the role-holder mapping | TC-SA-02-02-025 |
| 2.3 Track Role Holders | Highlight of anomalies: no roles, many roles, archived-role holders | TC-SA-02-02-026 |
| 2.3 Track Role Holders | Rule: mapping reflects current state; history via audit trail | TC-SA-02-02-027 |
| 2.3 Track Role Holders | Rule: holders of archived roles are highlighted | TC-SA-02-02-026 |
| 2.3 Track Role Holders | Rule: users with no roles are highlighted (deny-by-default) | TC-SA-02-02-026 |
| 2.3 Track Role Holders | Rule: exports access-controlled and audit-logged | TC-SA-02-02-025 |
| 2.3 Track Role Holders | Rule: view is read-only | TC-SA-02-02-028 |
| 2.3 Track Role Holders | Rule: holder view shows membership, not per-user data scope | TC-SA-02-02-029 |
| 2.4 Multiple Roles per User | Union of permissions across held roles | TC-SA-02-02-030 |
| 2.4 Multiple Roles per User | Data scoping: policy-defined resolution (default union) | TC-SA-02-02-031 |
| 2.4 Multiple Roles per User | Role-set view per user showing each role and its contribution | TC-SA-02-02-032 |
| 2.4 Multiple Roles per User | Conflict handling: overlapping differently-scoped access | TC-SA-02-02-033 |
| 2.4 Multiple Roles per User | Right-sizing guidance: highlight broader-than-typical role sets | TC-SA-02-02-034 |
| 2.4 Multiple Roles per User | Audit logging of role-set changes | TC-SA-02-02-035 |
| 2.4 Multiple Roles per User | Rule: removing a role removes only permissions not granted by another role | TC-SA-02-02-036 |
| 2.4 Multiple Roles per User | Rule: default scope resolution is the union of visible records | TC-SA-02-02-031 |
| 2.4 Multiple Roles per User | Rule: over-privileging surfaced via highlights, not silently enforced | TC-SA-02-02-034 |
| 2.4 Multiple Roles per User | Rule: separation-of-duties conflicts across combined roles are flagged | TC-SA-02-02-037 |
| 2.4 Multiple Roles per User | Rule: role-set view makes the union transparent | TC-SA-02-02-032 |
| 2.4 Multiple Roles per User | Rule: all role-set changes audit-logged | TC-SA-02-02-035 |

## 2.1 Assign Roles to User Accounts

### TC-SA-02-02-001 — Assign a single role from the user record
**Type:** Positive
**Covers:** 2.1 → Assign one or more roles to a user from the user record
**Preconditions:** A new teacher's user account exists; the Teacher/Content Creator role is active.
**Steps:**
1. Open the user's record in the user directory and select "Assign role".
2. Select Teacher/Content Creator from the picker and confirm.
3. Log in as the user and inspect their navigation.
**Expected Result:** The role is bound to the user; the user's effective access now includes the role's permissions (course creation, content upload, own analytics).
**Priority:** Critical

### TC-SA-02-02-002 — Assign a role from the role's holder view
**Type:** Positive
**Covers:** 2.1 → Assign one or more roles to a user from the role's holder view
**Preconditions:** Super Admin logged in; the Content Reviewer role's holder view is open.
**Steps:**
1. From the role's holder view, select "Add holder" and choose an existing user.
2. Confirm the assignment.
3. Open the user's record and verify the role appears in their role set.
**Expected Result:** The assignment succeeds from the holder view; the user's role set includes Content Reviewer.
**Priority:** High

### TC-SA-02-02-003 — Bulk assignment of a role to a group of users
**Type:** Positive
**Covers:** 2.1 → Bulk assignment: apply a role to a selected group of users
**Preconditions:** 15 new staff accounts exist at a new institute (10 teachers, 4 reviewers, 1 billing).
**Steps:**
1. Select the 15 users in the user directory and choose "Assign role".
2. Pick the appropriate role for each group and confirm the bulk preview: "15 users — 10 teachers, 4 reviewers, 1 billing."
3. Confirm the bulk assignment.
4. Spot-check one user from each group.
**Expected Result:** All 15 users receive their group's role; each spot-checked user has exactly the intended access.
**Priority:** Critical

### TC-SA-02-02-004 — The role picker shows only active roles
**Type:** Positive
**Covers:** 2.1 → Active-role-only picker; Rule: archived roles excluded from the picker
**Preconditions:** At least one active role and one archived role exist.
**Steps:**
1. Open the role picker from a user record.
2. Check the list for the archived role.
3. Attempt to assign the archived role via any path.
**Expected Result:** Only active roles appear in the picker; the archived role is absent and cannot be assigned.
**Priority:** High

### TC-SA-02-02-005 — Assignment takes effect on the next request without re-login
**Type:** Positive
**Covers:** 2.1 → Immediate effect: the user's access updates on their next request; Rule: no re-login required
**Preconditions:** A user with an active session has no roles; a role is about to be assigned.
**Steps:**
1. Assign the role to the user while their session is active.
2. The user makes their next request (refreshes a page) without re-logging in.
**Expected Result:** The new access is effective on the next request in the existing session — no re-login is required.
**Priority:** Critical

### TC-SA-02-02-006 — Optional notification to the user on role assignment
**Type:** Positive
**Covers:** 2.1 → Optional notification to the user on role assignment (per policy)
**Preconditions:** The notification policy for role assignment is enabled.
**Steps:**
1. Assign a role to a user.
2. Check the user's notification channel.
3. Disable the policy and assign a role to a second user; check again.
**Expected Result:** With the policy enabled, the user is notified of the assignment; with it disabled, no notification is sent — behavior follows the policy.
**Priority:** Medium

### TC-SA-02-02-007 — Every assignment is audit-logged with actor, user, role, timestamp
**Type:** Positive
**Covers:** 2.1 → Audit logging of every assignment with actor, user, role, and timestamp
**Preconditions:** An individual role assignment has just been made.
**Steps:**
1. Open the Permission Audit Trail and filter by action "role assign".
2. Inspect the entry for the assignment.
**Expected Result:** The entry records the actor (Super Admin), the target user, the role, and the timestamp.
**Priority:** Critical

### TC-SA-02-02-008 — A user can hold multiple roles with unioned access
**Type:** Positive
**Covers:** 2.1 → Rule: a user can hold multiple roles; effective access is the union
**Preconditions:** A user holds Teacher/Content Creator; the Content Reviewer role is active.
**Steps:**
1. Assign Content Reviewer to the same user.
2. Log in as the user and exercise both a teacher capability (create content) and a reviewer capability (approve content).
**Expected Result:** The user holds both roles; both capabilities work — effective access is the union of the two roles' permissions.
**Priority:** High

### TC-SA-02-02-009 — Bulk assignment requires a confirmed preview
**Type:** Positive
**Covers:** 2.1 → Rule: bulk assignments require a confirmed preview of the affected users and roles
**Preconditions:** 15 users are selected for bulk role assignment.
**Steps:**
1. Initiate the bulk assignment.
2. Review the preview before confirming.
3. Cancel the preview and verify nothing was applied.
**Expected Result:** The preview lists the affected users and roles and requires explicit confirmation; cancelling applies no changes.
**Priority:** High

### TC-SA-02-02-010 — Bulk assignments are logged as a batch with the member list
**Type:** Positive
**Covers:** 2.1 → Rule: bulk assignments are logged as a batch with the member list
**Preconditions:** A bulk assignment of 15 users has been completed.
**Steps:**
1. Open the Permission Audit Trail and filter by the bulk assignment.
**Expected Result:** The bulk assignment appears as a single batch entry containing the full member list (all 15 users), the roles, the actor, and the timestamp.
**Priority:** High

### TC-SA-02-02-011 — Assigning a role does not create the user account
**Type:** Negative
**Covers:** 2.1 → Rule: the user must already exist; assignment does not create the account
**Preconditions:** A user account for "new.person@example.com" does not exist.
**Steps:**
1. Attempt to assign a role to "new.person@example.com" from the role-assignment flow.
**Expected Result:** The assignment is impossible — the user must already exist; no account is created as a side effect.
**Priority:** Medium

## 2.2 Reassign or Remove Roles

### TC-SA-02-02-012 — Remove a single role from a user
**Type:** Positive
**Covers:** 2.2 → Remove a single role from a user (revokes that role's permissions)
**Preconditions:** A user holds Content Reviewer and one other role.
**Steps:**
1. Open the user's record and remove the Content Reviewer role.
2. Confirm.
3. Log in as the user and attempt a reviewer-only action.
**Expected Result:** The role is removed; the reviewer permissions are revoked on the user's next request; the other role's permissions remain.
**Priority:** Critical

### TC-SA-02-02-013 — Reassign: replace one role with another in a single action
**Type:** Positive
**Covers:** 2.2 → Reassign: replace one role with another in a single action (old removed, new added)
**Preconditions:** A user holds Content Reviewer; a custom "Content Lead" role exists.
**Steps:**
1. Select "Reassign" on the user's record and choose "Content Lead" to replace Content Reviewer.
2. Review the before/after and confirm.
3. Log in as the user and verify the new access.
**Expected Result:** Content Reviewer is removed and Content Lead is added in one action; the user's navigation reflects the lead's permissions (review plus scheduling).
**Priority:** Critical

### TC-SA-02-02-014 — Review the user's full role set before and after the change
**Type:** Positive
**Covers:** 2.2 → Review the user's full role set before and after the change
**Preconditions:** A role change is staged for a user holding 2 roles.
**Steps:**
1. Stage the reassignment.
2. Review the before/after role-set display.
**Expected Result:** The UI shows the complete role set before the change and the complete set after, so the change is deliberate.
**Priority:** Medium

### TC-SA-02-02-015 — Removing the last role is blocked where policy requires at least one
**Type:** Negative
**Covers:** 2.2 → Guardrail: a user cannot be left with no roles if the account requires at least one; Rule: removing the last role is blocked with a prompt to reassign
**Preconditions:** Policy requires every active user to hold at least one role; a user holds exactly one role.
**Steps:**
1. Attempt to remove the user's only role.
**Expected Result:** The removal is blocked with a prompt to reassign instead; the user is not left with zero roles.
**Priority:** High

### TC-SA-02-02-016 — Role changes take effect on the next request without re-login
**Type:** Positive
**Covers:** 2.2 → Immediate effect on the next request; Rule: changes take effect without re-login
**Preconditions:** A user with an active session is about to have a role removed.
**Steps:**
1. Remove the role while the user's session is active.
2. The user makes their next request without re-logging in.
**Expected Result:** The revoked permissions are denied on the next request in the existing session — no re-login is required.
**Priority:** Critical

### TC-SA-02-02-017 — Every removal/reassignment is audit-logged with before/after role sets
**Type:** Positive
**Covers:** 2.2 → Audit logging of every removal/reassignment with before/after role sets; Rule: every change audit-logged
**Preconditions:** A removal and a reassignment have been performed.
**Steps:**
1. Open the Permission Audit Trail and filter by the target user.
2. Inspect both entries.
**Expected Result:** Each entry records the actor, the reason, the timestamp, and the complete before/after role sets.
**Priority:** Critical

### TC-SA-02-02-018 — In-progress actions complete after role removal; new actions denied
**Type:** Edge
**Covers:** 2.2 → Rule: role removal revokes on the next request; in-progress actions complete but new actions are denied
**Preconditions:** A user is mid-flow on an action covered by a role about to be removed.
**Steps:**
1. Remove the role while the user is on the in-progress screen.
2. The user completes the current action.
3. The user attempts to initiate a new action requiring the removed role.
**Expected Result:** The in-progress action completes; the new action is denied.
**Priority:** High

### TC-SA-02-02-019 — Reassignment is atomic
**Type:** Edge
**Covers:** 2.2 → Rule: reassignment is atomic — old removed and new added in one audited action
**Preconditions:** A reassignment is about to be performed.
**Steps:**
1. Perform the reassignment (Content Reviewer → Content Lead).
2. Inspect the user's role set immediately after.
3. Inspect the audit trail for the operation.
**Expected Result:** There is no intermediate state where the user holds neither or both roles; the audit trail shows a single atomic action.
**Priority:** High

### TC-SA-02-02-020 — Removing a role does not deactivate the user account
**Type:** Edge
**Covers:** 2.2 → Rule: removing a role does not deactivate the user account
**Preconditions:** A user holds one role; the account is active.
**Steps:**
1. Remove the role (where policy allows zero roles).
2. Check the account status.
3. Log in as the user.
**Expected Result:** The account remains active and the user can log in; only the role-based access is removed — account status is a separate control.
**Priority:** Medium

## 2.3 Track Role Holders

### TC-SA-02-02-021 — Role → Users view shows holders with status and last-activity
**Type:** Positive
**Covers:** 2.3 → Role → Users view: all holders of a role with their account status and last-activity
**Preconditions:** The Billing Administrator role has known holders with known activity.
**Steps:**
1. Open Role & Permission Management → Role Holders.
2. Open the role → users view for Billing Administrator.
**Expected Result:** Every holder is listed with their account status and last-activity; the holder count matches the actual assignments.
**Priority:** High

### TC-SA-02-02-022 — User → Roles view shows all roles with permission summaries
**Type:** Positive
**Covers:** 2.3 → User → Roles view: all roles held by a user with each role's permission summary
**Preconditions:** A user holds 2 roles.
**Steps:**
1. Open the user → roles view for the user.
**Expected Result:** Both roles are listed, each with its permission summary.
**Priority:** High

### TC-SA-02-02-023 — Filters: by role, user type, account status, institute
**Type:** Positive
**Covers:** 2.3 → Filters: by role, by user type, by account status, by institute
**Preconditions:** Holders exist across multiple roles, user types, statuses, and institutes.
**Steps:**
1. Apply each filter individually: by role, by user type, by account status, by institute.
2. Apply combined filters.
**Expected Result:** Each filter narrows the holder list correctly; combined filters intersect as expected.
**Priority:** Medium

### TC-SA-02-02-024 — Search by user name/email or role name
**Type:** Positive
**Covers:** 2.3 → Search by user name/email or role name
**Preconditions:** Known users and roles exist.
**Steps:**
1. Search by a user's name, then by their email.
2. Search by a role name.
**Expected Result:** Each search returns the matching holders/roles accurately.
**Priority:** Medium

### TC-SA-02-02-025 — Export of the role-holder mapping is access-controlled and audit-logged
**Type:** Positive
**Covers:** 2.3 → Export of the role-holder mapping for access reviews; Rule: exports access-controlled and audit-logged
**Preconditions:** Super Admin logged in; the role-holder view is open.
**Steps:**
1. Export the role-holder mapping.
2. Verify the exported content.
3. Check the audit trail for the export action.
**Expected Result:** The export contains the current mapping; the export action is access-controlled and audit-logged.
**Priority:** High

### TC-SA-02-02-026 — Anomaly highlights: no roles, many roles, archived-role holders
**Type:** Positive
**Covers:** 2.3 → Highlight of anomalies; Rule: holders of archived roles highlighted; Rule: users with no roles highlighted
**Preconditions:** The system contains: 2 users with no roles, 1 user with 4 roles, 1 holder of an archived role.
**Steps:**
1. Open the Role Holders view and the anomaly list.
**Expected Result:** All three anomaly categories are highlighted: the 2 unassigned users (deny-by-default), the 4-role user (possible over-privileging), and the archived-role holder (needs reassignment).
**Priority:** High

### TC-SA-02-02-027 — The mapping reflects current state; history is in the audit trail
**Type:** Edge
**Covers:** 2.3 → Rule: the mapping reflects current state; historical holder data is available through the audit trail
**Preconditions:** A user's role was removed yesterday.
**Steps:**
1. Check the current role-holder mapping for the user.
2. Query the audit trail for the user's role history.
**Expected Result:** The current mapping shows only present roles; the historical assignment is recoverable from the audit trail.
**Priority:** Medium

### TC-SA-02-02-028 — The holder view is read-only
**Type:** Negative
**Covers:** 2.3 → Rule: the view is read-only; changes go through the assignment/reassignment flows
**Preconditions:** The Role Holders view is open.
**Steps:**
1. Attempt to edit, add, or remove a holder directly from the view.
**Expected Result:** No edit controls exist; changes are only possible through the assignment/reassignment flows.
**Priority:** Medium

### TC-SA-02-02-029 — The holder view shows membership, not per-user data scope
**Type:** Edge
**Covers:** 2.3 → Rule: the holder view shows role membership, not per-user data scope
**Preconditions:** Two teachers hold the same role with different course assignments.
**Steps:**
1. Open the role → users view for the teacher role.
2. Compare the two teachers' entries.
**Expected Result:** Both appear as holders of the role; the view does not display their individual data scopes (which differ per user).
**Priority:** Medium

## 2.4 Multiple Roles per User

### TC-SA-02-02-030 — Effective access is the union of held roles' permissions
**Type:** Positive
**Covers:** 2.4 → Union of permissions across held roles
**Preconditions:** A user holds Teacher/Content Creator and Content Reviewer.
**Steps:**
1. Log in as the user.
2. Exercise a teacher-only capability (create content) and a reviewer-only capability (approve content).
**Expected Result:** Both capabilities work — a permission granted by any held role is available.
**Priority:** Critical

### TC-SA-02-02-031 — Multi-role data scoping resolves per policy (default union)
**Type:** Positive
**Covers:** 2.4 → Data scoping: policy-defined resolution (default union of visible records); Rule: default is the union
**Preconditions:** A user holds two roles that scope records differently.
**Steps:**
1. Log in as the user and open a scoped list (e.g., courses).
2. Compare the visible records with the union of both roles' scopes.
**Expected Result:** The visible record set matches the policy-defined resolution — by default, the union of the records visible under each role.
**Priority:** High

### TC-SA-02-02-032 — Role-set view shows each role and its contribution
**Type:** Positive
**Covers:** 2.4 → Role-set view per user showing each role and its contribution; Rule: the view makes the union transparent
**Preconditions:** A user holds 2 roles.
**Steps:**
1. Open the user's role-set view.
**Expected Result:** Both roles are listed with each role's permission summary and the resulting union, so access questions can be answered from the UI.
**Priority:** Medium

### TC-SA-02-02-033 — Overlapping differently-scoped access resolves per policy
**Type:** Edge
**Covers:** 2.4 → Conflict handling: where roles grant overlapping but differently-scoped access, the policy-defined resolution applies
**Preconditions:** A user holds two roles that both grant access to the same data category with different scopes.
**Steps:**
1. Log in as the user and open the affected list.
2. Compare the result with the documented policy resolution.
**Expected Result:** The effective scope matches the policy-defined resolution exactly — consistent and documented, not arbitrary.
**Priority:** High

### TC-SA-02-02-034 — Right-sizing guidance highlights broader-than-typical role sets
**Type:** Positive
**Covers:** 2.4 → Right-sizing guidance: highlight users whose role set is broader than typical; Rule: surfaced via highlights, not silently enforced
**Preconditions:** A user holds 2 roles while their function typically requires 1.
**Steps:**
1. Open the right-sizing highlights during an access review.
**Expected Result:** The user is highlighted as broader-than-typical; no access is silently changed — the highlight prompts a deliberate review.
**Priority:** Medium

### TC-SA-02-02-035 — Role-set changes are audit-logged
**Type:** Positive
**Covers:** 2.4 → Audit logging of role-set changes; Rule: all role-set changes audit-logged
**Preconditions:** A second role has been added to a user.
**Steps:**
1. Open the Permission Audit Trail and filter by the user.
**Expected Result:** The role-set change is audit-logged with the before/after sets, actor, and timestamp.
**Priority:** High

### TC-SA-02-02-036 — Removing one role removes only permissions not granted by another role
**Type:** Edge
**Covers:** 2.4 → Rule: removing a role removes only the permissions not also granted by another held role
**Preconditions:** A user holds two roles that share a permission P plus unique permissions A and B.
**Steps:**
1. Remove the role that grants A and P.
2. Log in as the user and test capabilities A, B, and P.
**Expected Result:** Capability A is lost; capabilities B and P remain — P is still granted by the other held role.
**Priority:** High

### TC-SA-02-02-037 — Separation-of-duties conflicts across combined roles are flagged
**Type:** Edge
**Covers:** 2.4 → Rule: separation-of-duties conflicts across a user's combined roles are flagged for review
**Preconditions:** A user's combined roles grant both discount creation and refund approval.
**Steps:**
1. Open the separation-of-duties monitoring view.
2. Locate the user's combined-role conflict.
**Expected Result:** A warning flag is raised for the user's combined roles (sensitive action + its approval); the flag routes to review, not automatic blocking.
**Priority:** High