# 5. Permission Auditing — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: permission_auditing.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 |
|---------|--------------------|----------|
| 5.1 View Permission Assignments per User | Per-user access summary: roles held, each role's permissions, effective union | TC-SA-02-05-001 |
| 5.1 View Permission Assignments per User | Breakdown by module | TC-SA-02-05-002 |
| 5.1 View Permission Assignments per User | Data-scope summary per category | TC-SA-02-05-003 |
| 5.1 View Permission Assignments per User | Comparison view vs. a reference role | TC-SA-02-05-004 |
| 5.1 View Permission Assignments per User | Read-only view | TC-SA-02-05-005 |
| 5.1 View Permission Assignments per User | Export of a user's access summary | TC-SA-02-05-006 |
| 5.1 View Permission Assignments per User | Rule: summary reflects current effective access; history via audit trail | TC-SA-02-05-007 |
| 5.1 View Permission Assignments per User | Rule: data-scope summaries show scope definitions, not full record lists | TC-SA-02-05-008 |
| 5.1 View Permission Assignments per User | Rule: comparison view surfaces drift | TC-SA-02-05-004 |
| 5.1 View Permission Assignments per User | Rule: the view does not grant or change access | TC-SA-02-05-005 |
| 5.1 View Permission Assignments per User | Rule: exports access-controlled and audit-logged | TC-SA-02-05-006 |
| 5.1 View Permission Assignments per User | Rule: summary consistent with what the user actually experiences | TC-SA-02-05-009 |
| 5.2 Audit Trail of Role and Permission Changes | Event coverage: create/edit/delete/archive, permission add/remove, assign/reassign/remove, scope changes | TC-SA-02-05-010 |
| 5.2 Audit Trail of Role and Permission Changes | Each event: actor, action, target, before/after, timestamp, IP, device | TC-SA-02-05-011 |
| 5.2 Audit Trail of Role and Permission Changes | Tamper-evidence: immutable and integrity-checked | TC-SA-02-05-012 |
| 5.2 Audit Trail of Role and Permission Changes | Search and filter: by actor, action type, target role, target user, time range | TC-SA-02-05-013 |
| 5.2 Audit Trail of Role and Permission Changes | Point-in-time reconstruction | TC-SA-02-05-014 |
| 5.2 Audit Trail of Role and Permission Changes | Retention per compliance requirements | TC-SA-02-05-015 |
| 5.2 Audit Trail of Role and Permission Changes | Export for external audits | TC-SA-02-05-016 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: immutable; alteration attempts logged and alerted | TC-SA-02-05-012 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: before/after captured for every change | TC-SA-02-05-011 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: point-in-time reconstruction for both roles and users | TC-SA-02-05-014 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: retention follows the strictest applicable regulation | TC-SA-02-05-015 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: exports are read-only copies; source remains authoritative | TC-SA-02-05-016 |
| 5.2 Audit Trail of Role and Permission Changes | Rule: covers all role/permission changes across all modules | TC-SA-02-05-017 |
| 5.3 Access Review Support | Review workspace: mappings, summaries, anomalies in one place | TC-SA-02-05-018 |
| 5.3 Access Review Support | Anomaly detection: no roles, over-privileged, stale holders, archived-role holders | TC-SA-02-05-019 |
| 5.3 Access Review Support | Review record: date, scope, reviewer, findings, outcomes | TC-SA-02-05-020 |
| 5.3 Access Review Support | Remediation tracking: owners, due dates, tracked to closure | TC-SA-02-05-021 |
| 5.3 Access Review Support | Export of review evidence | TC-SA-02-05-022 |
| 5.3 Access Review Support | Cadence reminders for recurring reviews | TC-SA-02-05-023 |
| 5.3 Access Review Support | Rule: reviews are recorded, not just performed | TC-SA-02-05-020 |
| 5.3 Access Review Support | Rule: anomaly highlights do not replace the full mapping | TC-SA-02-05-024 |
| 5.3 Access Review Support | Rule: remediation items tracked until closed with evidence | TC-SA-02-05-021 |
| 5.3 Access Review Support | Rule: evidence exports access-controlled and audit-logged | TC-SA-02-05-022 |
| 5.3 Access Review Support | Rule: cadence reminders; cadence configurable | TC-SA-02-05-023 |
| 5.3 Access Review Support | Rule: changes during a review individually audit-logged and linked to the review record | TC-SA-02-05-025 |
| 5.4 Separation of Duties Monitoring | Conflict rule definitions: pairs/sets that should not be combined | TC-SA-02-05-026 |
| 5.4 Separation of Duties Monitoring | Role-level detection | TC-SA-02-05-027 |
| 5.4 Separation of Duties Monitoring | User-level detection (combined roles) | TC-SA-02-05-028 |
| 5.4 Separation of Duties Monitoring | Flag (not block) | TC-SA-02-05-029 |
| 5.4 Separation of Duties Monitoring | Review workflow: acknowledge, decide, record | TC-SA-02-05-030 |
| 5.4 Separation of Duties Monitoring | Audit logging of conflict flags and decisions | TC-SA-02-05-031 |
| 5.4 Separation of Duties Monitoring | Rule: conflicts flagged, not blocked — deliberate documented decision | TC-SA-02-05-029 |
| 5.4 Separation of Duties Monitoring | Rule: detection at both role and user level | TC-SA-02-05-027, TC-SA-02-05-028 |
| 5.4 Separation of Duties Monitoring | Rule: accepted conflicts require justification and review-by date | TC-SA-02-05-032 |
| 5.4 Separation of Duties Monitoring | Rule: conflict rules defined by the platform's SoD model and visible | TC-SA-02-05-026 |
| 5.4 Separation of Duties Monitoring | Rule: every flag, decision, and remediation audit-logged | TC-SA-02-05-031 |
| 5.4 Separation of Duties Monitoring | Rule: monitoring is continuous, not only at review time | TC-SA-02-05-033 |

## 5.1 View Permission Assignments per User

### TC-SA-02-05-001 — Per-user access summary shows roles, permissions, and the effective union
**Type:** Positive
**Covers:** 5.1 → Per-user access summary: roles held, each role's permissions, and the effective union
**Preconditions:** A new teacher holds Teacher/Content Creator; onboarding is complete.
**Steps:**
1. Open the user's record and view the permission-assignment summary.
2. Verify the roles held, each role's permissions, and the effective union.
**Expected Result:** The summary shows role Teacher/Content Creator, its permissions (course creation, content upload, own analytics), and the resulting effective access.
**Priority:** Critical

### TC-SA-02-05-002 — Breakdown by module of the user's effective access
**Type:** Positive
**Covers:** 5.1 → Breakdown by module: which features, actions, and scopes the user effectively has
**Preconditions:** A user holds 2 roles spanning multiple modules.
**Steps:**
1. Open the user's access summary.
2. Expand the per-module breakdown.
**Expected Result:** Each module lists the features, actions, and data scopes the user effectively has — no module is missing or misattributed.
**Priority:** High

### TC-SA-02-05-003 — Data-scope summary shows the record sets per category
**Type:** Positive
**Covers:** 5.1 → Data-scope summary: the record sets the user can see per category
**Preconditions:** A user's roles define scopes for courses, students, and tickets.
**Steps:**
1. Open the user's access summary.
2. Review the data-scope summary section.
**Expected Result:** The summary lists the scope per category (e.g., own courses, own students, queue tickets) matching the roles' scope definitions.
**Priority:** High

### TC-SA-02-05-004 — Comparison view surfaces drift against a reference role
**Type:** Positive
**Covers:** 5.1 → Comparison view: the user's effective access vs. a reference role; Rule: surfaces drift (extra or missing permissions)
**Preconditions:** A user holds Teacher/Content Creator plus a second role that adds "export reports".
**Steps:**
1. Open the comparison view with the reference role Teacher/Content Creator.
2. Review the drift report.
**Expected Result:** The view flags the extra "export reports" permission (drift) and any missing permissions, enabling right-sizing.
**Priority:** High

### TC-SA-02-05-005 — The access summary view is read-only
**Type:** Negative
**Covers:** 5.1 → Read-only view; Rule: it does not grant or change access
**Preconditions:** The user's access summary is open.
**Steps:**
1. Attempt to add, remove, or edit a permission directly from the summary.
**Expected Result:** No edit controls exist; the view is read-only — changes go through the assignment/role-edit flows.
**Priority:** Medium

### TC-SA-02-05-006 — Export of a user's access summary is access-controlled and audit-logged
**Type:** Positive
**Covers:** 5.1 → Export of a user's access summary for reviews; Rule: exports access-controlled and audit-logged
**Preconditions:** Super Admin logged in; a user's access summary is open.
**Steps:**
1. Export the user's access summary.
2. Verify the exported content.
3. Check the audit trail for the export action.
**Expected Result:** The export contains the full summary; the export action is access-controlled and audit-logged.
**Priority:** Medium

### TC-SA-02-05-007 — The summary reflects current effective access; history is in the audit trail
**Type:** Edge
**Covers:** 5.1 → Rule: the summary reflects current effective access; historical access is available through the audit trail
**Preconditions:** A user's role was changed yesterday.
**Steps:**
1. Open the user's access summary today.
2. Query the audit trail for the user's access as of yesterday.
**Expected Result:** The summary shows only the current effective access; the prior state is recoverable from the audit trail.
**Priority:** Medium

### TC-SA-02-05-008 — Data-scope summaries show scope definitions, not full record lists
**Type:** Edge
**Covers:** 5.1 → Rule: data-scope summaries show the scope definitions, not the full record lists
**Preconditions:** A user's scope covers many records.
**Steps:**
1. Open the user's data-scope summary.
2. Check whether individual records are listed.
**Expected Result:** The summary shows the scope definitions (e.g., "own courses"), not an enumeration of every record.
**Priority:** Medium

### TC-SA-02-05-009 — The summary is consistent with what the user actually experiences
**Type:** Positive
**Covers:** 5.1 → Rule: the summary is consistent with what the user actually experiences (same permission model)
**Preconditions:** A user's access summary is available.
**Steps:**
1. Record the summary's effective features, actions, and scopes.
2. Log in as the user and exercise each listed capability and attempt one unlisted capability.
**Expected Result:** Every listed capability works and the unlisted one is denied — the summary matches the live permission model exactly.
**Priority:** Critical

## 5.2 Audit Trail of Role and Permission Changes

### TC-SA-02-05-010 — Event coverage spans all role and permission change types
**Type:** Positive
**Covers:** 5.2 → Event coverage: role create/edit/delete/archive, permission add/remove, role assign/reassign/remove, scope changes
**Preconditions:** Each change type has been performed at least once.
**Steps:**
1. Open the Permission Audit Trail.
2. Verify an entry exists for each: role create, role edit, role delete, role archive, permission add, permission remove, role assign, role reassign, role remove, scope change.
**Expected Result:** Every change type produced an audit entry — coverage is complete.
**Priority:** Critical

### TC-SA-02-05-011 — Each event records actor, action, target, before/after, timestamp, IP, device
**Type:** Positive
**Covers:** 5.2 → Each event: actor, action, target, before/after state, timestamp, IP, device; Rule: before/after captured for every change
**Preconditions:** A role edit (permission removal) has been performed.
**Steps:**
1. Open the audit entry for the edit.
2. Verify each field.
**Expected Result:** The entry contains the actor, the action ("removed: process refunds"), the target role, the complete before/after permission set, the timestamp, IP, and device.
**Priority:** Critical

### TC-SA-02-05-012 — The trail is immutable; alteration attempts are logged and alerted
**Type:** Negative
**Covers:** 5.2 → Tamper-evidence: entries are immutable and integrity-checked; Rule: no role can edit or delete entries; alteration attempts logged and alerted
**Preconditions:** Audit entries exist; Super Admin logged in.
**Steps:**
1. Attempt to edit an audit entry's fields.
2. Attempt to delete an audit entry.
3. Attempt a direct modification via any available path.
4. Check for the alert and the logged alteration attempt.
**Expected Result:** All modification attempts fail — entries are immutable; each attempt is itself logged and raises an alert.
**Priority:** Critical

### TC-SA-02-05-013 — Search and filter by actor, action type, target role, target user, time range
**Type:** Positive
**Covers:** 5.2 → Search and filter: by actor, action type, target role, target user, and time range
**Preconditions:** Audit entries exist across actors, actions, targets, and dates.
**Steps:**
1. Filter by target role "Billing Administrator" and the date range from 1 March to now.
2. Apply each other filter individually: actor, action type, target user, time range.
**Expected Result:** Each filter returns exactly the matching entries; combined filters intersect correctly.
**Priority:** High

### TC-SA-02-05-014 — Point-in-time reconstruction of a role's and a user's state
**Type:** Positive
**Covers:** 5.2 → Point-in-time reconstruction: what a role's permissions were, or what a user's roles were, at a given date; Rule: answers "what was the state at date D" for both roles and users
**Preconditions:** The Billing Administrator role's permissions changed after 1 March; a user's roles changed after 15 June.
**Steps:**
1. Use the point-in-time view to reconstruct the Billing Administrator role's permission set exactly as of 1 March.
2. Reconstruct the user's role set as of 15 June.
**Expected Result:** Both reconstructions match the true historical state exactly — not just detection, but exact reconstruction.
**Priority:** Critical

### TC-SA-02-05-015 — Retention follows the strictest applicable regulation
**Type:** Positive
**Covers:** 5.2 → Retention per compliance requirements; Rule: retention follows the strictest applicable regulation
**Preconditions:** Multiple regulations with different retention periods apply.
**Steps:**
1. Check the configured retention for the audit trail.
2. Verify entries older than the shortest (but not the strictest) period are still retained.
**Expected Result:** Retention matches the strictest applicable regulation — entries survive beyond the shortest period.
**Priority:** High

### TC-SA-02-05-016 — Export for external audits produces read-only copies
**Type:** Positive
**Covers:** 5.2 → Export for external audits; Rule: exports are read-only copies; the source trail remains authoritative
**Preconditions:** A filtered trail and a point-in-time snapshot are ready for an auditor.
**Steps:**
1. Export the filtered trail and the point-in-time snapshot in the auditor's required format.
2. Verify the exports.
3. Verify the source trail is unchanged.
**Expected Result:** The exports are complete read-only copies; the source trail remains authoritative and unmodified.
**Priority:** High

### TC-SA-02-05-017 — The trail covers role/permission changes across all modules
**Type:** Positive
**Covers:** 5.2 → Rule: the trail covers all role/permission changes across all modules, not only this one
**Preconditions:** Role/permission changes have occurred in other modules' contexts (e.g., a scope change affecting billing data).
**Steps:**
1. Open the Permission Audit Trail without module filters.
2. Locate the changes originating from other modules.
**Expected Result:** Changes from all modules appear in the single trail — coverage is platform-wide.
**Priority:** Medium

## 5.3 Access Review Support

### TC-SA-02-05-018 — Review workspace consolidates mappings, summaries, and anomalies
**Type:** Positive
**Covers:** 5.3 → Review workspace: role-holder mappings, per-user access summaries, and anomaly highlights in one place
**Preconditions:** The quarterly access review is due.
**Steps:**
1. Open the Access Review workspace.
2. Verify the role-holder mappings, per-user access summaries, and anomaly highlights are all present.
**Expected Result:** All three views are available in one place — no context switching is needed to run the review.
**Priority:** High

### TC-SA-02-05-019 — Anomaly detection covers all four anomaly types
**Type:** Positive
**Covers:** 5.3 → Anomaly detection: users with no roles, over-privileged users, stale holders, holders of archived roles
**Preconditions:** The system contains: 2 users with no roles, 1 over-privileged user, 1 stale Billing Administrator (60 days inactive), 1 holder of an archived role.
**Steps:**
1. Open the anomaly list in the review workspace.
**Expected Result:** All four anomalies are detected and listed: the 2 unassigned users, the over-privileged user, the stale holder, and the archived-role holder.
**Priority:** High

### TC-SA-02-05-020 — Each review cycle produces a dated record with scope, reviewer, findings, outcomes
**Type:** Positive
**Covers:** 5.3 → Review record: date, scope, reviewer, findings, and outcomes per review cycle; Rule: reviews are recorded, not just performed
**Preconditions:** A review cycle has been completed with changes made.
**Steps:**
1. Open the review record for the cycle.
2. Verify each field: date, scope (all sub-admin roles), reviewer (Super Admin), findings (the anomalies), outcomes (the changes made).
**Expected Result:** The record is complete and dated — the review is evidenced, not just performed.
**Priority:** Critical

### TC-SA-02-05-021 — Remediation items are tracked to closure with evidence
**Type:** Positive
**Covers:** 5.3 → Remediation tracking: findings assigned to owners with due dates, tracked to closure; Rule: items remain tracked until explicitly closed with evidence
**Preconditions:** A review produced an open finding: "confirm institute X's staff roles by [date]".
**Steps:**
1. Assign the finding to an owner with a due date.
2. Attempt to close it without evidence.
3. Provide evidence and close it.
**Expected Result:** The item stays open until explicitly closed with evidence; closure records the evidence; the compliance dashboard reflects the state.
**Priority:** High

### TC-SA-02-05-022 — Review evidence export is access-controlled and audit-logged
**Type:** Positive
**Covers:** 5.3 → Export of review evidence (mappings, summaries, changes made); Rule: exports access-controlled and audit-logged
**Preconditions:** A review cycle is complete.
**Steps:**
1. Export the review evidence: mappings, per-user summaries reviewed, and changes made.
2. Check the audit trail for the export action.
**Expected Result:** The export contains the full evidence package; the export action is access-controlled and audit-logged.
**Priority:** Medium

### TC-SA-02-05-023 — Cadence reminders fire for recurring reviews; cadence is configurable
**Type:** Positive
**Covers:** 5.3 → Cadence reminders for recurring reviews; Rule: cadence is configurable
**Preconditions:** The quarterly review cadence is configured.
**Steps:**
1. Wait for (or simulate) the due date.
2. Verify the reminder is delivered to Super Admin.
3. Change the cadence and verify the next reminder date updates.
**Expected Result:** The reminder fires on schedule; changing the cadence updates the schedule — reviews are not missed.
**Priority:** Medium

### TC-SA-02-05-024 — Anomaly highlights do not replace the full mapping
**Type:** Edge
**Covers:** 5.3 → Rule: anomaly highlights reduce review effort but do not replace it; the full mapping is always available
**Preconditions:** The anomaly list shows 4 items.
**Steps:**
1. From the review workspace, open the full role-holder mapping.
2. Verify users not in the anomaly list are still reviewable.
**Expected Result:** The complete mapping is always available alongside the highlights — the review can cover every holder, not just anomalies.
**Priority:** Medium

### TC-SA-02-05-025 — Changes made during a review are individually audit-logged and linked to the review record
**Type:** Positive
**Covers:** 5.3 → Rule: all changes made during a review are individually audit-logged and linked to the review record
**Preconditions:** During a review, 4 changes were made (2 assignments, 1 removal, 1 right-sizing).
**Steps:**
1. Open the audit trail for each of the 4 changes.
2. Verify the link to the review record.
**Expected Result:** Each change has its own audit entry, and each entry is linked back to the review record for the cycle.
**Priority:** High

## 5.4 Separation of Duties Monitoring

### TC-SA-02-05-026 — Conflict rule definitions are visible to the Super Admin
**Type:** Positive
**Covers:** 5.4 → Conflict rule definitions: pairs/sets of permissions that should not be combined; Rule: defined by the platform's SoD model and visible
**Preconditions:** Super Admin logged in.
**Steps:**
1. Open the separation-of-duties monitoring view.
2. Review the conflict rule definitions (e.g., create + approve, configure + execute).
**Expected Result:** The conflict rules are visible and match the platform's separation-of-duties model.
**Priority:** High

### TC-SA-02-05-027 — Role-level detection: a single role granting a conflicting combination
**Type:** Positive
**Covers:** 5.4 → Role-level detection: a single role that grants a conflicting combination; Rule: detection at the role level
**Preconditions:** Super Admin is editing the Billing Administrator role and adds "Approve refunds" (the role already has "process refunds").
**Steps:**
1. Add "Approve refunds" in the role editor.
2. Observe the editor's response.
**Expected Result:** An immediate separation-of-duties warning appears: "This role would grant both 'process refunds' and 'approve refunds'."
**Priority:** Critical

### TC-SA-02-05-028 — User-level detection: combined roles granting a conflicting combination
**Type:** Positive
**Covers:** 5.4 → User-level detection: a user whose combined roles grant a conflicting combination; Rule: detection at the user level
**Preconditions:** A user holds a role that creates discount codes and a role that approves promotions.
**Steps:**
1. Open the user-level conflict view.
2. Locate the user's combined-role conflict.
**Expected Result:** The conflict is detected at the user level — the combined roles grant both a sensitive action and its approval.
**Priority:** Critical

### TC-SA-02-05-029 — Conflicts are flagged, not blocked
**Type:** Edge
**Covers:** 5.4 → Flag (not block); Rule: conflicts raise warnings for review, not automatic prevention
**Preconditions:** A role edit would create a conflict.
**Steps:**
1. Stage the conflicting edit.
2. Attempt to save without resolving the warning.
**Expected Result:** The save is not automatically prevented — the conflict raises a warning requiring a deliberate, documented decision (remediate or accept with justification).
**Priority:** High

### TC-SA-02-05-030 — Review workflow: acknowledge, decide, record
**Type:** Positive
**Covers:** 5.4 → Review workflow: acknowledge, decide (accept with justification or remediate), record the decision
**Preconditions:** A user-level conflict flag is open.
**Steps:**
1. Acknowledge the flag.
2. Decide to remediate: remove one of the conflicting roles via the reassignment flow.
3. Record the decision.
4. Verify the flag state.
**Expected Result:** The workflow completes: acknowledged → decided (remediated) → recorded; the flag clears after remediation.
**Priority:** High

### TC-SA-02-05-031 — Every flag, decision, and remediation is audit-logged
**Type:** Positive
**Covers:** 5.4 → Audit logging of conflict flags and decisions; Rule: every flag, decision, and remediation audit-logged
**Preconditions:** A conflict was flagged, reviewed, and remediated.
**Steps:**
1. Open the audit trail and filter by the conflict.
**Expected Result:** Three entries exist: the flag, the decision, and the remediation — each with actor, timestamp, and detail.
**Priority:** Critical

### TC-SA-02-05-032 — Accepted conflicts require a justification and a review-by date
**Type:** Negative
**Covers:** 5.4 → Rule: accepted conflicts require a justification and a review-by date; they are not silently ignored
**Preconditions:** A conflict flag is open; the business decides to accept it (small team).
**Steps:**
1. Attempt to accept the conflict without a justification.
2. Attempt to accept it without a review-by date.
3. Provide both and accept.
**Expected Result:** Acceptance is blocked until both the justification and the review-by date are recorded; the accepted item then appears on the dashboard with its review-by date.
**Priority:** High

### TC-SA-02-05-033 — Monitoring is continuous: new conflicts appear as roles or assignments change
**Type:** Positive
**Covers:** 5.4 → Rule: the monitoring is continuous — new conflicts appear as roles or assignments change, not only at review time
**Preconditions:** No open conflicts exist; a role edit or assignment that creates a conflict is about to happen.
**Steps:**
1. Perform the role edit/assignment that creates the conflict.
2. Immediately check the conflict dashboard (without running a review).
**Expected Result:** The new conflict appears on the dashboard as soon as the change is made — monitoring is continuous, not batch-only.
**Priority:** High