# Validation Report: URS-004 **Title:** Admin approve or reject a sales representative **Date:** 2026-04-23T03:33:42.637Z **Duration:** 57.6s **Overall Status:** ✅ PASS ## User Requirement > The system shall allow ZuriMED admins to approve or reject a sales representative *Source: `User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx` — the run below proves the system meets this requirement.* ## Environment - **Inbox URL:** http://localhost:61678 - **Database:** localhost:61679/cc_repinbox_dev ## Setup Status: ✅ PASS ## Test Steps Each step below corresponds to one Playwright test that ran sequentially. Screenshots and video recordings provide visual evidence of the UI behaviour. ### 1. Step 1: Admin navigates to rep management — ✅ PASS **What this step proves:** Proves that a ZuriMED admin (Alex) can authenticate and reach the Sales Reps management page. Both StellarTech reps — Bob (pending approval) and Ryan (active) — appear in the roster, establishing admin context for the approve/reject actions that follow. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:33:45Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:33:52Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:01Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:11Z | user_log | user:login | ryan.delauintana@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:18Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:25Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | **Screenshots:** ![step 01 admin logged in](screenshots/step-01-admin-logged-in.png) ![step 01 rep list](screenshots/step-01-rep-list.png) **Video recording:** [▶ Watch step recording](videos/step-01-admin-navigate.webm) --- ### 2. Step 2: Admin rejects Bob — ✅ PASS **What this step proves:** Alex opens Bob's detail page, clicks Reject Representative, supplies a rejection reason, and confirms. Proves that an admin has an in-app control to deny a rep onboarding. The relationship row moves to status='rejected', active=false, and a rep_creation_request_rejected notification is dispatched to the distributor. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-04-23T03:33:56.235Z → 2026-04-23T03:34:00.824Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:34:00Z | user_log | rep_onboarding_request_rejected | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:00Z | transactional_email | rep_creation_request_rejected | — | StellarTech Medical Solutions | — | **Emails triggered by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* **Email 1: Representative Request Rejected - ZuriMED** Template: `Representative_Request_Rejected_-_ZuriMED` ![Representative Request Rejected - ZuriMED](screenshots/emails/2026-04-23T03-34-00-333Z-Representative_Request_Rejected_-_ZuriMED.png) **Screenshots:** ![step 02 bob detail pending](screenshots/step-02-bob-detail-pending.png) ![step 02 reject dialog](screenshots/step-02-reject-dialog.png) ![step 02 bob detail rejected](screenshots/step-02-bob-detail-rejected.png) **Video recording:** [▶ Watch step recording](videos/step-02-admin-rejects.webm) --- ### 3. Step 3: Bob blocked from creating orders — ✅ PASS **What this step proves:** Bob logs in after being rejected and opens the order creation page. ZuriMED is filtered out of the manufacturer dropdown because `getAvailableFulfillingOrganizations` requires an active representation relationship. Proves the admin action is a hard restriction on downstream order creation — not just a cosmetic UI change. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:33:45Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:33:52Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:01Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:11Z | user_log | user:login | ryan.delauintana@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:18Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:25Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | **Screenshots:** ![step 03 bob no zurimed](screenshots/step-03-bob-no-zurimed.png) **Video recording:** [▶ Watch step recording](videos/step-03-bob-blocked.webm) --- ### 4. Step 4: Ryan (control) can still create orders — ✅ PASS **What this step proves:** Ryan, an unrelated StellarTech rep, is unaffected by the action taken on Bob. He reaches Step 2 of the order form as normal, proving that admin decisions are scoped to the rep under review and do not inadvertently strip privileges from other reps. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:33:45Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:33:52Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:01Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:11Z | user_log | user:login | ryan.delauintana@stellartech.com | StellarTech Medical Solutions | — | | 2026-04-23 03:34:18Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:25Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | **Screenshots:** ![step 04 ryan order form](screenshots/step-04-ryan-order-form.png) **Video recording:** [▶ Watch step recording](videos/step-04-ryan-control.webm) --- ### 5. Step 5: Admin approves Bob — ✅ PASS **What this step proves:** After the test harness returns Bob's status to 'proposed', Alex approves him through the UI's Approve Representative flow. The relationship row becomes status='active', active=true; a rep_created notification is dispatched to StellarTech announcing the approval. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-04-23T03:34:22.095Z → 2026-04-23T03:34:24.010Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:34:23Z | user_log | rep_onboarding_request_approved | alex.admin@zurimed.com | ZuriMED | — | | 2026-04-23 03:34:23Z | transactional_email | rep_created | — | StellarTech Medical Solutions | — | **Emails triggered by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* **Email 1: Representative Account Approved - ZuriMED** Template: `Representative_Account_Approved_-_ZuriMED` ![Representative Account Approved - ZuriMED](screenshots/emails/2026-04-23T03-34-23-508Z-Representative_Account_Approved_-_ZuriMED.png) **Screenshots:** ![step 05 bob detail pending again](screenshots/step-05-bob-detail-pending-again.png) ![step 05 approve dialog](screenshots/step-05-approve-dialog.png) ![step 05 bob detail approved](screenshots/step-05-bob-detail-approved.png) **Video recording:** [▶ Watch step recording](videos/step-05-admin-approves.webm) --- ### 6. Step 6: Bob submits an order after approval — ✅ PASS **What this step proves:** Now-approved Bob logs back in, reaches the order form, picks a delivery location, adds a product, and submits. Proves the restriction lifts immediately on approval — the admin's status change takes effect without any further action. The order request persists in the database for the DB-validation phase to confirm. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-04-23T03:34:30.841Z → 2026-04-23T03:34:35.360Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-04-23 03:34:35Z | decision | order_request_created | bob.kauffman@stellartech.com | ZuriMED | yes | **Screenshots:** ![step 06 order step2](screenshots/step-06-order-step2.png) ![step 06 order review](screenshots/step-06-order-review.png) ![step 06 order submitted](screenshots/step-06-order-submitted.png) **Video recording:** [▶ Watch step recording](videos/step-06-bob-orders.webm) --- ## Database Validations The following SQL queries ran against the application database after the Playwright scenarios completed. Each query asserts a specific condition that proves the feature under test persisted its data correctly. ### Bob's relationship ended the run as active — ✅ PASS **Assertion:** After the approve flow Bob's relationship should be status='active', active=true. ```sql SELECT id, status, active, rejection_reason FROM organization_representation_relationships WHERE id = $1 ``` | id | status | active | rejection_reason | | --- | --- | --- | --- | | 84c5d6e7-f8a9-0123-8901-234567890123 | active | true | NULL | ### Rejection status transition recorded — ✅ PASS **Assertion:** A proposed→rejected transition should have been recorded during the test run. ```sql SELECT from_status, to_status, reason, created_at FROM organization_representation_request_status_changes WHERE relationship_id = $1 AND to_status = 'rejected' AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | from_status | to_status | reason | created_at | | --- | --- | --- | --- | | proposed | rejected | URS-004 validation test: admin rejecting rep to verify order-creation is blocked. | 2026-04-23T03:34:00.290Z | ### Approval status transition recorded — ✅ PASS **Assertion:** A proposed→active transition should have been recorded during the test run. ```sql SELECT from_status, to_status, created_at FROM organization_representation_request_status_changes WHERE relationship_id = $1 AND to_status = 'active' AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | from_status | to_status | created_at | | --- | --- | --- | | proposed | active | 2026-04-23T03:34:23.488Z | ### Approved rep successfully submitted an order — ✅ PASS **Assertion:** At least one order_requests row should exist, tagged with the URS-004 marker. ```sql SELECT id, request_number, status, order_type, created_at FROM order_requests WHERE requested_by_user_id = $1 AND notes LIKE $2 ORDER BY created_at DESC ``` | id | request_number | status | order_type | created_at | | --- | --- | --- | --- | --- | | 019db867-5e07-71fe-8abf-bdbe67b1d2e9 | OR-1 | submitted | consignment | 2026-04-23T03:34:35.256Z | ### Audit events logged for approve and reject — ✅ PASS **Assertion:** audit_events should include both rep_onboarding_request_approved and rep_onboarding_request_rejected actions from this run. ```sql SELECT event_type, action, created_at FROM audit_events WHERE event_type = 'user_log' AND action IN ('rep_onboarding_request_approved', 'rep_onboarding_request_rejected') AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | event_type | action | created_at | | --- | --- | --- | | user_log | rep_onboarding_request_approved | 2026-04-23T03:34:23.499Z | | user_log | rep_onboarding_request_rejected | 2026-04-23T03:34:00.342Z | ## Audit & Email Assertion Ledger Per-declaration outcome of every `expectedAuditActions` and `expectedEmailTemplates` entry written into the orchestrator. Missing evidence here is a real test failure, not a soft warning. ### Audit Action Assertions Each row asserts that a declared `expectedAuditActions` entry produced a matching row in `audit_events`. A ❌ flips overall status to FAIL — the declaration is real proof, not just an annotation. | Step | Expected Audit Action | Found | |------|-----------------------|-------| | Step 1: Admin navigates to rep management | `user_log:user:login` | ✅ | | Step 2: Admin rejects Bob | `user_log:rep_onboarding_request_rejected` | ✅ | | Step 3: Bob blocked from creating orders | `user_log:user:login` | ✅ | | Step 4: Ryan (control) can still create orders | `user_log:user:login` | ✅ | | Step 5: Admin approves Bob | `user_log:rep_onboarding_request_approved` | ✅ | | Step 6: Bob submits an order after approval | `user_log:user:login` | ✅ | | Step 6: Bob submits an order after approval | `decision:order_request_created` | ✅ | ### Email Template Assertions Each row asserts that a declared `expectedEmailTemplates` entry was matched (case-insensitive substring) by a captured email subject or template. A ❌ flips overall status to FAIL. | Step | Expected Template | Found | |------|-------------------|-------| | Step 2: Admin rejects Bob | `Representative Request Rejected` | ✅ | | Step 5: Admin approves Bob | `Representative Account Approved` | ✅ | ## Audit Log Events Every row written to `audit_events` while this test was running (scoped to the demo organizations). Provides compliance evidence that user actions are traced end-to-end (URS-003). **Capture window start:** 2026-04-23T03:33:40.719Z
Query used to capture events ```sql SELECT ae.created_at, ae.event_type, ae.action, ae.user_id, u.email AS user_email, ae.organization_id, o.name AS organization_name, ae.object_id, ae.secondary_object_id, ae.payload, ae.route, ae.trace_id FROM audit_events ae LEFT JOIN users u ON u.id = ae.user_id LEFT JOIN organizations o ON o.id = ae.organization_id WHERE ae.created_at >= $1 AND ae.organization_id = ANY($2::uuid[]) ORDER BY ae.created_at ASC ```
11 event(s) captured: | Time | Type | Action | User | Org | Object ID | Performed | Reason | |------|------|--------|------|-----|-----------|-----------|--------| | 2026-04-23 03:33:45Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | — | | | 2026-04-23 03:33:52Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | — | | | 2026-04-23 03:34:00Z | user_log | rep_onboarding_request_rejected | alex.admin@zurimed.com | ZuriMED | 84c5d6e7-f8a9-0123-8901-234567890123 | — | | | 2026-04-23 03:34:00Z | transactional_email | rep_creation_request_rejected | — | StellarTech Medical Solutions | — | — | | | 2026-04-23 03:34:01Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | | | 2026-04-23 03:34:11Z | user_log | user:login | ryan.delauintana@stellartech.com | StellarTech Medical Solutions | — | — | | | 2026-04-23 03:34:18Z | user_log | user:login | alex.admin@zurimed.com | ZuriMED | — | — | | | 2026-04-23 03:34:23Z | user_log | rep_onboarding_request_approved | alex.admin@zurimed.com | ZuriMED | 84c5d6e7-f8a9-0123-8901-234567890123 | — | | | 2026-04-23 03:34:23Z | transactional_email | rep_created | — | StellarTech Medical Solutions | — | — | | | 2026-04-23 03:34:25Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | | | 2026-04-23 03:34:35Z | decision | order_request_created | bob.kauffman@stellartech.com | ZuriMED | 019db867-5e07-71fe-8abf-bdbe67b1d2e9 | yes | Order request OR-1 created (importSource=manual) | ## Email Evidence 2 notification email(s) were captured during this test run. Each email is rendered as a screenshot for compliance review. ### 1. Representative Request Rejected - ZuriMED **Template:** `Representative_Request_Rejected_-_ZuriMED` ![Representative Request Rejected - ZuriMED](screenshots/emails/2026-04-23T03-34-00-333Z-Representative_Request_Rejected_-_ZuriMED.png) ### 2. Representative Account Approved - ZuriMED **Template:** `Representative_Account_Approved_-_ZuriMED` ![Representative Account Approved - ZuriMED](screenshots/emails/2026-04-23T03-34-23-508Z-Representative_Account_Approved_-_ZuriMED.png)