URS-008 · Restrict Reps from Editing Accounts Outside Assigned Organization

Title: Restrict Reps from Editing Accounts Outside Assigned Organization Date: 2026-04-23T03:35:29.564Z Duration: 44.4s Overall Status: ✅ PASS

User Requirement

The system shall restrict reps from editing accounts outside their assigned organization.

Source: User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx — the run below proves the system meets this requirement.

Environment

• Inbox URL: http://localhost:62393
• Database: localhost:62394/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: Rep login — ✅ PASS

What this step proves:

Establishes the authenticated session for Bob Kauffman (StellarTech sales rep, role downgraded by setup). A successful login is the precondition for every subsequent step — without it, cross-organization failures would be indistinguishable from an unauthenticated redirect.

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:35:35Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:40Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:48Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:57Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:36:08Z	user_log	user:login	dan.distributor@stellartech.com	StellarTech Medical Solutions	—

Screenshots:

Video recording:

---

2. Step 2: Foreign-org account absent from list — ✅ PASS

What this step proves:

Navigates to /sales-accounts and asserts that the foreign-organization account’s name and UUID do not appear anywhere on the page. The list query filters by the caller’s organization, so a StellarTech rep must see only StellarTech-owned accounts. Proving absence-from-list closes the first half of the isolation story: the foreign account cannot be discovered through the app’s normal navigation.

Screenshots:

Video recording:

---

3. Step 3: In-organization account detail loads — ✅ PASS

What this step proves:

Loads the BOSS account detail page — BOSS is owned by Bob’s own organization (StellarTech). Confirming this page renders normally rules out the scenario where the Step 4 failure is caused by a broad access bug. It is the “negative control” that bounds the cross-org check.

Screenshots:

Video recording:

---

4. Step 4: Rep receives 404 on foreign-org account URL — ✅ PASS

What this step proves:

Navigates the rep directly to the foreign-organization account URL. The server-side route resolves through getSalesAccountWithOrgCheck, which returns null when the user’s organization matches neither the account’s distributor nor manufacturer; the route then throws a 404. Asserting both the HTTP status and the rendered error text proves the block is enforced on the server, not only in the UI.

Screenshots:

Video recording:

---

5. Step 5: Admin also blocked — org-scoped, not role-scoped — ✅ PASS

What this step proves:

Repeats Step 4 as Dan Distributor (StellarTech admin). The admin has sales_accounts:manage but is still in StellarTech, so the organization filter must still return null and the route must still 404. Proving this isolates the restriction as organization-scoped — the URS requirement is met by organization membership, not by role.

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:35:35Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:40Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:48Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:35:57Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—
2026-04-23 03:36:08Z	user_log	user:login	dan.distributor@stellartech.com	StellarTech Medical Solutions	—

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.

Rep has Sales Representative role — ✅ PASS

Assertion: Bob Kauffman should have the Sales Representative role in StellarTech so the test exercises a “rep” per the URS wording

SELECT u.email, u.name, r.name as role_name, r.id as role_id
      FROM users u
      JOIN user_roles ur ON ur.user_id = u.id
      JOIN roles r ON r.id = ur.role_id
      WHERE u.id = $1 AND ur.organization_id = $2

email	name	role_name	role_id
bob.kauffman@stellartech.com	Bob Kauffman	Sales Representative	d2e3f4a5-b6c7-8901-def0-123456789abc

Sales Rep role has sales_accounts:view — ✅ PASS

Assertion: The Sales Representative role must include sales_accounts:view so that absence-from-list is an organization scoping effect, not a permission gap

SELECT p.permission
      FROM permissions p
      WHERE p.actor_id = $1
      AND p.permission = 'sales_accounts:view'

permission
sales_accounts:view

Rep belongs only to StellarTech — ✅ PASS

Assertion: Bob Kauffman must have exactly one organization membership — StellarTech — so visiting the foreign-owned account cannot succeed via a second membership

SELECT ur.organization_id, o.name
      FROM user_roles ur
      JOIN organizations o ON o.id = ur.organization_id
      WHERE ur.user_id = $1

organization_id	name
b2c3d4e5-f6a7-8901-bcde-f12345678901	StellarTech Medical Solutions

Foreign distributor organization exists — ✅ PASS

Assertion: The ephemeral foreign organization inserted by setup must exist and be distinct from StellarTech, providing the target for the cross-org isolation proof

SELECT id, name, active FROM organizations WHERE id = $1

id	name	active
f0f0f0f0-0008-4f00-af00-000000000008	Acme Distribution Partners (URS-008 Fixture)	true

Foreign sales account owned entirely by foreign org — ✅ PASS

Assertion: The foreign sales account must set organization_id, distributor_organization_id, and manufacturer_organization_id all to the foreign org — no StellarTech linkage exists on any scoping column

SELECT id, name, status,
        organization_id,
        distributor_organization_id,
        manufacturer_organization_id
      FROM sales_accounts
      WHERE id = $1

id	name	status	organization_id	distributor_organization_id	manufacturer_organization_id
f0f0f0f0-0008-4f00-acc0-000000000008	Acme Diagnostics Center	active	f0f0f0f0-0008-4f00-af00-000000000008	f0f0f0f0-0008-4f00-af00-000000000008	f0f0f0f0-0008-4f00-af00-000000000008

Rep has no assignment to foreign sales account — ✅ PASS

Assertion: Bob Kauffman must not have any assignment row — active or inactive — linking him to the foreign-owned sales account

SELECT id, active, representative_type, organization_id
      FROM sales_account_user_assignments
      WHERE user_id = $1 AND sales_account_id = $2

No rows returned

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: Rep login	user_log:user:login	✅
Step 5: Admin also blocked — org-scoped, not role-scoped	user_log:user:login	✅

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:35:27.651Z

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

5 event(s) captured:

Time	Type	Action	User	Org	Object ID	Performed	Reason
2026-04-23 03:35:35Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—	—
2026-04-23 03:35:40Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—	—
2026-04-23 03:35:48Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—	—
2026-04-23 03:35:57Z	user_log	user:login	bob.kauffman@stellartech.com	StellarTech Medical Solutions	—	—
2026-04-23 03:36:08Z	user_log	user:login	dan.distributor@stellartech.com	StellarTech Medical Solutions	—	—

Downloads

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

Feedback