ATS-CRM-DQ-018 Resolve identities absorbed by a merge: Capability Test Specification
Markdown Design / CRM / Duplicate Review and Record Merging / Follow Absorbed Identities and Outcomes / Capability Test Specification Resolve identities absorbed by a merge: 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 Rule Scenarios BR-CAP-CRM-DQ-018-01ATS-CRM-DQ-018-01ATS-CRM-DQ-018-09ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-02ATS-CRM-DQ-018-02ATS-CRM-DQ-018-10ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-03ATS-CRM-DQ-018-03ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-04ATS-CRM-DQ-018-04ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-05ATS-CRM-DQ-018-05ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-06ATS-CRM-DQ-018-06ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-07ATS-CRM-DQ-018-07ATS-CRM-DQ-018-12ATS-CRM-DQ-018-13ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-08ATS-CRM-DQ-018-08ATS-CRM-DQ-018-18BR-CAP-CRM-DQ-018-09ATS-CRM-DQ-018-11
Open each link. Merge a contact twice, open the oldest link, query by its former number and inspect its lineage under record-read authority.
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 gap: FND-CRM-DQ-069 Permission gap: FND-CRM-DQ-069 Edge gap: FND-CRM-DQ-069 Failure gap: FND-CRM-DQ-069 Boundary covered Concurrency gap: FND-CRM-DQ-069 Invariant covered Interaction covered Test Scenarios 18 scenarios proving CAP-CRM-DQ-018
03 Absorbed identities cannot be recreated invariant api negative test
Proves BR-CAP-CRM-DQ-018-03Preconditions Prepare contact and organization aliases. Steps Create records under their absorbed identities and under fresh ones. Expected Absorbed identities fail for their own type while fresh identities succeed. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/integration/db/merged-id-reuse.integration.spec.js #refuses a contact under it, naming the id and what became of it 04 Alias lookup distinguishes absorbed and unused identities rule api test
Proves BR-CAP-CRM-DQ-018-04Preconditions A merge has completed. Steps Resolve an absorbed identity and an identity never merged. Expected The first returns survivor, merge and time and the second is not found. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merges.e2e.spec.js #says where an id the merge took away went, and through which merge 05 Workspace isolation applies to aliases boundary api negative test
Proves BR-CAP-CRM-DQ-018-05Preconditions An identity was absorbed in another workspace. Steps Read it locally and try writing an alias into that workspace. Expected Local lookup returns not found and the foreign write is rejected. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merged-records.e2e.spec.js #answers 404 in this tenant for an id merged away in another, whose merge is not ours to disclose 09 Observe live record becoming absorbed after a successful merge removes this participant transition api proposed
Proves BR-CAP-CRM-DQ-018-01Preconditions Arrange live record standing with the transition guard satisfied: The alias is written in the committing merge transaction. Steps A successful merge removes this participant. Expected Read the absorbed standing and inspect the associated changes: retain destination and merge attribution with prior integration identity; deny later identity reuse. Data Fixtures for live record, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/db/merged-record-aliases.table.integration.spec.js #refuses a second alias of the same merged id, so following one is never a choice 10 Observe absorbed becoming absorbed after a later merge absorbs the existing survivor transition api proposed
Proves BR-CAP-CRM-DQ-018-02Preconditions Arrange absorbed standing with the transition guard satisfied: The later merge transaction applies alias compression. Steps A later merge absorbs the existing survivor. Expected Read the absorbed standing and inspect the associated changes: redirect the alias while retaining its original merge attribution. Data Fixtures for absorbed, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/services/persistence/merged-record-aliases.integration.spec.js #leaves C holding both aliases, so the survivor can say what it is made of 11 Observe absorbed becoming dangling after ordinary deletion removes the survivor transition api negative proposed
Proves BR-CAP-CRM-DQ-018-09Preconditions Arrange absorbed standing with the transition guard satisfied: No implemented destination-liveness guard prevents this. Steps Ordinary deletion removes the survivor. Expected Read the dangling standing and inspect the associated changes: retain a pointer to a missing destination. Data Fixtures for absorbed, the guard and the affected records; a fixed clock for time-dependent changes. Source FND-CRM-DQ-022 12 Observe absorbed becoming purged after workspace lifecycle removes absorbed identity history transition api proposed
Proves BR-CAP-CRM-DQ-018-07Preconditions Arrange absorbed standing with the transition guard satisfied: Privileged purge capability performs the deletion. Steps Workspace lifecycle removes absorbed identity history. Expected Read the purged standing and inspect the associated changes: remove aliases before their merge history. Data Fixtures for absorbed, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/db/merged-record-aliases.table.integration.spec.js #may not erase an alias, which would make a merged id answerable and reusable again 13 Observe dangling becoming purged after workspace lifecycle removes a dangling alias transition api proposed
Proves BR-CAP-CRM-DQ-018-07Preconditions Arrange dangling standing with the transition guard satisfied: Deletion requires the privileged workspace capability. Steps Workspace lifecycle removes a dangling alias. Expected Read the purged standing and inspect the associated changes: remove the retained pointer. Data Fixtures for dangling, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/db/merged-record-aliases.table.integration.spec.js #may not erase an alias, which would make a merged id answerable and reusable again 14 An absorbed identity cannot receive a second alias invariant api test
Proves INV-DOM-CRM-DQ-004-06 Preconditions A stored alias for one absorbed identity. Steps Attempt a second alias for that same identity in the same workspace and record type. Expected The duplicate alias is refused. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/merges/tests/integration/db/merged-record-aliases.table.integration.spec.js #refuses a second alias of the same merged id, so following one is never a choice 15 A second absorption redirects the oldest alias invariant api test
Proves INV-DOM-CRM-DQ-004-07 Preconditions A contact absorbed into a survivor that is later absorbed into a third contact. Steps Insert the later merge’s aliases and read the final survivor’s incoming aliases. Expected Both absorbed contacts resolve directly to the third contact. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/merges/tests/integration/services/persistence/merged-record-aliases.integration.spec.js #leaves C holding both aliases, so the survivor can say what it is made of 16 Chosen contact identity cannot reuse an absorbed identity invariant api test
Proves INV-DOM-CRM-DQ-004-08 Preconditions A contact identity already recorded as absorbed in this workspace. Steps Create another contact explicitly naming that identity. Expected Creation is refused without another live contact at the old identity. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/merges/tests/integration/db/merged-id-reuse.integration.spec.js #refuses the contact a client asks to create under it, which is the path a chosen id arrives by 17 An application cannot erase an alias invariant api test
Proves INV-DOM-CRM-DQ-004-09 Preconditions A retained alias and the ordinary application database role. Steps Attempt deletion through that role. Expected The alias remains and the operation is refused. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/merges/tests/integration/db/merged-record-aliases.table.integration.spec.js #may not erase an alias, which would make a merged id answerable and reusable again ← Previous Capability Test Specification ATS-CRM-DQ-017 · Combine organizations and their connections safely: Capability Test Specification Next Capability Test Specification → ATS-CRM-DQ-019 · Inspect merge outcomes and attribution: Capability Test Specification