Rhythm 2.0 Specifications

Appearance

ATS-CRM-DQ-006Reuse a contact during portal registration: Capability Test Specification

Markdown

ATS-CRM-DQ-006

Reuse a contact during portal registration: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-006

Design

Executed by
TST-CRM-DQ-180

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Reuse a contact during portal registration: 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-006-01ATS-CRM-DQ-006-01, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-02ATS-CRM-DQ-006-02, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-03ATS-CRM-DQ-006-07, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-04ATS-CRM-DQ-006-01, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-05ATS-CRM-DQ-006-03, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-06ATS-CRM-DQ-006-03, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-07ATS-CRM-DQ-006-03, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-08ATS-CRM-DQ-006-04, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-09ATS-CRM-DQ-006-05, ATS-CRM-DQ-006-08
BR-CAP-CRM-DQ-006-10ATS-CRM-DQ-006-06, ATS-CRM-DQ-006-08

Decline an eligible offered contact, create the registration contact, deliver its detection change and open the resulting review group.

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 covered
  • Failure gap: FND-CRM-DQ-057
  • Boundary covered
  • Concurrency gap: FND-CRM-DQ-057
  • Invariant covered
  • Interaction covered

Test Scenarios

8 scenarios proving CAP-CRM-DQ-006; 6 bound to an existing test.

01 Registration suggestions use the medium floor and rankingboundaryapitest
Proves
BR-CAP-CRM-DQ-006-01 BR-CAP-CRM-DQ-006-04
Preconditions
Prepare neighboring scores of 70, 50, 50, 50 and 38.
Steps
Call candidate selection.
Expected
Three contacts appear, shared e-mail first and tied scores by number, with staff-equivalent scores.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#answers the three best contacts above the floor, the e-mail match first and a tie in contact-number order, with what Platform masks
02 Unavailable registration identities are excludededgeapinegativetest
Proves
BR-CAP-CRM-DQ-006-02
Preconditions
Prepare linked, deleted and other-workspace matching contacts.
Steps
Request candidates.
Expected
None of those contacts is offered.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#never offers a contact a portal user of the tenant already links
03 Declining a suggestion preserves a review pairtransitionapitest
Proves
BR-CAP-CRM-DQ-006-05 BR-CAP-CRM-DQ-006-06 BR-CAP-CRM-DQ-006-07
Preconditions
Registration rejects an existing candidate.
Steps
Create the portal contact naming that candidate and detect the new record.
Expected
The contact has portal attribution and an open declined-match pair at 35 that remains grouped after detection.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#writes the contact with a UUIDv7 id, the next number, the names trimmed and computed and the stamps of portal-sign-up
04 Repeated registration reuses its recent contactinvariantapitest
Proves
BR-CAP-CRM-DQ-006-08
Preconditions
A registration has just created a contact.
Steps
Repeat the submission within one minute.
Expected
The function returns that contact and performs no further creation.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#answers the same contact for the same sign-up retried within a minute, and writes nothing more
05 Registration honors contact validationvalidationapinegativetest
Proves
BR-CAP-CRM-DQ-006-09
Preconditions
An active contact reserves the intended primary e-mail.
Steps
Try creation with that address, then try creation without either name.
Expected
Both requests are rejected.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#refuses an address that is already the primary address of a contact it did not just create
06 Portal functions restrict their callers and workspacepermissionapinegativetest
Proves
BR-CAP-CRM-DQ-006-10
Preconditions
Use the CRM application role and a session outside the target workspace.
Steps
Attempt the registration functions.
Expected
The calls are denied.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#refuses CRM's own application role, which is not granted it
07 A name alone produces no registration suggestionruleapinegativeproposed
Proves
BR-CAP-CRM-DQ-006-03
Preconditions
An unlinked contact matching the supplied names but sharing neither e-mail nor phone.
Steps
Select registration candidates, then repeat with a shared phone and sufficient scoring evidence.
Expected
The name-only input returns no candidate; the shared-phone case can return the eligible contact.
Data
Run-owned records and caller permissions that distinguish the two cases.
Source
services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#offers nothing for a sign-up that shares no e-mail address and no number with any contact
08 Declined registration reaches the staff queueinteractionapiproposed
Proves
BR-CAP-CRM-DQ-006-01 BR-CAP-CRM-DQ-006-04 BR-CAP-CRM-DQ-006-02 BR-CAP-CRM-DQ-006-05 BR-CAP-CRM-DQ-006-06 BR-CAP-CRM-DQ-006-07 BR-CAP-CRM-DQ-006-08 BR-CAP-CRM-DQ-006-09 BR-CAP-CRM-DQ-006-10 BR-CAP-CRM-DQ-006-03
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Decline an eligible offered contact, create the registration contact, deliver its detection change and open the resulting review group.
Expected
The registration pair retains its origin and the staff queue presents the same contact evidence.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-006; CAP-CRM-DQ-007; WF-CRM-DQ-008

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