# 3. Permission Configuration — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: permission_configuration.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 |
|---------|--------------------|----------|
| 3.1 System-Wide Permission Catalog | Catalog organized by module | TC-SA-02-03-001 |
| 3.1 System-Wide Permission Catalog | Three permission types: feature access, action, data scope | TC-SA-02-03-002 |
| 3.1 System-Wide Permission Catalog | Catalog is system-managed; new permissions appear as capabilities ship | TC-SA-02-03-003 |
| 3.1 System-Wide Permission Catalog | Catalog browser: search and filter by module, type, name | TC-SA-02-03-004 |
| 3.1 System-Wide Permission Catalog | Permission detail view: what it grants, which roles hold it | TC-SA-02-03-005 |
| 3.1 System-Wide Permission Catalog | Read-only for the Super Admin | TC-SA-02-03-006 |
| 3.1 System-Wide Permission Catalog | Rule: the catalog is the upper bound of what a role can grant | TC-SA-02-03-007 |
| 3.1 System-Wide Permission Catalog | Rule: entries added by the platform, not user-defined | TC-SA-02-03-003 |
| 3.1 System-Wide Permission Catalog | Rule: "held by" visibility supports informed granting | TC-SA-02-03-005 |
| 3.1 System-Wide Permission Catalog | Rule: data-scope permissions are distinct; feature without scope may show no records | TC-SA-02-03-008 |
| 3.1 System-Wide Permission Catalog | Rule: consistent across web and service surfaces | TC-SA-02-03-009 |
| 3.1 System-Wide Permission Catalog | Rule: catalog changes visible in the change history | TC-SA-02-03-010 |
| 3.2 Grant or Restrict Feature Access per Role | Feature-level toggles per role organized by module | TC-SA-02-03-011 |
| 3.2 Grant or Restrict Feature Access per Role | Navigation shaping: menu shows only accessible features | TC-SA-02-03-012 |
| 3.2 Grant or Restrict Feature Access per Role | Server-side enforcement: direct navigation denied with a clear message | TC-SA-02-03-013 |
| 3.2 Grant or Restrict Feature Access per Role | Change preview: affected user count before saving | TC-SA-02-03-014 |
| 3.2 Grant or Restrict Feature Access per Role | Immediate propagation to holders | TC-SA-02-03-015 |
| 3.2 Grant or Restrict Feature Access per Role | Audit logging of feature-access changes | TC-SA-02-03-016 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: enforced at the service layer, not just the UI | TC-SA-02-03-013 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: denied feature produces a clear message with optional "request access" | TC-SA-02-03-017 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: granting a feature does not grant its actions | TC-SA-02-03-018 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: previews show the affected user count | TC-SA-02-03-014 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: all feature-access changes audit-logged | TC-SA-02-03-016 |
| 3.2 Grant or Restrict Feature Access per Role | Rule: the Super Administrator role has all feature access | TC-SA-02-03-019 |
| 3.3 Scope Data Access per Role | Scope types: all, own, team/institute, custom record-set rules | TC-SA-02-03-020 |
| 3.3 Scope Data Access per Role | Per-role scope configuration per data category | TC-SA-02-03-021 |
| 3.3 Scope Data Access per Role | Scope applied consistently across lists, detail views, search, exports | TC-SA-02-03-022 |
| 3.3 Scope Data Access per Role | Multi-role scope resolution per policy (default union) | TC-SA-02-03-023 |
| 3.3 Scope Data Access per Role | Scope preview: what a sample user of the role would see | TC-SA-02-03-024 |
| 3.3 Scope Data Access per Role | Audit logging of scope changes | TC-SA-02-03-025 |
| 3.3 Scope Data Access per Role | Rule: scoped-out records unreachable by any path | TC-SA-02-03-026 |
| 3.3 Scope Data Access per Role | Rule: two users with the same role can see different record sets | TC-SA-02-03-027 |
| 3.3 Scope Data Access per Role | Rule: multi-role resolution documented and consistent | TC-SA-02-03-023 |
| 3.3 Scope Data Access per Role | Rule: feature without data scope can yield an empty view; preview surfaces it | TC-SA-02-03-028 |
| 3.3 Scope Data Access per Role | Rule: institute-level isolation is a scope boundary | TC-SA-02-03-029 |
| 3.3 Scope Data Access per Role | Rule: all scope changes audit-logged | TC-SA-02-03-025 |
| 3.4 Permission Change Preview and Propagation | Change preview: capabilities gained/lost and affected user count | TC-SA-02-03-030 |
| 3.4 Permission Change Preview and Propagation | Side-by-side before/after permission set | TC-SA-02-03-031 |
| 3.4 Permission Change Preview and Propagation | Save confirmation with the preview summary | TC-SA-02-03-032 |
| 3.4 Permission Change Preview and Propagation | Immediate propagation: holders update on next request | TC-SA-02-03-033 |
| 3.4 Permission Change Preview and Propagation | No re-login required for holders | TC-SA-02-03-034 |
| 3.4 Permission Change Preview and Propagation | Audit logging with before/after state and affected count | TC-SA-02-03-035 |
| 3.4 Permission Change Preview and Propagation | Rule: preview is mandatory; no silent permission change | TC-SA-02-03-036 |
| 3.4 Permission Change Preview and Propagation | Rule: propagation immediate; no re-login | TC-SA-02-03-033 |
| 3.4 Permission Change Preview and Propagation | Rule: removing an actively used permission ends it on the next action; in-progress completes | TC-SA-02-03-037 |
| 3.4 Permission Change Preview and Propagation | Rule: before/after state captured in the audit log | TC-SA-02-03-035 |
| 3.4 Permission Change Preview and Propagation | Rule: bulk role edits produce a single preview covering all changes | TC-SA-02-03-038 |
| 3.4 Permission Change Preview and Propagation | Rule: affected user count always shown | TC-SA-02-03-030 |

## 3.1 System-Wide Permission Catalog

### TC-SA-02-03-001 — Catalog is organized by module
**Type:** Positive
**Covers:** 3.1 → Permission catalog organized by module
**Preconditions:** Super Admin logged in.
**Steps:**
1. Open the permission catalog.
2. Browse the module grouping (Authentication, Courses, Content, Billing, etc.).
**Expected Result:** Every permission is grouped under its module; the grouping is complete and navigable.
**Priority:** High

### TC-SA-02-03-002 — The catalog contains all three permission types
**Type:** Positive
**Covers:** 3.1 → Three permission types: feature access, action, data scope
**Preconditions:** Super Admin logged in; the Billing module is in the catalog.
**Steps:**
1. Open the Billing module in the catalog.
2. Verify the presence of feature access (open Pricing Management), actions (create plan, process refund, configure gateway), and data scopes (all invoices, own-institute invoices).
**Expected Result:** All three permission types are present and correctly typed for the module.
**Priority:** High

### TC-SA-02-03-003 — New platform capabilities appear in the catalog automatically
**Type:** Positive
**Covers:** 3.1 → Catalog is system-managed; new permissions appear as capabilities ship; Rule: entries are not user-defined
**Preconditions:** A new platform capability (e.g., a new report type) has shipped.
**Steps:**
1. Open the permission catalog and search for the new capability's permission.
2. Attempt to create a custom catalog entry manually.
**Expected Result:** The new permission appears in the catalog automatically; no manual creation path exists — entries are platform-managed.
**Priority:** High

### TC-SA-02-03-004 — Catalog browser: search and filter by module, type, name
**Type:** Positive
**Covers:** 3.1 → Catalog browser: search and filter permissions by module, type, and name
**Preconditions:** Super Admin logged in.
**Steps:**
1. Search for "refund" and review the results across modules.
2. Filter by module, then by type, then by name.
**Expected Result:** Search returns every permission containing the capability across modules; each filter narrows results correctly.
**Priority:** Medium

### TC-SA-02-03-005 — Permission detail view shows what it grants and which roles hold it
**Type:** Positive
**Covers:** 3.1 → Permission detail view: what the permission grants, which roles currently hold it; Rule: "held by" visibility supports informed granting
**Preconditions:** A permission with known holders exists.
**Steps:**
1. Open the detail view for the "process refund" permission.
2. Review the "held by" column.
**Expected Result:** The detail view explains what the permission grants and lists every role currently holding it — supporting blast-radius awareness.
**Priority:** High

### TC-SA-02-03-006 — The catalog is read-only for the Super Admin
**Type:** Negative
**Covers:** 3.1 → Read-only for the Super Admin (the catalog reflects platform capabilities)
**Preconditions:** Super Admin logged in; the catalog is open.
**Steps:**
1. Attempt to create a new catalog entry.
2. Attempt to rename an existing entry.
3. Attempt to delete an existing entry.
**Expected Result:** All three attempts are impossible — the catalog is read-only; it reflects platform capabilities, not user-defined entries.
**Priority:** High

### TC-SA-02-03-007 — A role cannot grant a permission that is not in the catalog
**Type:** Negative
**Covers:** 3.1 → Rule: the catalog is the upper bound of what any role can grant
**Preconditions:** Super Admin logged in; a role editor is open.
**Steps:**
1. Attempt to add a permission to a role that does not exist in the catalog.
**Expected Result:** The permission cannot be selected or added — the catalog defines the upper bound of grantable permissions.
**Priority:** Critical

### TC-SA-02-03-008 — Granting a feature without the data scope may yield no visible records
**Type:** Edge
**Covers:** 3.1 → Rule: data-scope permissions are distinct; granting a feature without the data scope may still result in no visible records
**Preconditions:** A role is granted feature access to a section but no corresponding data scope.
**Steps:**
1. Assign the role to a test user.
2. The user opens the section.
**Expected Result:** The section opens but shows no visible records (or only in-scope records) — feature access and data scope are independent permissions.
**Priority:** High

### TC-SA-02-03-009 — The same permission governs web and service surfaces
**Type:** Edge
**Covers:** 3.1 → Rule: the catalog is consistent across web and service surfaces
**Preconditions:** A user's role lacks the "process refund" permission.
**Steps:**
1. The user attempts the refund action via the web UI.
2. The same operation is attempted via a direct service/API request.
**Expected Result:** Both are denied by the same permission check — the catalog is consistent across surfaces; there is no UI-only or API-only permission.
**Priority:** Critical

### TC-SA-02-03-010 — Catalog changes are visible in the change history
**Type:** Positive
**Covers:** 3.1 → Rule: catalog changes (new entries) are visible in the change history
**Preconditions:** A new catalog entry has appeared after a platform capability shipped.
**Steps:**
1. Open the catalog change history.
2. Locate the new entry.
**Expected Result:** The new entry appears in the change history so role owners can review what became grantable.
**Priority:** Medium

## 3.2 Grant or Restrict Feature Access per Role

### TC-SA-02-03-011 — Feature-level toggles per role organized by module
**Type:** Positive
**Covers:** 3.2 → Feature-level toggles per role in the role editor (organized by module)
**Preconditions:** Super Admin logged in; the Student Support Administrator role editor is open.
**Steps:**
1. Review the feature-access toggles grouped by module.
2. Toggle on the specific feature "Support Reporting" under Customer Support without granting the rest of the module.
**Expected Result:** Toggles are per-feature and organized by module; only the selected feature is granted.
**Priority:** High

### TC-SA-02-03-012 — Navigation shows only the features a role can access
**Type:** Positive
**Covers:** 3.2 → Navigation shaping: a role's menu shows only the features it can access
**Preconditions:** A user holds a role with a known feature set.
**Steps:**
1. Log in as the user.
2. Inspect the navigation menu.
**Expected Result:** The menu shows exactly the features the role can access — no more, no less.
**Priority:** High

### TC-SA-02-03-013 — Direct navigation to an unpermitted feature is denied server-side
**Type:** Negative
**Covers:** 3.2 → Server-side enforcement: direct navigation denied with a clear message; Rule: enforced at the service layer, not just the UI
**Preconditions:** A support admin's role lacks the Marketing & Communication module.
**Steps:**
1. The support admin manually navigates to the Marketing module URL.
2. Observe the response and the access-denied log.
**Expected Result:** The request is denied server-side with "You don't have permission to access this section"; the denial is logged — hiding from the menu is a convenience, the denial is the control.
**Priority:** Critical

### TC-SA-02-03-014 — Change preview shows the affected user count before saving
**Type:** Positive
**Covers:** 3.2 → Change preview: affected user count before saving; Rule: previews show the affected user count
**Preconditions:** A feature-access toggle change is staged for a role held by 3 users.
**Steps:**
1. Stage the toggle change.
2. Review the preview before saving.
**Expected Result:** The preview states "Affects 3 users — gains: open Support Reporting" before any save.
**Priority:** High

### TC-SA-02-03-015 — Feature-access changes propagate immediately to holders
**Type:** Positive
**Covers:** 3.2 → Immediate propagation to holders
**Preconditions:** A feature is toggled on for a role held by 3 users with active sessions.
**Steps:**
1. Save the toggle change.
2. Each holder refreshes their navigation on their next request.
**Expected Result:** All 3 holders see the new section in their navigation on their next request — no re-login.
**Priority:** Critical

### TC-SA-02-03-016 — Feature-access changes are audit-logged with before/after state
**Type:** Positive
**Covers:** 3.2 → Audit logging of feature-access changes; Rule: all feature-access changes audit-logged
**Preconditions:** A feature-access change has been saved.
**Steps:**
1. Open the Permission Audit Trail and filter by the role.
**Expected Result:** The change is audit-logged with before/after state, the affected user count, the actor, and the timestamp.
**Priority:** Critical

### TC-SA-02-03-017 — A denied feature offers a clear message with an optional "request access" path
**Type:** Positive
**Covers:** 3.2 → Rule: a denied feature produces a clear message with an optional "request access" path
**Preconditions:** "Request access" is enabled per policy; a user lacks a feature.
**Steps:**
1. The user attempts the unpermitted feature.
2. Review the denial message.
3. Use the "request access" path.
**Expected Result:** The message is clear; the request routes to Super Admin with the requester and target.
**Priority:** Medium

### TC-SA-02-03-018 — Granting a feature does not automatically grant its actions
**Type:** Edge
**Covers:** 3.2 → Rule: actions are separate permissions (a role may open a section but only view, not edit)
**Preconditions:** A role is granted feature access to a section but no edit actions.
**Steps:**
1. Assign the role to a test user.
2. The user opens the section and attempts an edit action.
**Expected Result:** The section opens (view allowed); the edit action is denied — actions are separate permissions.
**Priority:** High

### TC-SA-02-03-019 — The Super Administrator role is not subject to feature toggles
**Type:** Edge
**Covers:** 3.2 → Rule: the Super Administrator role has all feature access and is not subject to these toggles
**Preconditions:** Super Admin logged in.
**Steps:**
1. Attempt to find feature-access toggles for the Super Administrator role.
2. As Super Admin, open every module.
**Expected Result:** No toggles apply to the Super Administrator role; full feature access is always available.
**Priority:** Medium

## 3.3 Scope Data Access per Role

### TC-SA-02-03-020 — All four scope types are configurable
**Type:** Positive
**Covers:** 3.3 → Scope types: all records, own records, team/institute records, custom record-set rules
**Preconditions:** Super Admin logged in; a role editor is open.
**Steps:**
1. For a data category, set the scope to "all records" and verify.
2. Set it to "own records" and verify.
3. Set it to "team/institute records" and verify.
4. Define a custom record-set rule and verify.
**Expected Result:** Each scope type is configurable and behaves as defined for a test holder.
**Priority:** High

### TC-SA-02-03-021 — Per-role scope configuration per data category
**Type:** Positive
**Covers:** 3.3 → Per-role scope configuration in the role editor (per data category: courses, students, tickets, invoices, etc.)
**Preconditions:** Super Admin logged in; the Teacher/Content Creator role editor is open.
**Steps:**
1. Set the scope for courses to "own records" and for students to "own records".
2. Set the scope for institute data to "own institute".
3. Save and verify with a test holder.
**Expected Result:** Each data category carries its own scope; the holder sees only their assigned courses/students and only their institute's data.
**Priority:** Critical

### TC-SA-02-03-022 — Scope applies consistently across lists, detail views, search, and exports
**Type:** Positive
**Covers:** 3.3 → Scope applied consistently across lists, detail views, search, and exports
**Preconditions:** A teacher's scope is "own records" for courses and students.
**Steps:**
1. The teacher opens the course list.
2. Opens a detail view for an in-scope course.
3. Runs a search for students.
4. Exports the enrollment list.
**Expected Result:** All four surfaces show exactly the in-scope records — consistent scoping everywhere.
**Priority:** Critical

### TC-SA-02-03-023 — Multi-role scope resolution follows the documented policy
**Type:** Positive
**Covers:** 3.3 → Multi-role scope resolution per policy (default union); Rule: resolution documented and consistent
**Preconditions:** A user holds two roles with different scopes for the same data category.
**Steps:**
1. Log in as the user and open the affected list.
2. Compare the visible records with the documented policy resolution.
**Expected Result:** The effective scope matches the policy (default: union of visible records) — documented and applied consistently.
**Priority:** High

### TC-SA-02-03-024 — Scope preview shows what a sample user of the role would see
**Type:** Positive
**Covers:** 3.3 → Scope preview: what a sample user of the role would see
**Preconditions:** The Teacher/Content Creator role's scope is "own records"; a sample teacher has 3 assigned courses; an institute admin role is scoped to "all records within own institute" (40 courses).
**Steps:**
1. Run the scope preview for the teacher role with the sample teacher.
2. Run the scope preview for the institute admin role.
**Expected Result:** The preview shows the sample teacher seeing only their 3 assigned courses and the institute admin seeing all 40 courses in their institute.
**Priority:** High

### TC-SA-02-03-025 — Scope changes are audit-logged with before/after definitions
**Type:** Positive
**Covers:** 3.3 → Audit logging of scope changes; Rule: all scope changes audit-logged
**Preconditions:** A scope change has been saved for a role.
**Steps:**
1. Open the Permission Audit Trail and filter by the role.
**Expected Result:** The scope change is audit-logged with the before/after scope definitions, the affected roles, the actor, and the timestamp.
**Priority:** Critical

### TC-SA-02-03-026 — A scoped-out record cannot be reached by any path
**Type:** Negative
**Covers:** 3.3 → Rule: scoping applies to lists, detail views, search, and exports — a scoped-out record cannot be reached by any path
**Preconditions:** A teacher's scope excludes a colleague's course.
**Steps:**
1. The teacher attempts to open the colleague's course by direct URL/ID.
2. Searches for the course by name.
3. Attempts to include it in an export.
**Expected Result:** Every path is denied or excludes the record; the attempt is logged.
**Priority:** Critical

### TC-SA-02-03-027 — Two users with the same role see different record sets
**Type:** Edge
**Covers:** 3.3 → Rule: two users with the same role can see different record sets; scoping is per-user within the role
**Preconditions:** Two teachers hold the same "own records" role with different course assignments.
**Steps:**
1. Log in as each teacher and open the course list.
**Expected Result:** Each teacher sees only their own assigned courses — the same role, different per-user record sets.
**Priority:** High

### TC-SA-02-03-028 — Feature access without data scope surfaces an empty view in the preview
**Type:** Edge
**Covers:** 3.3 → Rule: granting feature access without the corresponding data scope can result in an empty view; the scope preview surfaces this
**Preconditions:** A role has feature access to a section but no data scope for its records.
**Steps:**
1. Run the scope preview for the role.
**Expected Result:** The preview surfaces that a sample user would see an empty view — flagging the missing data scope before it ships.
**Priority:** Medium

### TC-SA-02-03-029 — Institute-level isolation is a hard scope boundary
**Type:** Negative
**Covers:** 3.3 → Rule: institute-level isolation is a scope boundary — one institute's data is not visible to another institute's users
**Preconditions:** Staff of institute A and institute B exist with institute-scoped roles.
**Steps:**
1. As institute A staff, attempt to view institute B's courses, students, and content via lists, search, and direct IDs.
**Expected Result:** Every attempt is denied or excluded — institute B's data is never visible to institute A's users.
**Priority:** Critical

## 3.4 Permission Change Preview and Propagation

### TC-SA-02-03-030 — Change preview shows capabilities gained/lost and the affected user count
**Type:** Positive
**Covers:** 3.4 → Change preview: capabilities gained/lost and the affected user count; Rule: affected user count always shown
**Preconditions:** "Process refunds" is about to be removed from the Billing Administrator role (3 holders).
**Steps:**
1. Stage the removal in the role editor.
2. Review the preview.
**Expected Result:** The preview states "Affects 3 users — loses: process refunds; keeps: view billing, manage plans, configure gateway" — the blast radius is explicit.
**Priority:** Critical

### TC-SA-02-03-031 — Side-by-side before/after permission set is shown
**Type:** Positive
**Covers:** 3.4 → Side-by-side before/after permission set
**Preconditions:** A multi-permission change is staged.
**Steps:**
1. Stage the change and open the preview.
2. Review the side-by-side comparison.
**Expected Result:** The before and after permission sets are displayed side-by-side so only the intended differences are visible.
**Priority:** High

### TC-SA-02-03-032 — Save requires confirmation with the preview summary
**Type:** Positive
**Covers:** 3.4 → Save confirmation with the preview summary
**Preconditions:** A permission change is staged with a preview.
**Steps:**
1. Click save.
2. Review the confirmation dialog.
3. Cancel, then confirm.
**Expected Result:** Saving requires an explicit confirmation showing the preview summary; cancelling applies nothing; confirming applies the change.
**Priority:** High

### TC-SA-02-03-033 — Propagation is immediate on the next request without re-login
**Type:** Positive
**Covers:** 3.4 → Immediate propagation: holders' access updates on their next request; Rule: no re-login required
**Preconditions:** 3 billing admins have active sessions; "process refunds" is removed from their role.
**Steps:**
1. Save the removal.
2. Each billing admin makes their next request without re-logging in.
**Expected Result:** All 3 can no longer initiate refunds on their next request — propagation is immediate in existing sessions.
**Priority:** Critical

### TC-SA-02-03-034 — Holders do not need to re-login for permission changes
**Type:** Positive
**Covers:** 3.4 → No re-login required for holders
**Preconditions:** A holder has an active session spanning a permission change.
**Steps:**
1. Change the role's permissions while the holder's session is active.
2. The holder continues working in the same session.
**Expected Result:** The session remains valid; the new permissions apply on subsequent requests — no re-login is ever required.
**Priority:** High

### TC-SA-02-03-035 — Audit log captures before/after state and affected count
**Type:** Positive
**Covers:** 3.4 → Audit logging with before/after state and affected count; Rule: before/after state captured for reconstruction
**Preconditions:** A permission change has been saved.
**Steps:**
1. Open the Permission Audit Trail and inspect the entry.
**Expected Result:** The entry contains the complete before/after permission sets, the actor, the affected user count, and the timestamp — sufficient for exact reconstruction.
**Priority:** Critical

### TC-SA-02-03-036 — No silent permission change is possible
**Type:** Negative
**Covers:** 3.4 → Rule: the preview is mandatory before save; there is no silent permission change
**Preconditions:** Super Admin logged in; a role editor is open.
**Steps:**
1. Attempt to save a permission change without reviewing/confirming the preview.
**Expected Result:** The save is blocked until the mandatory preview is reviewed and confirmed — no silent permission change can occur.
**Priority:** Critical

### TC-SA-02-03-037 — Removing an actively used permission: in-progress request completes, next action denied
**Type:** Edge
**Covers:** 3.4 → Rule: removing a permission a user is actively using ends that capability on their next action; the current in-progress request completes
**Preconditions:** A billing admin is mid-refund-screen when "process refunds" is removed from their role.
**Steps:**
1. Remove the permission and save while the admin is on the refund screen.
2. The admin completes the current view.
3. The admin attempts to submit the refund.
**Expected Result:** The in-progress view completes; the submit is denied with a clear "you no longer have permission" message.
**Priority:** High

### TC-SA-02-03-038 — Bulk role edits produce a single preview covering all changes
**Type:** Edge
**Covers:** 3.4 → Rule: bulk role edits (multiple permissions at once) produce a single preview covering all changes
**Preconditions:** Three permission changes are staged in one role-edit session.
**Steps:**
1. Stage all three changes.
2. Open the preview.
**Expected Result:** A single preview covers all three changes with the combined affected user count — not three separate previews.
**Priority:** Medium