ATS-CRM-DQ-012 Prepare a merge and choose its survivor: Capability Test Specification
Markdown Design / CRM / Duplicate Review and Record Merging / Prepare a Reviewed Merge / Capability Test Specification Prepare a merge and choose its survivor: 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.
Launch their plans from the queue. Launch from a record, choose a different survivor, answer a conflict, remove a participant and execute the refreshed preview.
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-063 Permission covered Edge gap: FND-CRM-DQ-063 Failure gap: FND-CRM-DQ-063 Boundary covered Concurrency gap: FND-CRM-DQ-063 Invariant covered Interaction covered Test Scenarios 18 scenarios proving CAP-CRM-DQ-012
02 Plan authority requires the type's complete permission pair permission api negative test
Proves BR-CAP-CRM-DQ-012-02Preconditions Prepare contact-only authority, organization merge-only, read-only and merge-without-read callers. Steps Request contact and organization plans. Expected Every incomplete type-specific read-and-merge pair is refused. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merges.e2e.spec.js #refuses the plan to a caller who may merge contacts but not organizations 05 Participant changes preserve only applicable decisions transition api test
Proves BR-CAP-CRM-DQ-012-08Preconditions A three-record plan holds decisions. Steps Remove one participant and read again after data changes. Expected Two participants remain and invalidated decisions are removed with explanations. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merges.e2e.spec.js #answers the change with the two records that are left, in record_ids and in records 06 The expiry sweep respects stored deadlines transition api test
Proves BR-CAP-CRM-DQ-012-10Preconditions Create overdue undecided and blocked plans, a completed plan and a ready plan whose stored deadline is later. Steps Run the sweep at a fixed time and repeat it. Expected The overdue undecided and blocked plans are expired; the completed and not-yet-due plans retain their standing; repetition expires nothing. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/integration/services/merges/merge-plan-expiry.integration.spec.js #expires the plan whose seven days are up, which is what takes it off the reader’s list 08 Observe needs_decisions becoming expired after the expiry sweep finds an overdue working preview transition api proposed
Proves INV-DOM-CRM-DQ-003-12 Preconditions Arrange needs_decisions standing with the transition guard satisfied: Only executed and already-expired plans are excluded. Steps The expiry sweep finds an overdue working preview. Expected Read the expired standing and inspect the associated changes: mark expiry and advance the version. Data Fixtures for needs_decisions, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/services/merges/merge-plan-expiry.integration.spec.js #expires a blocked plan too, a plan nobody cleared being as abandoned as one nobody decided 09 Observe ready becoming expired after the expiry sweep finds an overdue ready preview transition api proposed
Proves INV-DOM-CRM-DQ-003-12 Preconditions Arrange ready standing with the transition guard satisfied: Only executed and already-expired plans are excluded. Steps The expiry sweep finds an overdue ready preview. Expected Read the expired standing and inspect the associated changes: mark expiry. Data Fixtures for ready, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/services/merges/merge-plan-expiry.integration.spec.js #expires a blocked plan too, a plan nobody cleared being as abandoned as one nobody decided 10 Observe blocked becoming expired after the expiry sweep finds an overdue blocked preview transition api proposed
Proves INV-DOM-CRM-DQ-003-12 Preconditions Arrange blocked standing with the transition guard satisfied: Only executed and already-expired plans are excluded. Steps The expiry sweep finds an overdue blocked preview. Expected Read the expired standing and inspect the associated changes: mark expiry. Data Fixtures for blocked, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/tests/integration/services/merges/merge-plan-expiry.integration.spec.js #expires a blocked plan too, a plan nobody cleared being as abandoned as one nobody decided 11 Observe executing becoming expired after the expiry sweep finds an overdue active attempt’s plan transition api proposed
Proves INV-DOM-CRM-DQ-003-12 Preconditions Arrange executing standing with the transition guard satisfied: Executing standing is not excluded by the sweep. Steps The expiry sweep finds an overdue active attempt’s plan. Expected Read the expired standing and inspect the associated changes: mark expiry while the attempt may still execute. Data Fixtures for executing, the guard and the affected records; a fixed clock for time-dependent changes. Source services-crm:modules/merges/services/persistence/record-merge-plans.ts :expireRecordMergePlans 12 Invalid participant lists cannot create a preview invariant api proposed
Proves INV-DOM-CRM-DQ-003-01 Preconditions Lists of one and eleven records, a repeated record and an outside survivor. Steps Create each proposed plan and inspect saved previews. Expected Every invalid list is refused without a saved plan. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Source services-crm:modules/merges/services/persistence/record-merge-plans.ts :createRecordMergePlan ; modules/merges/db/record-merge-plans.table.ts :record_merge_plans_record_ids_check 13 A preview and its material hash cannot be stored separately invariant api proposed
Proves INV-DOM-CRM-DQ-003-02 Preconditions Direct plan rows containing only a computed preview or only its hash. Steps Attempt each incomplete database insert. Expected Both inserts are refused by the database. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Source services-crm:modules/merges/db/record-merge-plans.table.ts :record_merge_plans_plan_hash_check 14 A settled preview refuses another edit invariant api proposed
Proves INV-DOM-CRM-DQ-003-06 Preconditions Plans in executing, executed and expired standing. Steps Try an answer or participant edit at the current version of each plan. Expected Every edit is refused and the stored preview stays unchanged. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Source services-crm:modules/merges/services/merges/merge-plans.ts :assertPlanIsOpen 15 Editing does not renew the stored expiry deadline invariant api proposed
Proves INV-DOM-CRM-DQ-003-12 Preconditions A plan near its stored creation-based expiry deadline. Steps Edit the plan, read its deadline and sweep after that stored instant. Expected The deadline is unchanged and the sweep expires the edited plan. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Source services-crm:modules/merges/services/persistence/record-merge-plans.ts:defaultExpiry, updateRecordMergePlan, expireRecordMergePlans 16 Authority for only the other record type cannot create a plan invariant api test
Proves INV-DOM-CRM-DQ-003-13 Preconditions A context qualified for contact merging and an organization participant list. Steps Create the organization plan with the contact context. Expected The route refuses the plan before saving it. 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/e2e/merges.e2e.spec.js #refuses the plan to a caller who may merge contacts but not organizations 17 A preview remains inaccessible in another workspace invariant api proposed
Proves INV-DOM-CRM-DQ-003-14 Preconditions A saved plan and a current-version edit attempted through a different workspace. Steps Read and update the plan using the other workspace context. Expected The plan is unavailable and its records remain unchanged. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Source services-crm:db/row-level-security.ts (record_merge_plans forced workspace policy) ← Previous Capability Test Specification ATS-CRM-DQ-011 · Understand the duplicate-review workload: Capability Test Specification Next Capability Test Specification → ATS-CRM-DQ-013 · Resolve differences in the merge preview: Capability Test Specification