URS-004 · Admin approve or reject a sales representative

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:

Video recording:

---

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

Screenshots:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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

Screenshots:

Video recording:

---

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:

Video recording:

---

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.

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.

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.

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.

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.

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

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

2. Representative Account Approved - ZuriMED

Template: Representative_Account_Approved_-_ZuriMED

Downloads

• audit-events.json
• report.md
• result.json
• screenshots-index.json
• step-timings.json

Feedback