Rhythm 2.0 Specifications

Appearance

ATS-CRM-ENT-008Keep workspace’s-defined information with records

Markdown

ATS-CRM-ENT-008

Keep workspace’s-defined information with records

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-ENT-008

Design

Executed by
TST-CRM-ENT-775, TST-CRM-ENT-786

KindAcceptance test setProduct areaCRMModuleEntitiesRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Keep workspace’s-defined information with records ​

Coverage ​

The category map separates specified cases from recorded gaps. A proposed case describes proof to implement; a binding identifies the assertions supplied by an existing executable file. The permission and transition ledgers record the individual checks needed for the capability.

Required ruleScenario or finding
BR-CAP-CRM-ENT-008-01ATS-CRM-ENT-008-01
BR-CAP-CRM-ENT-008-02ATS-CRM-ENT-008-02
BR-CAP-CRM-ENT-008-03ATS-CRM-ENT-008-03, ATS-CRM-ENT-008-06, ATS-CRM-ENT-008-09, ATS-CRM-ENT-008-10
BR-CAP-CRM-ENT-008-04ATS-CRM-ENT-008-04, ATS-CRM-ENT-008-08
BR-CAP-CRM-ENT-008-06ATS-CRM-ENT-008-05

The interaction scenarios exercise establish a person’s CRM record; establish an organization and its hierarchy; save corrections without overwriting another change. They change one part of a prepared record and inspect the dependent outcome. Unbound interactions remain proposed rather than implying an existing end-to-end implementation.

Source Evidence ​

The frontmatter pins the repositories and identifies the source anchors for each scenario. Bindings record inspected assertions, while unbound cases remain proposed. Source inspection supplies no execution result or product approval.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-CRM-ENT-056
  • Invariant gap: FND-CRM-ENT-056
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-CRM-ENT-008; 7 bound to an existing test.

01 Only named keys changeedgeapinegativetest
Proves
BR-CAP-CRM-ENT-008-01
Preconditions
Prepare a contact with several custom values.
Steps
Replace with the map omitted, empty, and naming one key set, one null and one empty selection; patch removing the map; send custom_fields null.
Expected
Unmodified; unmodified; exactly those keys; rejected; rejected.
Data
Use two custom fields.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#sets the key it sends, clears the key sent null and the selection sent empty, and leaves the others
02 Unknown, foreign and archived fields are rejectedboundaryapinegativetest
Proves
BR-CAP-CRM-ENT-008-02 INV-DOM-CRM-ENT-001-12
Preconditions
Prepare two tenants with their own fields, one archived.
Steps
Write an unknown key, the other workspace’s key, a contact key on an organization, the archived field.
Expected
400 at each path.
Data
Use two tenants.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#refuses a write to an archived field
03 Values are converted or rejected by typevalidationapinegativetest
Proves
BR-CAP-CRM-ENT-008-03
Preconditions
Prepare one field of every type.
Steps
Send digits for a number, "false", "yes", an over-long text, an archived option, a date-time without offset, a missing reference, an inexact percentage.
Expected
Converted; converted; rejected each other case.
Data
Use fields of every type.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#refuses yes for a yes/no field: no truthiness
04 Required fields on create, never emptied, old records saveabletransitionbrowsernegativetest
Proves
BR-CAP-CRM-ENT-008-04
Preconditions
Prepare a field made API-required after a record existed.
Steps
Create without it; create blank; replace the old record without it; replace sending null; patch removing it.
Expected
Rejected; rejected; saved; rejected; rejected.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#saves a replace of a contact created before the field was required, leaving the field out
05 No custom fields on rolesvalidationapinegativetest
Proves
BR-CAP-CRM-ENT-008-06 INV-DOM-CRM-ENT-003-15
Preconditions
No additional setup is required.
Steps
Create, replace and patch a contact role carrying custom_fields.
Expected
400 each.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contact-roles.e2e.spec.js#refuses a create that carries custom_fields, as an unknown property
06 Refuse an invalid custom value with the standard correctionfailureapinegativetest
Proves
BR-CAP-CRM-ENT-008-03 BR-CAP-CRM-ENT-004-07
Preconditions
A person has a valid numeric custom value and saved notes.
Steps
Submit an invalid numeric value together with changed notes, then read the person.
Expected
The request is refused; the notes and custom value keep their previous contents.
Data
Run-owned records and configuration in an isolated workspace.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#refuses a replacement with an invalid custom value as a whole, its standard change included
07 Read custom values only through the declared mapruleapitest
Proves
BR-CAP-CRM-ENT-008-05
Preconditions
A person has a readable populated custom field and a readable empty field.
Steps
Read the person and inspect the map and top-level properties.
Expected
The populated and empty values use the declared JSON forms in the map; neither appears as a top-level custom property.
Data
Run-owned records and configuration in an isolated workspace.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#puts no custom field at the top level of the record
08 Create with a required customer valueinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-01 BR-CAP-CRM-ENT-008-04
Preconditions
An active contact definition requires a value during creation.
Steps
Create without that value, then create with a valid value and read the resulting person.
Expected
The first attempt creates no person; the corrected attempt stores the person and its custom value together.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#answers 400 for a contact with neither a first nor a last name, naming the rule; services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#saves a replace of a contact created before the field was required, leaving the field out
09 Refuse an invalid organization custom valueinteractionapiproposed
Proves
BR-CAP-CRM-ENT-002-01 BR-CAP-CRM-ENT-008-03
Preconditions
An organization definition has a numeric custom field.
Steps
Create a named organization with invalid numeric text, then correct the value and retry with a fresh unused identity.
Expected
The invalid request creates no organization; the corrected request stores the declared numeric value.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/organizations.field-rules.integration.spec.js#refuses a name of 201 characters, naming name; services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#refuses yes for a yes/no field: no truthiness
10 Keep all values after a mixed correction failsinteractionapiproposed
Proves
BR-CAP-CRM-ENT-004-07 BR-CAP-CRM-ENT-008-03
Preconditions
A person has saved notes and a valid custom number.
Steps
Change the notes while submitting an invalid custom number in the same save.
Expected
Neither proposed change survives the refusal.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.integration.spec.js#rolls back the contact row the transaction had already updated; services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#refuses yes for a yes/no field: no truthiness
11 Exercise every declared authority independentlypermissionapinegativeproposed
Proves
BR-CAP-CRM-ENT-003-07 BR-CAP-CRM-ENT-003-09
Preconditions
An eligible record and configuration fixture exist for each operation; the caller can reach only the run’s workspace.
Steps
For each declared permission, execute its matching operation with that permission, then without it while retaining the other required grants. Read affected records after every refused mutation.
Expected
The authorized case reaches the operation; the missing-grant case is refused and preserves saved data. Record access alone does not authorize the other declared actions.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:aws/crm.service.ts:ApplicationPermissions; services-crm:modules/entities/aws/api/entities.routes.ts

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