# 1. Platform Branding — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: platform_branding.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 Configure Platform Name and Logo | Platform display name (used in the interface, browser context, and communications) | TC-SA-04-01-001 |
| 1.1 Configure Platform Name and Logo | Logo upload with format/size validation and a preview | TC-SA-04-01-002 |
| 1.1 Configure Platform Name and Logo | Logo variants: full logo, compact/favicons-style mark, and a light/dark variant where applicable | TC-SA-04-01-003 |
| 1.1 Configure Platform Name and Logo | Preview of the branding across key surfaces (interface header, email header, export header) | TC-SA-04-01-004 |
| 1.1 Configure Platform Name and Logo | Save with immediate platform-wide application | TC-SA-04-01-005 |
| 1.1 Configure Platform Name and Logo | Change history of branding updates | TC-SA-04-01-006 |
| 1.1 Configure Platform Name and Logo | Audit logging of branding changes | TC-SA-04-01-007 |
| 1.1 Configure Platform Name and Logo | Rule: logo uploads are validated (format, size, dimensions); invalid files are rejected with the specific reason | TC-SA-04-01-008 |
| 1.1 Configure Platform Name and Logo | Rule: the preview covers the key surfaces before save, so a bad asset is caught before it goes live | TC-SA-04-01-004 |
| 1.1 Configure Platform Name and Logo | Rule: light/dark variants are required where the interface has both themes; a missing variant is flagged | TC-SA-04-01-009 |
| 1.1 Configure Platform Name and Logo | Rule: changes apply platform-wide on save; there is no per-institute branding in this setting | TC-SA-04-01-005 |
| 1.1 Configure Platform Name and Logo | Rule: the previous branding is retained in the change history for rollback reference | TC-SA-04-01-006 |
| 1.1 Configure Platform Name and Logo | Rule: branding changes are audit-logged with the acting admin and timestamp | TC-SA-04-01-007 |
| 1.2 Configure Email Templates and Branding | Template library: all transactional/communication email templates with their trigger context | TC-SA-04-01-010 |
| 1.2 Configure Email Templates and Branding | Template editor: subject, body blocks, merge fields (user name, course, amount, etc.), and links | TC-SA-04-01-011 |
| 1.2 Configure Email Templates and Branding | Branded header and footer applied from the platform branding (logo, name, colors) | TC-SA-04-01-012 |
| 1.2 Configure Email Templates and Branding | Per-template settings: send enablement, subject line, and required blocks | TC-SA-04-01-013 |
| 1.2 Configure Email Templates and Branding | Preview with sample merge-field values before saving | TC-SA-04-01-014 |
| 1.2 Configure Email Templates and Branding | Language variants per supported language (see Localization) | TC-SA-04-01-015 |
| 1.2 Configure Email Templates and Branding | Audit logging of template changes | TC-SA-04-01-016 |
| 1.2 Configure Email Templates and Branding | Rule: the branded header/footer is driven by the platform branding; updating branding updates email branding without editing each template | TC-SA-04-01-012 |
| 1.2 Configure Email Templates and Branding | Rule: merge fields are validated: a template cannot reference a field that does not exist for its trigger context | TC-SA-04-01-017 |
| 1.2 Configure Email Templates and Branding | Rule: the preview uses sample values, so the layout is checkable without sending a real email | TC-SA-04-01-014 |
| 1.2 Configure Email Templates and Branding | Rule: language variants are tracked per supported language; an untranslated variant is flagged, not silently sent in the wrong language | TC-SA-04-01-015 |
| 1.2 Configure Email Templates and Branding | Rule: compliance-required blocks (e.g., footer legal lines) are protected: they cannot be removed, only updated | TC-SA-04-01-018 |
| 1.2 Configure Email Templates and Branding | Rule: template changes are audit-logged; a test-send path exists to verify live rendering | TC-SA-04-01-016 |

## 1.1 Configure Platform Name and Logo

### TC-SA-04-01-001 — The platform display name is used in the interface, browser context, and communications
**Type:** Positive
**Covers:** 1.1 → Platform display name (used in the interface, browser context, and communications)
**Preconditions:** The platform display name is "Mi Digital Academy".
**Steps:**
1. Open the interface and verify the display name in the header.
2. Check the browser tab/context for the display name.
3. Open a communication (e.g., a test email) and verify the display name.
**Expected Result:** The display name appears consistently in the interface, the browser context, and communications.
**Priority:** High

### TC-SA-04-01-002 — Logo upload passes format/size validation and shows a preview
**Type:** Positive
**Covers:** 1.1 → Logo upload with format/size validation and a preview
**Preconditions:** A valid logo file (correct format, size, dimensions) is ready.
**Steps:**
1. Upload the valid logo file.
2. Verify it passes format/size validation.
3. Verify the preview renders the logo.
**Expected Result:** The valid logo uploads, passes validation, and renders in the preview.
**Priority:** High

### TC-SA-04-01-003 — Logo variants: full logo, compact mark, and light/dark variant
**Type:** Positive
**Covers:** 1.1 → Logo variants: full logo, compact/favicons-style mark, and a light/dark variant where applicable
**Preconditions:** Three logo assets are ready: full logo, compact mark, and light/dark variants.
**Steps:**
1. Upload the full logo, the compact mark, and the light/dark variants.
2. Verify each variant is stored and rendered in its context (full in the header, compact in the favicon, light/dark per theme).
**Expected Result:** All logo variants are uploaded and rendered in their correct contexts — full, compact, and light/dark.
**Priority:** High

### TC-SA-04-01-004 — Preview covers the key surfaces before save: interface header, email header, export header
**Type:** Positive
**Covers:** 1.1 → Preview of the branding across key surfaces (interface header, email header, export header); Rule: the preview covers the key surfaces before save, so a bad asset is caught before it goes live
**Preconditions:** New branding assets are staged (not yet saved).
**Steps:**
1. Open the branding preview.
2. Verify the interface header, the email template header, and the report export header all show the new name and logo.
**Expected Result:** The preview shows the new branding across all three key surfaces — a bad asset is caught before it goes live.
**Priority:** Critical

### TC-SA-04-01-005 — Save applies the branding platform-wide immediately; no per-institute branding in this setting
**Type:** Positive
**Covers:** 1.1 → Save with immediate platform-wide application; Rule: changes apply platform-wide on save; there is no per-institute branding in this setting (institute-level identity is separate)
**Preconditions:** New branding is previewed and confirmed.
**Steps:**
1. Save the branding.
2. Open key screens across the platform and verify the new branding is live.
3. Verify there is no per-institute branding option in this setting.
**Expected Result:** The branding applies platform-wide immediately on save; no per-institute branding exists in this setting.
**Priority:** Critical

### TC-SA-04-01-006 — Change history retains the previous branding for rollback reference
**Type:** Positive
**Covers:** 1.1 → Change history of branding updates; Rule: the previous branding is retained in the change history for rollback reference
**Preconditions:** A branding change has been saved.
**Steps:**
1. Open the branding change history.
2. Verify the previous branding is recorded with the date and the acting admin.
**Expected Result:** The change history shows the previous branding with the date and the acting admin — available for rollback reference.
**Priority:** Medium

### TC-SA-04-01-007 — Branding changes are audit-logged with the assets changed and the timestamp
**Type:** Positive
**Covers:** 1.1 → Audit logging of branding changes; Rule: branding changes are audit-logged with the acting admin and timestamp
**Preconditions:** A branding change has been saved.
**Steps:**
1. Open the audit trail and filter by "branding".
2. Verify the entry shows the assets changed, the acting admin, and the timestamp.
**Expected Result:** The branding change is audit-logged with the assets changed, the acting admin, and the timestamp.
**Priority:** Critical

### TC-SA-04-01-008 — Invalid logo files are rejected with the specific reason
**Type:** Negative
**Covers:** 1.1 → Rule: logo uploads are validated (format, size, dimensions); invalid files are rejected with the specific reason
**Preconditions:** Three invalid logo files: wrong format, oversized, wrong dimensions.
**Steps:**
1. Upload the wrong-format file.
2. Upload the oversized file.
3. Upload the wrong-dimensions file.
**Expected Result:** All three are rejected with the specific reason (format, size, or dimensions) — no invalid asset is accepted.
**Priority:** High

### TC-SA-04-01-009 — A missing light/dark variant is flagged where the interface has both themes
**Type:** Negative
**Covers:** 1.1 → Rule: light/dark variants are required where the interface has both themes; a missing variant is flagged
**Preconditions:** The interface has both light and dark themes; only the light variant is uploaded.
**Steps:**
1. Attempt to save the branding with only the light variant.
2. Verify the missing dark variant is flagged.
**Expected Result:** The missing dark variant is flagged — the save is blocked or the gap is clearly indicated.
**Priority:** High

## 1.2 Configure Email Templates and Branding

### TC-SA-04-01-010 — The template library lists all transactional/communication email templates with their trigger context
**Type:** Positive
**Covers:** 1.2 → Template library: all transactional/communication email templates with their trigger context
**Preconditions:** The platform has templates for verification, receipts, notifications, and welcome.
**Steps:**
1. Open the template library.
2. Verify each template is listed with its trigger context.
**Expected Result:** All templates are listed with their trigger context — the library is complete.
**Priority:** High

### TC-SA-04-01-011 — The template editor supports subject, body blocks, merge fields, and links
**Type:** Positive
**Covers:** 1.2 → Template editor: subject, body blocks, merge fields (user name, course, amount, etc.), and links
**Preconditions:** The "Welcome" template is open in the editor.
**Steps:**
1. Edit the subject line.
2. Edit the body blocks.
3. Insert merge fields (user name, first course) from the palette.
4. Add/verify links.
**Expected Result:** The editor supports all four: subject, body blocks, merge fields, and links — all editable.
**Priority:** High

### TC-SA-04-01-012 — The branded header/footer is driven by the platform branding; updating branding updates email branding without editing each template
**Type:** Positive
**Covers:** 1.2 → Branded header and footer applied from the platform branding (logo, name, colors); Rule: the branded header/footer is driven by the platform branding; updating branding updates email branding without editing each template
**Preconditions:** The platform branding is updated (new logo and name).
**Steps:**
1. Update the platform branding (new logo and name).
2. Open an email template and verify the header/footer reflect the new branding.
3. Verify no per-template editing was required.
**Expected Result:** The email header/footer automatically reflects the new platform branding — no per-template editing needed.
**Priority:** Critical

### TC-SA-04-01-013 — Per-template settings: send enablement, subject line, and required blocks
**Type:** Positive
**Covers:** 1.2 → Per-template settings: send enablement, subject line, and required blocks
**Preconditions:** A template is open in the editor.
**Steps:**
1. Toggle the send enablement off and verify the template is disabled.
2. Set the subject line.
3. Verify the required blocks are present.
**Expected Result:** The per-template settings work — send enablement toggles, the subject is set, and required blocks are enforced.
**Priority:** Medium

### TC-SA-04-01-014 — Preview uses sample merge-field values; the layout is checkable without sending a real email
**Type:** Positive
**Covers:** 1.2 → Preview with sample merge-field values before saving; Rule: the preview uses sample values, so the layout is checkable without sending a real email
**Preconditions:** A template with merge fields is staged.
**Steps:**
1. Open the preview.
2. Verify the merge fields show sample values and the layout renders correctly.
3. Verify no real email was sent.
**Expected Result:** The preview shows sample merge-field values and the correct layout — no real email is sent.
**Priority:** High

### TC-SA-04-01-015 — Language variants are tracked per supported language; an untranslated variant is flagged, not silently sent in the wrong language
**Type:** Positive
**Covers:** 1.2 → Language variants per supported language (see Localization); Rule: language variants are tracked per supported language; an untranslated variant is flagged, not silently sent in the wrong language
**Preconditions:** A template is updated in English; the Spanish variant is not yet translated.
**Steps:**
1. Save the English update.
2. Verify the Spanish variant is flagged as untranslated.
3. Verify the Spanish variant is not silently sent in English.
**Expected Result:** The Spanish variant is flagged as untranslated — it is not silently sent in the wrong language.
**Priority:** High

### TC-SA-04-01-016 — Template changes are audit-logged; a test-send path exists to verify live rendering
**Type:** Positive
**Covers:** 1.2 → Audit logging of template changes; Rule: template changes are audit-logged; a test-send path exists to verify live rendering
**Preconditions:** A template change is saved.
**Steps:**
1. Open the audit trail and verify the template change is logged (template, blocks changed, timestamp).
2. Use the test-send path to send a test email to a test account.
3. Verify the live rendering (header, body, links, footer).
**Expected Result:** The template change is audit-logged; the test-send path delivers a test email with the correct live rendering.
**Priority:** Critical

### TC-SA-04-01-017 — A template cannot reference a merge field that does not exist for its trigger context
**Type:** Negative
**Covers:** 1.2 → Rule: merge fields are validated: a template cannot reference a field that does not exist for its trigger context
**Preconditions:** A "Welcome" template is being edited; the field "payment_amount" does not exist for the welcome trigger context.
**Steps:**
1. Attempt to insert the "payment_amount" merge field into the welcome template.
**Expected Result:** The field is rejected — it does not exist for the welcome trigger context; the template cannot reference it.
**Priority:** High

### TC-SA-04-01-018 — Compliance-required blocks are protected: they cannot be removed, only updated
**Type:** Negative
**Covers:** 1.2 → Rule: compliance-required blocks (e.g., footer legal lines) are protected: they cannot be removed, only updated
**Preconditions:** A template contains a compliance-required footer block (legal lines).
**Steps:**
1. Attempt to remove the compliance-required footer block.
2. Attempt to update its text.
**Expected Result:** The removal is blocked (the block is protected); the update is allowed — the block can be updated but not removed.
**Priority:** Critical