Rhythm 2.0 Specifications

Appearance

ATS-PFM-SEC-001Establish and administer a customer: Capability Test Specification

Markdown

ATS-PFM-SEC-001

Establish and administer a customer: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-SEC-001

Design

Executed by
TST-PFM-SEC-041, TST-PFM-SEC-042, TST-PFM-SEC-043, TST-PFM-SEC-044, TST-PFM-SEC-191

KindAcceptance test setProduct areaPlatformModuleSecurity, Customers and WorkspacesRevision3ExaminercodexExamined on2026-10-23

Read atservices-platform ad3f6a65react-console baf6dae3

Establish and administer a customer: Capability Test Specification ​

Coverage ​

Required ruleScenario or finding
BR-CAP-PFM-SEC-001-01ATS-PFM-SEC-001-01
BR-CAP-PFM-SEC-001-02ATS-PFM-SEC-001-02, ATS-PFM-SEC-001-13
BR-CAP-PFM-SEC-001-03ATS-PFM-SEC-001-03
BR-CAP-PFM-SEC-001-04ATS-PFM-SEC-001-04
BR-CAP-PFM-SEC-001-05ATS-PFM-SEC-001-05
BR-CAP-PFM-SEC-001-06ATS-PFM-SEC-001-06
BR-CAP-PFM-SEC-001-07ATS-PFM-SEC-001-07
BR-CAP-PFM-SEC-001-08ATS-PFM-SEC-001-08
BR-CAP-PFM-SEC-001-10ATS-PFM-SEC-001-09
BR-CAP-PFM-SEC-001-11ATS-PFM-SEC-001-10, ATS-PFM-SEC-001-12
BR-CAP-PFM-SEC-001-12ATS-PFM-SEC-001-11, ATS-PFM-SEC-001-14
BR-CAP-PFM-SEC-001-13no scenario: FND-PFM-SEC-58

The category map records specified proof. A covered category can contain proposed scenarios; it does not mean the checks have run. The bindings identify individual executable contributions, while findings retain missing rules, permissions, transitions and assertions.

The interaction scenarios connect this capability to the related actions and workflow handoffs named in their proof references. Each case observes the outcome after the connected action changes records or available authority. A collection of separately bound checks does not establish an ordered feature journey.

Source revisions and assertion references are recorded in frontmatter. Steps and expected observations carry separate evidence annotations. Proposed checks remain distinct from executable test statements, and static review supplies no run result.

Coverage

  • Rule gap: FND-PFM-SEC-058
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge gap: FND-PFM-SEC-058
  • Failure gap: FND-PFM-SEC-058
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

14 scenarios proving CAP-PFM-SEC-001; 10 bound to an existing test.

01 Customer-level authority cannot create a customerpermissionapinegativetest
Proves
BR-CAP-PFM-SEC-001-01
Preconditions
A customer administrator and staff callers with customer-create authority are available.
Steps
Attempt creation under customer-scoped authority and under permitted staff authority.
Expected
Customer-scoped creation returns forbidden while authorized staff creation succeeds; deletion separation is established by route evidence and still needs a dedicated refusal test.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer-scoped caller the system route that creates a customer
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#refuses a create from an administrator of a customer as 403
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer-scoped caller the system route that creates a customer
02 Customer references require valid normalized unique valuesvalidationapinegativetest
Proves
BR-CAP-PFM-SEC-001-02 INV-DOM-PFM-SEC-001-01
Preconditions
A customer reference is already assigned.
Steps
Request creation without a reference, with a generated-identifier shape, with a reserved reference and with taken references in plain and padded uppercase forms.
Expected
Invalid choices receive their required, invalid or reserved refusal; both spellings of an assigned reference receive the taken refusal.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a body that names no id as 400 customer_id_required, nothing generating one
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a UUID-shaped id as 400 customer_id_invalid
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a reserved id as 400 customer_id_reserved
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#reads a padded id in capitals as the id it normalizes to, and so finds it taken
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a body that names no id as 400 customer_id_required, nothing generating one
03 Customer classification is required and closedvalidationunitnegativetest
Proves
BR-CAP-PFM-SEC-001-03 INV-DOM-PFM-SEC-001-02
Preconditions
Database fixtures can attempt direct customer inserts.
Steps
Insert an unsupported classification and a row without classification.
Expected
The database rejects both inserts through the closed classification and required-column constraints.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/integration/db/customers.table.integration.spec.js#refuses a type outside the closed list by customers_type_check
Source
services-platform:modules/customers/tests/integration/db/customers.table.integration.spec.js#refuses a type outside the closed list by customers_type_check
04 Address normalization and refusal protect customer recordsvalidationapitest
Proves
BR-CAP-PFM-SEC-001-04 INV-DOM-PFM-SEC-001-03
Preconditions
An editable customer and address inputs are available.
Steps
Save mixed-case and blank addresses, then submit an invalid address.
Expected
Valid addresses are normalized, blank input leaves no address, and invalid input is rejected without an accepted write.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses an invalid e-mail address as 400 naming emailAddress
Source
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#stores an address in its canonical form on create
05 Customer reads stay within the administrator’s boundaryboundaryapinegativetest
Proves
BR-CAP-PFM-SEC-001-05
Preconditions
Two customers exist and the caller administers one.
Steps
Read the customer list and request the unrelated customer.
Expected
The list contains only the authorized customer and the unrelated read returns not found.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#reduces the list to the caller's own customer when the caller is not staff
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#answers a customer-scoped caller 404 for another customer's record, so the route cannot be walked
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#reduces the list to the caller's own customer when the caller is not staff
06 Stale replacement preserves the newer customerconcurrencyapinegativetest
Proves
BR-CAP-PFM-SEC-001-06 INV-DOM-PFM-SEC-001-06
Preconditions
The customer has changed since the caller read its version.
Steps
Submit a replacement using that earlier version.
Expected
A stale-object conflict is returned and the newer stored record remains unchanged.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#leaves the row at the version it reached when it refuses a stale version
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a stale version as 409
07 Proposed replacement proof reads the current commercial fieldruleapiproposed
Proves
BR-CAP-PFM-SEC-001-07
Preconditions
The customer has a populated commercial reference.
Steps
Replace the customer while omitting that reference, then read the persisted current field.
Expected
The proposed proof must establish that the current field is absent; checking only a retired property name proves nothing about it.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Source
FND-PFM-SEC-032
08 Customer locks prevent the corresponding mutationinvariantapinegativetest
Proves
BR-CAP-PFM-SEC-001-08 INV-DOM-PFM-SEC-001-05
Preconditions
Separate customer fixtures carry update and deletion locks.
Steps
Attempt the mutation restricted by each lock and read the customer afterward.
Expected
The service reports an illegal operation and the customer retains its prior stored state.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
Source
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#refuses a record locked against updates as IllegalOperation
09 HQ edits preserve their defined field boundaryvalidationapitest
Proves
BR-CAP-PFM-SEC-001-10
Preconditions
A customer and a staff caller permitted to update it are available.
Steps
Edit the four supported fields, omit one, explicitly clear a nullable one and submit an unsupported field.
Expected
Supported changes persist, omission preserves the value, clearing removes it, and the unsupported field receives an invalid-request response.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#edits the four HQ fields and answers the customer as the detail read answers it
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#leaves a field the body does not name exactly as it was
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#refuses a body naming a field the HQ screen does not edit as 400
Source
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#edits the four HQ fields and answers the customer as the detail read answers it
10 Workspace dependencies block customer removalinvariantapinegativetest
Proves
BR-CAP-PFM-SEC-001-11 INV-DOM-PFM-SEC-001-04
Preconditions
At least one workspace still references the customer.
Steps
Request customer deletion and read the customer afterward.
Expected
The request returns a dependency conflict and the customer remains readable.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer that still has tenants as 409
services-platform:modules/customers/tests/integration/db/customers.table.integration.spec.js#refuses deleting a customer that tenants still reference by tenants_customer_fk
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer that still has tenants as 409
11 Customer removal also removes standing staff grantstransitionapitest
Proves
BR-CAP-PFM-SEC-001-12 INV-DOM-PFM-SEC-001-07
Preconditions
The customer has no workspaces and a Rhythm Administrator has a standing grant to it.
Steps
Delete the customer through the path that removes standing access.
Expected
The transaction removes the customer and its standing grants, then submits a flush request; gateway eviction is outside what this test establishes.
Data
Use the fixtures described by the cited test or the proposed scenario setup.
Bound to
services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#submits one authorizer-cache flush naming the customer once the deletion has committed, so no cached answer outlives the grants
Source
services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#deletes the customer
12 Establish and administer a customer with maintain workspace information and operating statusinteractionapinegativeproposed
Proves
BR-CAP-PFM-SEC-001-11 BR-CAP-PFM-SEC-002-01
Preconditions
A customer has one active workspace.
Steps
Try deleting the customer, then read the workspace and customer.
Expected
Deletion is refused and both records retain their identities.
Data
An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run.
Source
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer that still has tenants as 409,services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#lists no tenant of another customer, which is what the reach reduction means
13 Establish and administer a customer with prepare a workspace for customer useinteractionapiproposed
Proves
BR-CAP-PFM-SEC-001-02 BR-CAP-PFM-SEC-003-03
Preconditions
A chosen customer and workspace identifier are unused.
Steps
Submit setup with a new customer, replay it, then try another submission with the same workspace identifier.
Expected
Replay returns the original customer, workspace and job; the competing submission creates none.
Data
An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run.
Source
services-platform:modules/customers/services/persistence/customers.ts:requireCustomerId,services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#answers the same tenant and the same job when the same submission is sent twice
14 Establish and administer a customer with control staff access to customer workspacesinteractionapiproposed
Proves
BR-CAP-PFM-SEC-001-12 BR-CAP-PFM-SEC-017-08
Preconditions
A customer without workspaces has a standing staff grant.
Steps
Delete the customer and inspect retained staff-access records.
Expected
The customer and its standing grant are removed together; no usable assignment reaches the removed customer.
Data
An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run.
Source
services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#deletes the customer,services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#gives each Rhythm Administrator one active customer-level standing grant in every customer but Rhythm’s own

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