Rhythm 2.0 Specifications

Appearance

CAP-COM-ORD-011Protect orders and carts by workspace and authority

Markdown

CAP-COM-ORD-011

Protect orders and carts by workspace and authority

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

Planning

Feature
FEAT-COM-ORD-03
Exercised by
FAS-COM-ORD-01-04, FAS-COM-ORD-02-04, FAS-COM-ORD-03-01, FAS-COM-ORD-03-02, FAS-COM-ORD-03-03, FAS-COM-ORD-03-04, FAS-COM-ORD-03-05, FAS-COM-ORD-04-04, FAS-COM-ORD-05-04, JNY-COM-ORD-003
Key concepts
CON-COM-ORD-001, CON-COM-ORD-002
Actors
ACT-COM-014, ACT-COM-015, ACT-COM-016, ACT-COM-017
Related
CAP-COM-ORD-001, CAP-COM-ORD-005, CAP-COM-ORD-007, CAP-COM-ORD-010
Proved by
ATS-COM-ORD-011

Implementation

Executable suites
TST-COM-ORD-025, TST-COM-ORD-040, TST-COM-ORD-048, TST-COM-ORD-104, TST-COM-ORD-155

KindCapabilityProduct areaCommerceModuleCustomer purchases, purchased benefits and vendor stockRevision1

Read atservices-commerce c8b66a98react-console baf6dae3

Protect orders and carts by workspace and authority ​

Purpose ​

Commerce keeps each customer’s records within its workspace and respects the caller’s purchasing authority. Audit attribution distinguishes staff, buyers and system work.

How It Works ​

Commerce identifies the caller and workspace before it reads purchase records. Staff permission controls determine whether an operation can proceed. Portal purchasing also depends on the linked contact and the parties named by the record. A refusal leaves the caller without authority to make the attempted change. Support actions remain attributed to the support identity. Background processing discovers eligible work across workspaces and enters each owning workspace before changing it.

Relationships ​

Cart construction, placement, payment and order inspection all use the workspace and party boundaries; system processing uses the same owning records.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
A separate workspace cannot obtain these purchase records.Read-only staff cannot change, price, place or pay an order.
Surfaces
consoleportalapi
Intent sources
services-commerce:docs/milestones/COMM-M2-take-a-staff-order.md#M2-S2services-commerce:docs/milestones/plans/COMM-M2-plan.md#9. Acceptance scenarios

Controls

35 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-CRY-001 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
commerce.application.accessapitenant
commerce.checkouts.readapitenant
commerce.checkouts.createapitenant
commerce.checkouts.updateapitenant
commerce.orders.readapitenant
commerce.orders.createapitenant
commerce.orders.tenderapitenant
commerce.orders.voidapitenant
commerce.checkouts.deleteapitenant
commerce.checkouts.bulkapitenant
commerce.orders.updateapitenant
commerce.orders.deleteapitenant
commerce.orders.bulkapitenant

Business Rules

8 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 8 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Requests require security context and workspace authority, and a record from another workspace remains not found even for a principal authorized in both.
origin: services-commerce:docs/milestones/plans/COMM-M2-plan.md#9. Acceptance scenarios
proved by ATS-COM-ORD-001-19, ATS-COM-ORD-001-20, ATS-COM-ORD-011-01, TST-COM-ORD-025
permissionapi, databasetest
services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#answers 404 in tenant B to a checkout and an order of tenant A, to a context that covers both
02must prove
Confirmed
Read authority permits cart and order reads and buyer lists but rejects mutations without changing the cart.
origin: services-commerce:docs/milestones/plans/COMM-M2-plan.md#9. Acceptance scenarios
proved by ATS-COM-ORD-001-18, ATS-COM-ORD-011-02, ATS-COM-ORD-011-07, ATS-COM-ORD-011-08, TST-COM-ORD-025
permissionapitest
services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader is refused every write, 403 permission_missing, leaving the checkout as it was
03must prove
Confirmed
Portal callers can act only where their linked contact is the buyer or acting contact, and attempts to reach another party’s carts, orders or lists are refused.
proved by ATS-COM-ORD-010-10, ATS-COM-ORD-011-03, ATS-COM-ORD-011-09, ATS-COM-ORD-011-10, TST-COM-ORD-025
permissionservicetest
services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused another member’s checkout and order, 403 not_your_party, and a change of it
04must prove
Confirmed
The portal purchasing contact comes from the Platform user link, and purchasing is unavailable without that linked contact.
no proof recorded yet
permissionservicedocumented
services-commerce:docs/migrations/order-domain/README.md#D16. A portal caller's contact comes from Platform's user directory
05must prove
Confirmed
Rhythm support can administer customer carts under its acting identity, which is retained on events and record stamps.
origin: services-commerce:docs/milestones/COMM-M2-take-a-staff-order.md#M2-S2
proved by ATS-COM-ORD-011-04, TST-COM-ORD-048
permissionservice, databasetest
services-commerce:modules/checkout/tests/unit/checkout/checkout-event-actor.spec.js#names the support identity in the record system columns
06must prove
Confirmed
An operation permission is insufficient without access to the Commerce application itself.
proved by ATS-COM-ORD-011-05, TST-COM-ORD-155
permissionapitest
services-commerce:modules/purchasing/tests/e2e/purchasing.e2e.spec.js#lets a reader list and read, refuses the reader every write 403 permission_missing, a denied principal 403 app_not_permitted, no context 401, and another tenant 404
07must prove
Confirmed
Sweeps discover records using a limited cross-workspace read policy and perform each mutation under the owning workspace’s context.
proved by ATS-COM-ORD-011-06, TST-COM-ORD-040, TST-COM-ORD-104
invariantdatabase, servicetest
services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#lists, across tenants, every placed order past its window as references, oldest window first, under the sweep policy alone
08
Confirmed
Checkout and order permission catalogues include unused deletion, bulk and order-update permissions without corresponding operations.
permissionapiobserved
services-commerce:aws/commerce.service.ts:OrdersPermissions

Scenarios

IdGivenWhenThenProvenance
01An administrator from a different customer knows a purchase identifier.They attempt to read, pay or void it through their own workspace.The attempted cross-workspace access is refused.unknown
FND-COM-ORD-032

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software