Rhythm 2.0 Specifications

Appearance

ATS-CRM-DQ-009Record a duplicate that matching missed: Capability Test Specification

Markdown

ATS-CRM-DQ-009

Record a duplicate that matching missed: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-009

Design

Executed by
TST-CRM-DQ-180, TST-CRM-DQ-182

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Record a duplicate that matching missed: Capability Test Specification ​

Coverage ​

The rule matrix names the authored checks. A covered category means that a scenario exists; it does not report a passing execution. The coverage notes and findings identify missing checks, while execution sources retain the exact assertions inspected.

Required RuleScenarios
BR-CAP-CRM-DQ-009-01ATS-CRM-DQ-009-01, ATS-CRM-DQ-009-07, ATS-CRM-DQ-009-09
BR-CAP-CRM-DQ-009-02ATS-CRM-DQ-009-02, ATS-CRM-DQ-009-05, ATS-CRM-DQ-009-06, ATS-CRM-DQ-009-09
BR-CAP-CRM-DQ-009-03ATS-CRM-DQ-009-03, ATS-CRM-DQ-009-09
BR-CAP-CRM-DQ-009-04ATS-CRM-DQ-009-04, ATS-CRM-DQ-009-09
BR-CAP-CRM-DQ-009-06ATS-CRM-DQ-009-08, ATS-CRM-DQ-009-09

Confirm an open pair and a dismissed pair, read their groups, then prepare the confirmed records for a merge.

These sequences test the handoffs named in the interaction coverage record. A proposed sequence remains unbound until an executable run checks its combined outcome; component assertions alone leave that obligation open.

Coverage

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

Test Scenarios

9 scenarios proving CAP-CRM-DQ-009; 4 bound to an existing test.

01 Manual confirmation creates a full-score decisionruleapitest
Proves
BR-CAP-CRM-DQ-009-01
Preconditions
Two existing records have no candidate.
Steps
Confirm their shared identity with a note.
Expected
The result is manual and confirmed at 100 with the reviewer and note in its reason.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#is confirmed, manual and at full score: certainty, not a computation
02 Confirmation replaces an earlier dismissal in placetransitionapitest
Proves
BR-CAP-CRM-DQ-009-02
Preconditions
An existing pair is dismissed.
Steps
Manually confirm it.
Expected
The same identity becomes confirmed at full score, removes dismissal and retains the human reason.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#is the same candidate, confirmed in place
03 Confirmation rejects invalid participantsvalidationapinegativetest
Proves
BR-CAP-CRM-DQ-009-03
Preconditions
Prepare one record and an unavailable identity.
Steps
Submit one participant, repeated participants and an absent participant.
Expected
Invalid cardinality is rejected and unavailable records return not found.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#refuses a manual pair that does not name two records (400)
04 Readers cannot confirm duplicatespermissionapinegativetest
Proves
BR-CAP-CRM-DQ-009-04
Preconditions
Use a duplicate reader without review authority.
Steps
Submit manual confirmation.
Expected
The request is refused.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#answers 403 to that reader saying two records are the same
05 Observe open becoming confirmed after a reviewer confirms an existing open comparisontransitionapiproposed
Proves
BR-CAP-CRM-DQ-009-02
Preconditions
Arrange open standing with the transition guard satisfied: Review authority and two different existing records of one type are required.
Steps
A reviewer confirms an existing open comparison.
Expected
Read the confirmed standing and inspect the associated changes: assign full score and the human explanation; exclude the confirmed pair from groups.
Data
Fixtures for open, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#takes the dismissal off, the person having just overruled it
06 Observe dismissed becoming confirmed after a reviewer confirms a previously rejected comparisontransitionapiproposed
Proves
BR-CAP-CRM-DQ-009-02
Preconditions
Arrange dismissed standing with the transition guard satisfied: Review authority is required.
Steps
A reviewer confirms a previously rejected comparison.
Expected
Read the confirmed standing and inspect the associated changes: clear the former dismissal; record the human confirmation.
Data
Fixtures for dismissed, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#takes the dismissal off, the person having just overruled it
07 Observe absent becoming confirmed after a reviewer identifies an unstored duplicate pairtransitionapiproposed
Proves
BR-CAP-CRM-DQ-009-01
Preconditions
Arrange absent standing with the transition guard satisfied: Review authority is required.
Steps
A reviewer identifies an unstored duplicate pair.
Expected
Read the confirmed standing and inspect the associated changes: create a manual full-score confirmation without grouping.
Data
Fixtures for absent, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#is confirmed, manual and at full score: certainty, not a computation
08 A reviewer can confirm without merge authorityrulebrowsernegativeproposed
Proves
BR-CAP-CRM-DQ-009-06
Preconditions
A reviewer lacking both record-merge permissions and two records with no detected comparison.
Steps
Use the console confirmation picker, confirm the pair and add another existing record to the reviewed selection.
Expected
Confirmation is available independently of merging. This proposed customer-surface obligation has no executable binding.
Data
Run-owned records and caller permissions that distinguish the two cases.
Source
FND-CRM-DQ-012
09 Human confirmation settles review before planninginteractionapiproposed
Proves
BR-CAP-CRM-DQ-009-01 BR-CAP-CRM-DQ-009-02 BR-CAP-CRM-DQ-009-03 BR-CAP-CRM-DQ-009-04 BR-CAP-CRM-DQ-009-06
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Confirm an open pair and a dismissed pair, read their groups, then prepare the confirmed records for a merge.
Expected
Confirmation updates the existing pair and group membership; planning operates on the same two records.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-009; CAP-CRM-DQ-007; CAP-CRM-DQ-012; WF-CRM-DQ-004

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