Rhythm 2.0 Specifications

Appearance

ATS-CRM-ENT-016Inspect a record’s changes over time

Markdown

ATS-CRM-ENT-016

Inspect a record’s changes over time

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-ENT-016

Design

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

KindAcceptance test setProduct areaCRMModuleEntitiesRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Inspect a record’s changes over time ​

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-016-01ATS-CRM-ENT-016-01, ATS-CRM-ENT-016-07, ATS-CRM-ENT-016-08, ATS-CRM-ENT-016-10
BR-CAP-CRM-ENT-016-02ATS-CRM-ENT-016-02, ATS-CRM-ENT-016-09, ATS-CRM-ENT-016-11
BR-CAP-CRM-ENT-016-03ATS-CRM-ENT-016-03
BR-CAP-CRM-ENT-016-07ATS-CRM-ENT-016-04

The interaction scenarios exercise save corrections without overwriting another change; set records aside and restore them; remove records and their owned information; control record locks and system protection. 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 not-applicable
  • Validation gap: FND-CRM-ENT-064
  • Permission covered
  • Edge gap: FND-CRM-ENT-064
  • Failure covered
  • Boundary gap: FND-CRM-ENT-064
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-CRM-ENT-016; 5 bound to an existing test.

01 One revision per committed save, none for a no-opinvariantapitest
Proves
BR-CAP-CRM-ENT-016-01 INV-DOM-CRM-ENT-033-08
Preconditions
Prepare a contact.
Steps
Save it touching several collections; save it unmodified.
Expected
Exactly one revision labelled with the name; then none.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.history.integration.spec.js#writes exactly one revision, whatever the save touched
02 the history key and reachpermissionapinegativetest
Proves
BR-CAP-CRM-ENT-016-02
Preconditions
Prepare a contact and an organization, one later deleted.
Steps
Read history without the key; with key and read; with key but no read; of the deleted one.
Expected
403; 200; 404; 200 marked deleted.
Data
Use personas by key.
Bound to
Source
services-crm:modules/entities/tests/e2e/organizations-history.e2e.spec.js#answers a caller with the history key but no read of organizations 404, as the organization itself would
03 Timeline paging and filtersconcurrencyapinegativetest
Proves
BR-CAP-CRM-ENT-016-03
Preconditions
Prepare a contact with several revisions.
Steps
Page while it changes; filter; send an unknown parameter; ask for 101.
Expected
Stable cursor; filtered; 400; 400.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-history.e2e.spec.js#refuses a query parameter it does not know, rather than ignoring the filter
04 Revisions cannot be forged and outlive the recordinvariantapinegativetest
Proves
BR-CAP-CRM-ENT-016-07 INV-DOM-CRM-ENT-033-09
Preconditions
No additional setup is required.
Steps
Insert a revision as the application; delete a contact; read across tenants.
Expected
Rejected; its revision preserved; another workspace’s hidden.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/db/record-revisions.table.integration.spec.js#may not insert a revision, so nothing the application runs can forge one
05 Sections, labels and names are presented as the console displays themruleapitest
Proves
BR-CAP-CRM-ENT-016-04 BR-CAP-CRM-ENT-016-05
Preconditions
Prepare a contact with roles, an affiliation and custom values changed by a since-renamed user.
Steps
Open the revisions.
Expected
Sections and labels as configured, the role and affiliation named, the user by today's name.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-history.e2e.spec.js#shows the role removed and the role added, each under the name it has now
06 Roll back a change lacking revision attributionfailureapinegativeproposed
Proves
BR-CAP-CRM-ENT-016-08 INV-DOM-CRM-ENT-033-10
Preconditions
A run-owned person is visible before a direct database transaction.
Steps
Attempt a changed write without the required actor and source context; inspect the person and its revision count afterward.
Expected
The transaction fails and neither the attempted value nor a revision survives.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:docs/record-history.md#Fail closed, and the maintenance helper
07 Review a correction and its unchanged retryinteractionapiproposed
Proves
BR-CAP-CRM-ENT-004-02 BR-CAP-CRM-ENT-016-01
Preconditions
A person with several contact points has a known revision count.
Steps
Save corrections to multiple sections; read the timeline; save the returned record unchanged and reread the timeline.
Expected
The changed save contributes one aggregate revision and the unchanged save contributes none.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/record-saves.no-op.integration.spec.js#writes no revision; services-crm:modules/entities/tests/integration/services/persistence/contacts.history.integration.spec.js#writes exactly one revision, whatever the save touched
08 Archive and restoration remain inspectableinteractionapiproposed
Proves
BR-CAP-CRM-ENT-013-03 BR-CAP-CRM-ENT-016-01
Preconditions
A live person has readable history.
Steps
Archive it with a reason, restore it with a reason and open both revisions.
Expected
History identifies both lifecycle changes while the restored person keeps its identity and collections.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.archive.integration.spec.js#keeps the status it had: archive is not a status; services-crm:modules/entities/tests/integration/services/persistence/contacts.history.integration.spec.js#writes exactly one revision, whatever the save touched
09 Deleted-record history survives the ordinary recordinteractionapiproposed
Proves
BR-CAP-CRM-ENT-014-02 BR-CAP-CRM-ENT-016-02
Preconditions
A person has saved revisions and an authorized history reader.
Steps
Delete the person; read its ordinary record and its timeline.
Expected
The ordinary read is not found while history remains readable and identifies the deleted subject.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.integration.spec.js#removes every owned element with it, the foreign keys cascading; services-crm:modules/entities/tests/e2e/organizations-history.e2e.spec.js#answers a caller with the history key but no read of organizations 404, as the organization itself would
10 Lock changes appear in audit and aggregate historyinteractionapiproposed
Proves
BR-CAP-CRM-ENT-015-03 BR-CAP-CRM-ENT-016-01
Preconditions
A live person has no lock and both histories are readable.
Steps
Apply a delete lock with a reason and read lock audit and record history.
Expected
Both reads identify the lock change without creating multiple aggregate revisions.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/persistence/record-locks.queries.integration.spec.js#answers the newest two changes of the record, every property mapped, and where the page ended; services-crm:modules/entities/tests/integration/services/persistence/contacts.history.integration.spec.js#writes exactly one revision, whatever the save touched
11 Exercise every declared authority independentlypermissionapinegativeproposed
Proves
BR-CAP-CRM-ENT-016-02
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