# 1. Role Definition — Test Cases

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

---

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

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 1.1 Create Custom Roles | Role creation form: name (unique), description, optional category/tag | TC-SA-02-01-001 |
| 1.1 Create Custom Roles | Starting permission set: empty by default, or copy from an existing role | TC-SA-02-01-002, TC-SA-02-01-003 |
| 1.1 Create Custom Roles | Permission assignment from the catalog during creation | TC-SA-02-01-004 |
| 1.1 Create Custom Roles | Uniqueness validation on role name | TC-SA-02-01-005 |
| 1.1 Create Custom Roles | Role status: active/inactive | TC-SA-02-01-006, TC-SA-02-01-010 |
| 1.1 Create Custom Roles | Audit logging of role creation with the initial permission set | TC-SA-02-01-007 |
| 1.1 Create Custom Roles | Rule: role names unique; duplicates rejected | TC-SA-02-01-005 |
| 1.1 Create Custom Roles | Rule: new role has no permissions until granted (deny-by-default) | TC-SA-02-01-008 |
| 1.1 Create Custom Roles | Rule: copying does not propagate later source changes | TC-SA-02-01-009 |
| 1.1 Create Custom Roles | Rule: inactive roles cannot be assigned; holders keep access | TC-SA-02-01-010 |
| 1.1 Create Custom Roles | Rule: creation audit-logged with actor, timestamp, initial set | TC-SA-02-01-007 |
| 1.1 Create Custom Roles | Rule: Super Administrator role cannot be created/edited/deleted | TC-SA-02-01-011 |
| 1.2 Edit Roles | Edit role name and description (identity preserved) | TC-SA-02-01-012 |
| 1.2 Edit Roles | Toggle role status active/inactive | TC-SA-02-01-013 |
| 1.2 Edit Roles | Add or remove permissions from the role's set | TC-SA-02-01-014, TC-SA-02-01-015 |
| 1.2 Edit Roles | Change preview: affected user count and capabilities gained/lost | TC-SA-02-01-016 |
| 1.2 Edit Roles | Immediate propagation to all holders on their next request | TC-SA-02-01-017 |
| 1.2 Edit Roles | Audit logging of every edit with before/after permission sets | TC-SA-02-01-018 |
| 1.2 Edit Roles | Rule: renaming does not break assignments | TC-SA-02-01-012 |
| 1.2 Edit Roles | Rule: removed permission takes effect on next request; in-progress completes | TC-SA-02-01-019 |
| 1.2 Edit Roles | Rule: preview always shows affected user count | TC-SA-02-01-016 |
| 1.2 Edit Roles | Rule: every edit audit-logged with before/after state | TC-SA-02-01-018 |
| 1.2 Edit Roles | Rule: no re-login required; propagation is prompt | TC-SA-02-01-017 |
| 1.2 Edit Roles | Rule: Super Administrator role cannot be edited | TC-SA-02-01-020 |
| 1.3 Delete and Archive Roles | Delete: only for roles with zero holders | TC-SA-02-01-021, TC-SA-02-01-026 |
| 1.3 Delete and Archive Roles | Archive: for roles with holders; blocks new assignments, retains history | TC-SA-02-01-022, TC-SA-02-01-027 |
| 1.3 Delete and Archive Roles | Reassignment assistance: list of current holders | TC-SA-02-01-023 |
| 1.3 Delete and Archive Roles | Confirmation with impact summary | TC-SA-02-01-024 |
| 1.3 Delete and Archive Roles | Audit logging of deletion/archival with actor and reason | TC-SA-02-01-025 |
| 1.3 Delete and Archive Roles | Rule: deletion blocked while holders exist | TC-SA-02-01-026 |
| 1.3 Delete and Archive Roles | Rule: archived roles cannot be assigned; visible; reactivatable | TC-SA-02-01-027 |
| 1.3 Delete and Archive Roles | Rule: archival does not change existing holders' access | TC-SA-02-01-028 |
| 1.3 Delete and Archive Roles | Rule: deletion irreversible; audit history retained | TC-SA-02-01-029 |
| 1.3 Delete and Archive Roles | Rule: every deletion/archival requires a recorded reason | TC-SA-02-01-025 |
| 1.3 Delete and Archive Roles | Rule: predefined and Super Administrator roles cannot be deleted | TC-SA-02-01-030 |
| 1.4 Predefined Sub-Administrator Roles | Billing Administrator default set | TC-SA-02-01-031 |
| 1.4 Predefined Sub-Administrator Roles | Teacher/Content Creator default set | TC-SA-02-01-032 |
| 1.4 Predefined Sub-Administrator Roles | Content Reviewer default set | TC-SA-02-01-033 |
| 1.4 Predefined Sub-Administrator Roles | Student Support Administrator default set | TC-SA-02-01-034 |
| 1.4 Predefined Sub-Administrator Roles | Default permission sets are editable | TC-SA-02-01-035 |
| 1.4 Predefined Sub-Administrator Roles | Protection: predefined roles cannot be deleted | TC-SA-02-01-036 |
| 1.4 Predefined Sub-Administrator Roles | Usage visibility: holder count and last-activity | TC-SA-02-01-037 |
| 1.4 Predefined Sub-Administrator Roles | Rule: predefined roles editable but not deletable | TC-SA-02-01-036 |
| 1.4 Predefined Sub-Administrator Roles | Rule: editing a predefined role affects all holders across institutes | TC-SA-02-01-038 |
| 1.4 Predefined Sub-Administrator Roles | Rule: default sets follow separation of duties | TC-SA-02-01-039 |
| 1.4 Predefined Sub-Administrator Roles | Rule: holder count and last-activity visible per role | TC-SA-02-01-037 |
| 1.4 Predefined Sub-Administrator Roles | Rule: all changes to predefined roles audit-logged | TC-SA-02-01-040 |
| 1.4 Predefined Sub-Administrator Roles | Rule: Super Administrator role is separate from the predefined set | TC-SA-02-01-041 |

## 1.1 Create Custom Roles

### TC-SA-02-01-001 — Create a custom role with name, description, and category
**Type:** Positive
**Covers:** 1.1 → Role creation form: name (unique), description, optional category/tag
**Preconditions:** Super Admin logged in; a unique role name "Course Operations" not yet in use.
**Steps:**
1. Open Role & Permission Management → Roles and select "Create role".
2. Enter the name "Course Operations", a description, and the category "Operations".
3. Save the role.
**Expected Result:** The role is created with the exact name, description, and category; it appears in the role list and in the role-assignment picker.
**Priority:** Critical

### TC-SA-02-01-002 — New role starts with an empty permission set (deny-by-default)
**Type:** Positive
**Covers:** 1.1 → Starting permission set: empty by default
**Preconditions:** Super Admin logged in; creating a new role without copying from another role.
**Steps:**
1. Create a new role "Empty Test Role" without selecting "Copy permissions from".
2. Save the role.
3. Open the role editor and inspect the permission set.
4. Assign the role to a test user and attempt to open a section the role does not grant.
**Expected Result:** The role's permission set is empty; the test user is denied access to every section and action not explicitly granted — deny-by-default holds.
**Priority:** Critical

### TC-SA-02-01-003 — Create a role by copying permissions from an existing role
**Type:** Positive
**Covers:** 1.1 → Starting permission set: copy from an existing role as a starting point
**Preconditions:** Super Admin logged in; the Teacher/Content Creator role exists with a known permission set.
**Steps:**
1. Create a new role "Course Operations" and choose "Copy permissions from" → Teacher/Content Creator.
2. Remove the content-creation permissions from the copy.
3. Save and compare the new role's set with the source role's set.
**Expected Result:** The new role starts with an exact copy of the source's current permission set; the removed permissions are absent; the source role is unchanged.
**Priority:** High

### TC-SA-02-01-004 — Assign permissions from the catalog during creation
**Type:** Positive
**Covers:** 1.1 → Permission assignment from the catalog during creation (features, actions, data scopes)
**Preconditions:** Super Admin logged in; creating a new role.
**Steps:**
1. In the role editor, add from the catalog: view courses (feature), manage scheduling (action), view enrollment lists (feature), export enrollment reports (action).
2. Save the role.
3. Assign the role to a test user and exercise each granted capability.
**Expected Result:** All four catalog permissions are attached to the role; the test user can perform exactly those capabilities and nothing else.
**Priority:** High

### TC-SA-02-01-005 — Duplicate role name is rejected at creation
**Type:** Negative
**Covers:** 1.1 → Uniqueness validation on role name; Rule: duplicates rejected
**Preconditions:** Super Admin logged in; a role named "Billing Administrator" already exists.
**Steps:**
1. Select "Create role" and enter the name "Billing Administrator".
2. Attempt to save.
**Expected Result:** The system rejects the creation with a uniqueness validation error; no duplicate role is created; the role list is unchanged.
**Priority:** High

### TC-SA-02-01-006 — Created role is active and assignable
**Type:** Positive
**Covers:** 1.1 → Role status: active/inactive
**Preconditions:** Super Admin logged in; a new role "Course Operations" just created.
**Steps:**
1. Open the role list and check the status of "Course Operations".
2. Open the role-assignment picker for a test user.
**Expected Result:** The role's status is active; it is selectable in the role-assignment picker.
**Priority:** High

### TC-SA-02-01-007 — Role creation is audit-logged with the initial permission set
**Type:** Positive
**Covers:** 1.1 → Audit logging of role creation with the initial permission set; Rule: actor, timestamp, initial set
**Preconditions:** Super Admin logged in; a new role with a known initial permission set is about to be created.
**Steps:**
1. Create the role "Audit Test Role" with 3 specific permissions.
2. Open the Permission Audit Trail and filter by action "role create" and target "Audit Test Role".
**Expected Result:** An audit entry exists recording the actor (Super Admin), the timestamp, and the complete initial permission set exactly as saved.
**Priority:** Critical

### TC-SA-02-01-008 — A new role grants nothing until permissions are added
**Type:** Edge
**Covers:** 1.1 → Rule: a new role has no permissions until granted — deny-by-default
**Preconditions:** A brand-new role with zero permissions is assigned to a test user who previously had no roles.
**Steps:**
1. Log in as the test user.
2. Attempt to open each major module (Courses, Billing, Content, Marketing).
3. Attempt direct URL navigation to a section.
**Expected Result:** Every request is denied; the user has no role-based access at all; no section, action, or record is reachable.
**Priority:** Critical

### TC-SA-02-01-009 — Later changes to the source role do not propagate to the copy
**Type:** Edge
**Covers:** 1.1 → Rule: copying copies the current set; later source changes do not propagate
**Preconditions:** Role "Copy Target" was created by copying from "Source Role"; both exist.
**Steps:**
1. Add a new permission to "Source Role" and save.
2. Open "Copy Target" and inspect its permission set.
3. Remove a permission from "Source Role" and re-inspect "Copy Target".
**Expected Result:** "Copy Target" is unaffected by both the addition and the removal — it retains the snapshot taken at copy time.
**Priority:** High

### TC-SA-02-01-010 — Inactive role cannot be assigned; existing holders keep access
**Type:** Negative
**Covers:** 1.1 → Role status: active/inactive; Rule: inactive roles cannot be assigned; holders keep access
**Preconditions:** Role "Legacy Role" is active and held by 2 users; Super Admin toggles it inactive.
**Steps:**
1. Open the role-assignment picker for a new user and look for "Legacy Role".
2. Log in as one of the 2 existing holders and exercise the role's permissions.
**Expected Result:** "Legacy Role" is absent from the picker (cannot be assigned to new users); the existing holders retain full access until reassigned.
**Priority:** High

### TC-SA-02-01-011 — The Super Administrator role cannot be created, edited, or deleted
**Type:** Negative
**Covers:** 1.1 → Rule: the Super Administrator role is fixed and outside this flow
**Preconditions:** Super Admin logged in.
**Steps:**
1. Attempt to create a role named "Super Administrator".
2. Attempt to open the existing Super Administrator role in the role editor.
3. Attempt to delete or archive the Super Administrator role.
**Expected Result:** All three attempts are blocked: the name is reserved, the role is not editable through this flow, and deletion/archival is unavailable.
**Priority:** Critical

## 1.2 Edit Roles

### TC-SA-02-01-012 — Renaming a role preserves identity and assignments
**Type:** Positive
**Covers:** 1.2 → Edit role name and description; Rule: renaming does not break assignments
**Preconditions:** Role "Content Ops" is held by 3 users.
**Steps:**
1. Open the role editor for "Content Ops" and rename it to "Content Operations Team".
2. Save.
3. Log in as one of the 3 holders and verify their access.
4. Open the role-holder view for the renamed role.
**Expected Result:** The role's identity is stable — the 3 holders remain assigned, their access is unchanged, and the holder list is intact under the new name.
**Priority:** High

### TC-SA-02-01-013 — Toggle role status active/inactive
**Type:** Positive
**Covers:** 1.2 → Toggle role status active/inactive
**Preconditions:** Super Admin logged in; an active custom role exists.
**Steps:**
1. Open the role editor and toggle the status to inactive; save.
2. Verify the role list shows the inactive status.
3. Toggle the status back to active; save.
**Expected Result:** The status changes are persisted and reflected in the role list; the inactive role is excluded from the assignment picker while inactive and restored when reactivated.
**Priority:** Medium

### TC-SA-02-01-014 — Add a permission to an existing role
**Type:** Positive
**Covers:** 1.2 → Add or remove permissions from the role's set
**Preconditions:** Role "Content Reviewer" is held by 4 users; "Approve resource library items" is not in its set.
**Steps:**
1. Open the role editor and add "Approve resource library items" from the catalog.
2. Save with the change preview confirmation.
3. Log in as one of the 4 holders and check the review queue.
**Expected Result:** The permission is added to the role; the 4 holders see the new approve action on their next request.
**Priority:** Critical

### TC-SA-02-01-015 — Remove a permission from an existing role
**Type:** Positive
**Covers:** 1.2 → Add or remove permissions from the role's set
**Preconditions:** Role "Content Reviewer" currently includes "Approve resource library items".
**Steps:**
1. Open the role editor and remove "Approve resource library items".
2. Save with the change preview confirmation.
3. Log in as a holder and attempt to approve a resource library item.
**Expected Result:** The permission is removed; the holder is denied the approve action on their next request.
**Priority:** Critical

### TC-SA-02-01-016 — Change preview shows affected user count and capabilities gained/lost
**Type:** Positive
**Covers:** 1.2 → Change preview: affected user count and capabilities gained/lost; Rule: preview always shows affected user count
**Preconditions:** Role "Content Reviewer" is held by 4 users; a permission change is staged.
**Steps:**
1. Stage the addition of "Approve resource library items".
2. Review the change preview before saving.
**Expected Result:** The preview states the affected user count (4) and the exact capability gained ("approve resource library items"); no save occurs until confirmed.
**Priority:** High

### TC-SA-02-01-017 — Permission edits propagate immediately without re-login
**Type:** Positive
**Covers:** 1.2 → Immediate propagation to all holders on their next request; Rule: no re-login required
**Preconditions:** A holder of "Content Reviewer" has an active session; the role is about to gain a new permission.
**Steps:**
1. Add the new permission to the role and save.
2. Without re-logging in, the holder makes their next request (refreshes the review queue).
**Expected Result:** The new permission is effective on the holder's next request in the existing session — no re-login is required.
**Priority:** Critical

### TC-SA-02-01-018 — Every role edit is audit-logged with before/after permission sets
**Type:** Positive
**Covers:** 1.2 → Audit logging of every edit with before/after permission sets; Rule: every edit audit-logged
**Preconditions:** A role edit (add + later remove of a permission) has been performed.
**Steps:**
1. Open the Permission Audit Trail and filter by the target role.
2. Inspect the entries for both edits.
**Expected Result:** Each edit has an entry with the actor, timestamp, and the complete before/after permission sets, enabling exact reconstruction.
**Priority:** Critical

### TC-SA-02-01-019 — Removed permission: in-progress action completes, new actions denied
**Type:** Edge
**Covers:** 1.2 → Rule: removing a permission takes effect on the next request; in-progress screens complete the current action
**Preconditions:** A holder is mid-flow on a screen that uses a permission about to be removed from their role.
**Steps:**
1. While the holder is on the in-progress screen, remove the permission from the role and save.
2. The holder completes the current action on the open screen.
3. The holder attempts to initiate a new action requiring the removed permission.
**Expected Result:** The in-progress action completes; the new action is denied with a clear permission message.
**Priority:** High

### TC-SA-02-01-020 — The Super Administrator role cannot be edited through the role editor
**Type:** Negative
**Covers:** 1.2 → Rule: the Super Administrator role cannot be edited through this flow
**Preconditions:** Super Admin logged in.
**Steps:**
1. Attempt to open the Super Administrator role in the role editor.
2. Attempt to modify its permission set or status.
**Expected Result:** The role is not editable through this flow; no modification is possible.
**Priority:** High

## 1.3 Delete and Archive Roles

### TC-SA-02-01-021 — Delete a role with zero holders
**Type:** Positive
**Covers:** 1.3 → Delete: available only for roles with zero holders
**Preconditions:** Role "Unused Role" has zero holders.
**Steps:**
1. Select "Delete" for "Unused Role".
2. Review the confirmation (permission set, last-usage date) and confirm.
**Expected Result:** The role and its permission set are removed from the role list; the deletion succeeds because no holders exist.
**Priority:** High

### TC-SA-02-01-022 — Archive a role that has holders
**Type:** Positive
**Covers:** 1.3 → Archive: available for roles with holders; blocks new assignments, retains history
**Preconditions:** Role "Legacy Billing" is held by 2 users.
**Steps:**
1. Select "Archive" for "Legacy Billing".
2. Review the confirmation: "2 users currently hold this role. Archiving will prevent new assignments; existing holders keep access until reassigned."
3. Confirm with the reason "Role retired after billing reorganization".
4. Check the role list and the role-assignment picker.
**Expected Result:** The role appears as archived in the role list, is excluded from the assignment picker, and its audit history is retained.
**Priority:** Critical

### TC-SA-02-01-023 — Reassignment assistance lists current holders
**Type:** Positive
**Covers:** 1.3 → Reassignment assistance: list of current holders with a path to assign replacement roles
**Preconditions:** Role "Legacy Billing" is held by 2 users and is being archived.
**Steps:**
1. Open the archival flow for "Legacy Billing".
2. Review the reassignment assistance panel.
**Expected Result:** The panel lists the 2 current holders with a direct path to assign replacement roles before deletion.
**Priority:** Medium

### TC-SA-02-01-024 — Deletion confirmation shows the impact summary
**Type:** Positive
**Covers:** 1.3 → Confirmation with impact summary (holders, permissions, recent usage)
**Preconditions:** An archived role with zero holders is about to be deleted.
**Steps:**
1. Select "Delete" for the archived role.
2. Review the final confirmation dialog.
**Expected Result:** The confirmation displays the role's permission set, holder count (zero), and last-usage date before the deletion proceeds.
**Priority:** Medium

### TC-SA-02-01-025 — Deletion and archival are audit-logged with actor and reason
**Type:** Positive
**Covers:** 1.3 → Audit logging of deletion/archival with the actor and reason; Rule: every deletion/archival requires a recorded reason
**Preconditions:** An archival and a subsequent deletion have been performed with recorded reasons.
**Steps:**
1. Open the Permission Audit Trail and filter by the target role.
2. Attempt an archival without providing a reason.
**Expected Result:** Both events are audit-logged with the actor, timestamp, and the recorded reason; the no-reason archival is blocked until a reason is provided.
**Priority:** Critical

### TC-SA-02-01-026 — Deletion is blocked while any user holds the role
**Type:** Negative
**Covers:** 1.3 → Rule: deletion is blocked while any user holds the role
**Preconditions:** Role "Legacy Billing" is held by 2 users.
**Steps:**
1. Attempt to select "Delete" for "Legacy Billing".
**Expected Result:** Deletion is unavailable/blocked; the UI shows the holder count (2) and guides reassignment or archival instead.
**Priority:** Critical

### TC-SA-02-01-027 — Archived role: not assignable, visible, and reactivatable
**Type:** Edge
**Covers:** 1.3 → Rule: archived roles cannot be assigned but remain visible and can be reactivated
**Preconditions:** Role "Legacy Billing" is archived.
**Steps:**
1. Verify the role is absent from the role-assignment picker.
2. Verify the role is still visible in the role list with its archived status.
3. Reactivate the role and verify it reappears in the picker.
**Expected Result:** The archived role is excluded from assignment, remains visible for audit, and reactivation restores assignability.
**Priority:** High

### TC-SA-02-01-028 — Archival does not change existing holders' access
**Type:** Edge
**Covers:** 1.3 → Rule: archival does not change the access of existing holders until reassigned
**Preconditions:** Role "Legacy Billing" is held by 2 users and is archived.
**Steps:**
1. Log in as each of the 2 holders.
2. Exercise the role's billing capabilities.
**Expected Result:** Both holders retain full access to the role's permissions until they are reassigned — archival alone changes nothing for them.
**Priority:** High

### TC-SA-02-01-029 — Deletion is irreversible but audit history is retained
**Type:** Edge
**Covers:** 1.3 → Rule: deletion is irreversible; the role's audit history is retained
**Preconditions:** An archived, zero-holder role is deleted.
**Steps:**
1. Delete the role and confirm.
2. Search the role list for the deleted role.
3. Open the Permission Audit Trail and search for the role's history.
**Expected Result:** The role no longer exists and cannot be restored; its full history (creation, edits, holders over time) remains queryable in the audit trail.
**Priority:** High

### TC-SA-02-01-030 — Predefined sub-administrator roles cannot be deleted
**Type:** Negative
**Covers:** 1.3 → Rule: predefined sub-administrator roles and the Super Administrator role cannot be deleted
**Preconditions:** Super Admin logged in; the 4 predefined sub-administrator roles exist.
**Steps:**
1. Attempt to delete each predefined role (Billing Administrator, Teacher/Content Creator, Content Reviewer, Student Support Administrator).
2. Attempt to delete the Super Administrator role.
**Expected Result:** All deletion attempts are blocked; archival is available for predefined roles only where policy allows; the Super Administrator role has no delete/archive path.
**Priority:** Critical

## 1.4 Predefined Sub-Administrator Roles

### TC-SA-02-01-031 — Billing Administrator default permission set is correct
**Type:** Positive
**Covers:** 1.4 → Billing Administrator: plans, pricing, discounts, payments, refunds, billing reports; no content/curriculum
**Preconditions:** Super Admin logged in; the Billing Administrator role is at its default set.
**Steps:**
1. Open the Billing Administrator role editor.
2. Verify the set includes: manage plans, pricing, discounts, payments, refunds, and billing reports.
3. Verify the set excludes all content and curriculum permissions.
**Expected Result:** The default set matches the documented scope exactly — full billing capability, zero content or curriculum access.
**Priority:** Critical

### TC-SA-02-01-032 — Teacher/Content Creator default permission set is correct
**Type:** Positive
**Covers:** 1.4 → Teacher/Content Creator: creates and manages assigned courses and content; no billing/pricing/platform settings
**Preconditions:** Super Admin logged in; the Teacher/Content Creator role is at its default set.
**Steps:**
1. Open the role editor.
2. Verify the set includes: create courses, upload/manage content, view own analytics, scoped to assigned courses.
3. Verify the set excludes billing, pricing, and platform-wide settings.
**Expected Result:** The default set matches the documented scope exactly.
**Priority:** Critical

### TC-SA-02-01-033 — Content Reviewer default permission set is correct
**Type:** Positive
**Covers:** 1.4 → Content Reviewer: reviews and approves/rejects submissions; read access to content; no creation or billing
**Preconditions:** Super Admin logged in; the Content Reviewer role is at its default set.
**Steps:**
1. Open the role editor.
2. Verify the set includes: review queue access, approve/reject content, read access to content.
3. Verify the set excludes content creation and all billing permissions.
**Expected Result:** The default set matches the documented scope exactly.
**Priority:** Critical

### TC-SA-02-01-034 — Student Support Administrator default permission set is correct
**Type:** Positive
**Covers:** 1.4 → Student Support Administrator: student accounts, support tickets, student data within scope; no billing configuration or content approval
**Preconditions:** Super Admin logged in; the Student Support Administrator role is at its default set.
**Steps:**
1. Open the role editor.
2. Verify the set includes: manage student accounts, support tickets, and student data within scope.
3. Verify the set excludes billing configuration and content approval.
**Expected Result:** The default set matches the documented scope exactly.
**Priority:** Critical

### TC-SA-02-01-035 — Predefined role default sets are editable
**Type:** Positive
**Covers:** 1.4 → Default permission sets are editable (starting points, not fixed)
**Preconditions:** Super Admin logged in; the Teacher/Content Creator role is at its default set.
**Steps:**
1. Open the role editor and add "view resource library" (read access).
2. Review the change preview (all holders affected) and save.
**Expected Result:** The edit is accepted — predefined roles are starting points, not fixed; the change propagates to all holders.
**Priority:** High

### TC-SA-02-01-036 — Predefined roles cannot be deleted
**Type:** Negative
**Covers:** 1.4 → Protection: predefined roles cannot be deleted; they can be archived or edited
**Preconditions:** Super Admin logged in.
**Steps:**
1. Attempt to delete each of the 4 predefined sub-administrator roles.
2. Verify the available lifecycle actions for each.
**Expected Result:** Deletion is blocked for all predefined roles; editing and (where policy allows) archival remain available.
**Priority:** High

### TC-SA-02-01-037 — Usage visibility: holder count and last-activity per predefined role
**Type:** Positive
**Covers:** 1.4 → Usage visibility: holder count and last-activity per predefined role; Rule: visible per role
**Preconditions:** The 4 predefined roles have known holders with known activity.
**Steps:**
1. Open the role list for the predefined roles.
2. Check the holder count and last-activity for each.
**Expected Result:** Each predefined role displays its current holder count and last-activity, supporting staffing and access reviews.
**Priority:** Medium

### TC-SA-02-01-038 — Editing a predefined role affects all holders across all institutes
**Type:** Edge
**Covers:** 1.4 → Rule: editing a predefined role affects all its holders across all institutes
**Preconditions:** The Teacher/Content Creator role is held by teachers in 3 different institutes.
**Steps:**
1. Add a new permission to the Teacher/Content Creator role and save.
2. Log in as holders from each of the 3 institutes.
**Expected Result:** The change is effective for every holder in every institute; where an institute needs a variation, the documented path is a custom copy.
**Priority:** High

### TC-SA-02-01-039 — Default sets follow separation of duties
**Type:** Edge
**Covers:** 1.4 → Rule: no single predefined role combines content approval with billing, or billing configuration with refund approval
**Preconditions:** Super Admin logged in; all 4 predefined roles at default sets.
**Steps:**
1. For each predefined role, inspect the permission set for conflicting combinations (content approval + billing; billing configuration + refund approval).
**Expected Result:** No predefined role's default set contains a separation-of-duties conflict.
**Priority:** High

### TC-SA-02-01-040 — Changes to predefined roles are audit-logged
**Type:** Positive
**Covers:** 1.4 → Rule: all changes to predefined roles are audit-logged like any other role edit
**Preconditions:** An edit has been made to a predefined role.
**Steps:**
1. Open the Permission Audit Trail and filter by the predefined role.
**Expected Result:** The edit is audit-logged with the same before/after detail as any other role edit — actor, timestamp, before/after sets, affected count.
**Priority:** High

### TC-SA-02-01-041 — The Super Administrator role is not part of the predefined set
**Type:** Edge
**Covers:** 1.4 → Rule: the Super Administrator role is separate from the sub-administrator predefined set
**Preconditions:** Super Admin logged in.
**Steps:**
1. Open the predefined sub-administrator roles list.
2. Check whether the Super Administrator role appears in the set.
**Expected Result:** The predefined set contains exactly the 4 sub-administrator roles; the Super Administrator role is separate and not listed among them.
**Priority:** Medium