Rhythm 2.0 Specifications

Appearance

ATS-CRM-DQ-019Inspect merge outcomes and attribution: Acceptance Scenarios

Markdown

ATS-CRM-DQ-019

Inspect merge outcomes and attribution: Acceptance Scenarios

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-019

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Test Scenarios

7 scenarios proving CAP-CRM-DQ-019; 7 bound to an existing test.

01 Workspace history filters retain paging orderapitest
Proves
BR-CAP-CRM-DQ-019-01
Preconditions
Prepare both record types, several requesters and a failed attempt.
Steps
List defaults, all statuses and each filter, then page.
Expected
Default results contain successes, requested status and filters narrow correctly and pages preserve order.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/integration/services/merges/tenant-merge-history.integration.spec.js#answers the merges that succeeded, which is what a history screen asks for by default
services-crm:modules/merges/tests/integration/services/merges/tenant-merge-history.integration.spec.js#answers the merges one person asked for in a span, the filters narrowing together
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#refuses a page larger than the list will answer, rather than reading the whole history
Source
services-crm:modules/merges/tests/integration/services/merges/tenant-merge-history.integration.spec.js#answers the merges that succeeded, which is what a history screen asks for by default
02 Absorbed and surviving identities share lineageapitest
Proves
BR-CAP-CRM-DQ-019-02
Preconditions
A merge has succeeded.
Steps
Request history through survivor and absorbed identity.
Expected
Both return the survivor's same history.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#answers the merge in the survivor’s history
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#answers the same history when asked under an id the merge took away, under the survivor
Source
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#answers the merge in the survivor’s history
03 Historical identity remains readable after absorptionapitest
Proves
BR-CAP-CRM-DQ-019-03
Preconditions
Prepare deleted participants and visible or unavailable requesters.
Steps
List their merges.
Expected
Participant names come from originals and requester names are current or blank.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#names the survivor and the records it took away, so a history list needs no further read
services-crm:modules/merges/tests/integration/services/merges/tenant-merge-history.integration.spec.js#is the name Platform knows the requester by now, never the id a screen cannot read
services-crm:modules/merges/tests/integration/services/merges/tenant-merge-history.integration.spec.js#is nothing at all for a requester the view does not answer for, rather than their id
Source
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#names the survivor and the records it took away, so a history list needs no further read
04 Outcome details preserve decisions and gap fillsapitest
Proves
BR-CAP-CRM-DQ-019-04
Preconditions
A completed merge includes a reviewer choice and an automatic fill.
Steps
Inspect its details.
Expected
The choice retains author and source, the fill retains its source and originals accompany the stored outcome.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/integration/services/merges/merge-outcome.integration.spec.js#keeps the reviewer’s choice with what it was, who made it, and the record it was taken from
services-crm:modules/merges/tests/integration/services/merges/merge-outcome.integration.spec.js#says which record a value was filled in from, where the survivor had none
services-crm:modules/merges/tests/integration/services/merges/merge-outcome.integration.spec.js#keeps the absorbed record’s original values beside the outcome
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#answers the evidence of what it did on the details route, which the summary leaves out
Source
services-crm:modules/merges/tests/integration/services/merges/merge-outcome.integration.spec.js#keeps the reviewer’s choice with what it was, who made it, and the record it was taken from
05 Permanent outcomes cannot be erased or relocatedapinegativetest
Proves
BR-CAP-CRM-DQ-019-05
Preconditions
Prepare a merge record.
Steps
As the application, delete, truncate or move it between workspaces.
Expected
Every attempted mutation is refused.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/integration/db/record-merges.table.integration.spec.js#may not erase a merge, which holds the only copy left of the records it deleted
services-crm:modules/merges/tests/integration/db/record-merges.table.integration.spec.js#may not truncate the table, which would erase every tenant’s merges at once
services-crm:modules/merges/tests/integration/db/record-merges.table.integration.spec.js#may not move a merge into another tenant, the policy refusing the statement
Source
services-crm:modules/merges/tests/integration/db/record-merges.table.integration.spec.js#may not erase a merge, which holds the only copy left of the records it deleted
06 Record readers receive appropriately restricted lineageapinegativetest
Proves
BR-CAP-CRM-DQ-019-07 BR-CAP-CRM-DQ-019-08
Preconditions
Prepare a contact reader without merge management and an organization-only reader.
Steps
Read a contact's history and one outcome.
Expected
The contact reader sees history and field outcomes without login actions, carried decisions or checks; the other reader is denied.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/e2e/merged-from-history.e2e.spec.js#answers the reader the survivor’s merged-from history, naming the merge and the record it absorbed
services-crm:modules/merges/tests/e2e/merged-from-history.e2e.spec.js#answers the reader the merge’s outcome and the absorbed record as it was
services-crm:modules/merges/tests/integration/services/merges/merged-from-history.integration.spec.js#leaves what only merge management reads out of a reader’s details
services-crm:modules/merges/tests/e2e/merged-from-history.e2e.spec.js#refuses a reader of organizations a contact’s merged-from history
Source
services-crm:modules/merges/tests/e2e/merged-from-history.e2e.spec.js#answers the reader the survivor’s merged-from history, naming the merge and the record it absorbed
07 Console history connects summaries and outcomesbrowsertest
Proves
BR-CAP-CRM-DQ-019-09
Preconditions
Prepare several completed merges.
Steps
Filter Recently Merged, open details and follow a record history entry.
Expected
Attribution and participants accompany retained, moved and discarded values, and history links open their merge.
Data
The existing scenario setup supplies the required records.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/merging/CRM-ACC-0266.spec.ts#CRM-ACC-0266

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