Skip to content

ATS-CRM-ACT-009Preserve the baseline activity catalog without replacing customer choices: Capability Test Specification

Markdown

ATS-CRM-ACT-009

Preserve the baseline activity catalog without replacing customer choices: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaCRMModuleActivities, Follow-ups and Task WorkRevision3

Read atservices-crm a8d1364freact-console baf6dae3rhythm-v2-docs 18a49edf

Coverage

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

Test Scenarios

6 scenarios proving CAP-CRM-ACT-009; 5 bound to an existing test.

01 Inspect the expected baseline catalogrulebrowsertest
Proves
BR-CAP-CRM-ACT-009-01
Preconditions
An acceptance workspace is available for baseline inspection.
Steps
List activity types after setup.
Expected
The test expects seven built-in categories; installation across workspaces remains a Platform dependency.
Data
Each run creates and isolates the records it needs.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0728.spec.ts#CRM-ACC-0728
02 Adopt a customized baseline typeinvariantapitest
Proves
BR-CAP-CRM-ACT-009-02
Preconditions
The workspace has renamed its Call type.
Steps
Apply the corresponding seed again.
Expected
The existing customized record remains unchanged.
Data
Each run creates and isolates the records it needs.
Bound to
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#adopts a type the tenant already has under that id, leaving it as the tenant made it
Source
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#adopts a type the tenant already has under that id, leaving it as the tenant made it
03 Prevent baseline type deletionvalidationapinegativetest
Proves
BR-CAP-CRM-ACT-009-03
Preconditions
Call is a built-in activity type.
Steps
Request its deletion.
Expected
The service conflicts and directs deactivation.
Data
Each run creates and isolates the records it needs.
Bound to
Source
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#refuses a system type, saying to deactivate it instead
04 Preserve and uniquely reserve baseline codesinvariantapinegativetest
Proves
BR-CAP-CRM-ACT-009-04 BR-CAP-CRM-ACT-009-05
Preconditions
The workspace has built-in Call.
Steps
Try another code on its replacement and insert another type with the Call code.
Expected
Replacement preserves the code and the duplicate reservation fails.
Data
Each run creates and isolates the records it needs.
Bound to
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#refuses a change of system code in the database too, whatever writes the row
services-crm:modules/activities/tests/integration/db/activities.table.integration.spec.js#refuses a second type of the tenant with the same system code
Source
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#keeps a system type’s system code whatever the replacement says
05 Keep Call direction mandatoryvalidationapinegativetest
Proves
BR-CAP-CRM-ACT-009-06
Preconditions
The workspace has built-in Call.
Steps
Make direction optional.
Expected
The refusal explains the required direction setting.
Data
Each run creates and isolates the records it needs.
Bound to
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#refuses to make the Call type’s direction anything but required, saying why
services-crm:modules/activities/tests/e2e/activities.e2e.spec.js#refuses to make the Call type’s direction optional: 400
Source
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#refuses to make the Call type’s direction anything but required, saying why
06 Both baseline catalogs adopt customer choicesinteractionapiproposed
Proves
BR-CAP-CRM-ACT-009-02 BR-CAP-CRM-ACT-016-09
Preconditions
Customer-edited baseline activity and task classifications exist.
Steps
Apply the two baseline participants repeatedly and read both catalogs and the queue list.
Expected
Customer values remain, missing baseline entries appear, and baseline application creates no queue.
Data
Run-owned records in an isolated workspace; fixed clock for calendar checks.
Source
services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#adopts a type the tenant already has under that id, leaving it as the tenant made it; services-crm:modules/tasks/tests/integration/services/persistence/task-types.integration.spec.js#adopts a record the tenant edited, which is what makes a seed a starting point

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.