Rhythm 2.0 Specifications

Appearance

ATS-PFM-INT-020Publish event-driven automation and follow its work: Capability Test Specification

Markdown

ATS-PFM-INT-020

Publish event-driven automation and follow its work: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-INT-020

Design

Executed by
TST-PFM-INT-003, TST-PFM-INT-007, TST-PFM-INT-587, TST-PFM-INT-588, TST-PFM-INT-589, TST-PFM-INT-594, TST-PFM-INT-598

KindAcceptance test setProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision3

Read atservices-platform ad3f6a65macroservice-libraries 54536a44react-console baf6dae3

Publish event-driven automation and follow its work: Capability Test Specification ​

Coverage ​

RuleProved By
BR-CAP-PFM-INT-020-01ATS-PFM-INT-020-01, ATS-PFM-INT-020-09
BR-CAP-PFM-INT-020-02ATS-PFM-INT-020-02, ATS-PFM-INT-020-09
BR-CAP-PFM-INT-020-03ATS-PFM-INT-020-03, ATS-PFM-INT-020-09
BR-CAP-PFM-INT-020-04ATS-PFM-INT-020-04, ATS-PFM-INT-020-09, ATS-PFM-INT-020-10
BR-CAP-PFM-INT-020-05ATS-PFM-INT-020-05, ATS-PFM-INT-020-09
BR-CAP-PFM-INT-020-06ATS-PFM-INT-020-06
BR-CAP-PFM-INT-020-07ATS-PFM-INT-020-07
BR-CAP-PFM-INT-020-09ATS-PFM-INT-020-08

Automation publication depends on the current action registry and the configured recipe. The interaction cases check permission refusal, declaration retirement and the effect of later configuration changes on published work.

The structured scenarios name the capabilities and rules involved. A bound test contributes only the outcomes it asserts; proposed transition matrices and composed interactions still require executable proof.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge gap: FND-PFM-INT-090
  • Failure covered
  • Boundary gap: FND-PFM-INT-090
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

10 scenarios proving CAP-PFM-INT-020; 8 bound to an existing test.

01 Draft ownership follows the selected eventtransitionapinegativetest
Proves
BR-CAP-PFM-INT-020-01
Preconditions
The automation API can configure an overdue-invoice event.
Steps
Create its rule, replace the event before publication, publish and try another event change.
Expected
Accounting owns the rule, the draft event change succeeds and the published rule refuses another event.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/services/persistence/automation-rules.integration.spec.js#creates the rule as a draft, owned by the event’s application, with its first version as the draft
02 Draft versions are edited rather than multipliedconcurrencyapitest
Proves
BR-CAP-PFM-INT-020-02
Preconditions
A rule already has a published version.
Steps
Save a new draft, update it and submit a stale update.
Expected
The next version opens once, subsequent saves edit that draft and stale writes refuse.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/db/workflow-actions-tables.integration.spec.js#refuses a second draft of one rule
03 Publication requires a runnable configuration and authorityvalidationapinegativetest
Proves
BR-CAP-PFM-INT-020-03 AS-JNY-PFM-INT-006-01
Preconditions
An overdue-invoice rule remains draft.
Steps
Publish with an unknown event, undeclared fact, no action, wrong trigger and missing action permission, then correct it.
Expected
Each invalid publication names its problem; valid publication retains the necessary permissions.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/services/automation/publish-automation-rule.integration.spec.js#refuses a publisher without the permission an action’s type requires
04 Published content resists direct mutationinvariantapitest
Proves
BR-CAP-PFM-INT-020-04
Preconditions
A rule version is published.
Steps
Attempt direct changes to actions, condition, fingerprint and publication fields.
Expected
All content changes refuse while allowed system-column maintenance remains possible.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/db/workflow-actions-tables.integration.spec.js#refuses a change to a published version’s actions
05 Rule retirement preserves historical meaningtransitionapinegativetest
Proves
BR-CAP-PFM-INT-020-05
Preconditions
Prepare draft, enabled, disabled and retired rules.
Steps
Enable a draft, toggle enabled and disabled, retire, move retired and delete published or unpublished rules.
Expected
Only permitted moves succeed; published rules retain history through retirement rather than deletion.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/services/persistence/automation-rules.integration.spec.js#refuses to delete a published rule, which is retired instead (409)
06 Automation uses the published version once per eventruleapitest
Proves
BR-CAP-PFM-INT-020-06
Preconditions
An enabled rule has a newer draft, alongside a disabled rule.
Steps
Raise the same event twice.
Expected
Only the enabled published version raises actions once and attributes them to its rule and version.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
macroservice-libraries:packages/workflow-actions/src/tests/integration/automation.integration.spec.ts#raises each matching rule’s actions as platform.automation_rule, rule and version, at event, once per event
07 Cross-application views tolerate an unavailable hostfailureapitest
Proves
BR-CAP-PFM-INT-020-07
Preconditions
Two hosts expose views and one lacks a required column.
Steps
Read runs, timers and attention filters.
Expected
The sound host returns ordered work and failed or blocked attention items, while the incompatible host is skipped with a warning.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/integration/services/persistence/cross-workflow-views.queries.integration.spec.js#skips a host with no view, and one whose view lacks a column, naming each
08 Read authority does not grant automation operationpermissionapinegativetest
Proves
BR-CAP-PFM-INT-020-09
Preconditions
Prepare a registry reader and a person lacking run-read.
Steps
Publish as the reader and inspect runs as the other person.
Expected
Both requests deny access.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/workflow-actions/tests/e2e/workflow-actions.e2e.spec.js#refuses a reader the publish (403)
09 Exercise the complete automation rule lifecycletransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-020-01 BR-CAP-PFM-INT-020-02 BR-CAP-PFM-INT-020-03 BR-CAP-PFM-INT-020-04 BR-CAP-PFM-INT-020-05
Preconditions
Prepare one independent record in each starting state, including absent-record cases where the model defines creation.
Steps
Run each listed transition once with its guard satisfied, then repeat it with the guard denied. Inspect the resulting record and listed side effects after commit.
Expected
Each positive case reaches its listed destination and records its defined side effects. Each denied case preserves the starting record and creates no transition side effects.
Data
Run-owned records and principals in an isolated workspace.
Source
rhythm-v2-docs:specs/platform/integrations/design/state-models/STATE-PFM-INT-015-automation-rule-lifecycle.md#transitions
10 Recipe edits leave a published automation unchangedinteractionapiproposed
Proves
BR-CAP-PFM-INT-019-04 BR-CAP-PFM-INT-020-04
Preconditions
A rule publishes actions copied from a customer recipe.
Steps
Edit the recipe, inspect the published version and raise its event.
Expected
Published content and raised work keep the copied actions until an explicit new version is published.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:docs/workflow-actions/README.md#Workflow actions: Platform's part of the Workflow Action Engine,services-platform:modules/workflow-actions/tests/integration/db/workflow-actions-tables.integration.spec.js#refuses a change to a published version’s actions

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