Rhythm 2.0 Specifications

Appearance

ATS-PFM-NOT-017Submit association communication requests: Capability Test Specification

Markdown

ATS-PFM-NOT-017

Submit association communication requests: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-NOT-017

Design

Executed by
TST-PFM-NOT-024, TST-PFM-NOT-027, TST-PFM-NOT-028, TST-PFM-NOT-030, TST-PFM-NOT-031, TST-PFM-NOT-032, TST-PFM-NOT-035, TST-PFM-NOT-036, TST-PFM-NOT-039, TST-PFM-NOT-055, TST-PFM-NOT-057, TST-PFM-NOT-060

KindAcceptance test setProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision2

Read atservices-platform ad3f6a65react-console baf6dae3

Submit association communication requests: Capability Test Specification ​

Coverage ​

Each scenario names the guarantee it proves. Category coverage describes specified cases; executable bindings retain their narrower assertion boundaries. Lifecycle coverage remains a gap wherever guards and effects lack independent verification.

RuleProof
BR-CAP-PFM-NOT-017-01ATS-PFM-NOT-017-01, ATS-PFM-NOT-017-15
BR-CAP-PFM-NOT-017-02ATS-PFM-NOT-017-02
BR-CAP-PFM-NOT-017-03ATS-PFM-NOT-017-03
BR-CAP-PFM-NOT-017-04ATS-PFM-NOT-017-04
BR-CAP-PFM-NOT-017-05ATS-PFM-NOT-017-05
BR-CAP-PFM-NOT-017-06ATS-PFM-NOT-017-06
BR-CAP-PFM-NOT-017-07ATS-PFM-NOT-017-07
BR-CAP-PFM-NOT-017-08ATS-PFM-NOT-017-08
BR-CAP-PFM-NOT-017-09ATS-PFM-NOT-017-09
BR-CAP-PFM-NOT-017-10ATS-PFM-NOT-017-10
BR-CAP-PFM-NOT-017-11ATS-PFM-NOT-017-11
BR-CAP-PFM-NOT-017-14ATS-PFM-NOT-017-12
BR-CAP-PFM-NOT-017-15ATS-PFM-NOT-017-13
BR-CAP-PFM-NOT-017-16ATS-PFM-NOT-017-14

Use published compliance content, one eligible contact and one suppressed address. Commit the request with its business change, process and send it, report provider delivery and read the request with its messages.

The interaction case combines the producing, processing and reading outcomes named in its frontmatter. It remains proposed until an executable suite performs that complete sequence.

Coverage

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

Test Scenarios

15 scenarios proving CAP-PFM-NOT-017; 13 bound to an existing test.

01 Commit a communication pointer with its business changeinvariantapitest
Proves
BR-CAP-PFM-NOT-017-01
Preconditions
Prepare a caller transaction that submits a request.
Steps
Submit once in a transaction that rolls back and once in a transaction that commits.
Expected
Rollback leaves no pointer; commit leaves one entry referring to the stored object.
Data
Use only records created and owned by this suite.
Bound to
Source
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#leaves no queue row behind when the caller’s transaction rolls back
02 Restrict callers to scoped pointer insertionpermissionapinegativetest
Proves
BR-CAP-PFM-NOT-017-02
Preconditions
Prepare the communications capability role.
Steps
Insert into another organization; store the claim column; read, change or delete a row; read messages and templates.
Expected
Forbidden access fails; allowed pointer insertion succeeds only in the caller's workspace.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#inserts a queue row into its own tenant naming all ten pointer columns, which is the whole capability
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#cannot write the claim column, so a caller can never hide its own row from the dispatcher
Source
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#inserts a queue row into its own tenant naming all ten pointer columns, which is the whole capability
03 Deduplicate ordinary request retries and recoveryinvariantapitest
Proves
BR-CAP-PFM-NOT-017-03 INV-DOM-PFM-NOT-005-02
Preconditions
Prepare a submitted request.
Steps
Submit the same key while its request waits, during the handoff, after processing and after removal of the request row.
Expected
Repetition returns the same identifier with a duplicate indicator, producing one provider send in the exercised recovery path.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/requests/submit-request.integration.spec.js#is still answered duplicate, because the request object says the id was submitted before
services-platform:modules/communications/tests/integration/services/requests/submit-request.integration.spec.js#is accepted once and sends its one e-mail once, though the queue carried it twice
services-platform:modules/communications/tests/integration/services/requests/submit-request.integration.spec.js#is accepted and its e-mail sent, which is what makes the retry worth taking
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#answers the derived id both times, so a retrying caller is never told an id that does not exist
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#answers the same request id, marked duplicate, when the idempotency key is repeated
Source
services-platform:modules/communications/tests/integration/services/requests/submit-request.integration.spec.js#is answered duplicate, under the id the first submission named
04 Validate before consuming the submission keyvalidationapinegativetest
Proves
BR-CAP-PFM-NOT-017-04
Preconditions
Prepare the request primitive.
Steps
Submit an envelope with a bad path; next the identical key correctly.
Expected
The invalid request reports its field path and stores nothing; corrected input using the key is accepted.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#answers invalid in front of the caller for an envelope it can judge there, naming the problem by path
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#takes nothing for that request, so its key is still free
services-platform:modules/communications/tests/integration/services/requests/handle-invocation.integration.spec.js#answers a broken envelope as an invalid outcome, not an exception, naming the path
services-platform:modules/communications/tests/integration/db/communication-request-submissions.table.integration.spec.js#refuses a malformed submission before anything is written, naming the caller’s own defect
Source
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#answers invalid in front of the caller for an envelope it can judge there, naming the problem by path
05 Retain all non-sending outcomes and reasonsfailureapinegativetest
Proves
BR-CAP-PFM-NOT-017-05
Preconditions
Requests with no template, an unpublished template, data the contract rejects and only suppressed recipients.
Steps
Process each submitted fixture and retrieve its recorded request outcome.
Expected
Missing template, missing publication, invalid fields and fully suppressed recipients produce their corresponding recorded outcomes without sending.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#blocks a request that names no template, recording the reason staff can act on
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#blocks a request naming a template that was never published
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#takes data the purpose’s contract does not accept, and stores it invalid behind the queue
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#withholds every message of a request to a suppressed address, which is the suppressed outcome
Source
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#blocks a request that names no template, recording the reason staff can act on
06 Pin published content and derive message identitiesruleapitest
Proves
BR-CAP-PFM-NOT-017-06
Preconditions
Prepare a record whose template is published; three recipients, one suppressed.
Steps
Send the constructed envelope through the request primitive.
Expected
The accepted request pins its version. The receipt names message identities before persistence; processing queues two messages and withholds one.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#names the messages in the receipt, under ids derived from the request, before any of them exists
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#accepts the request with the owner’s published version pinned
07 Reject missing and mismatched stored objectsboundaryapinegativetest
Proves
BR-CAP-PFM-NOT-017-07 INV-DOM-PFM-NOT-005-03
Preconditions
Prepare a row whose object names another organization; a row whose object is gone.
Steps
Evaluate both stored-object fixtures.
Expected
Both requests become invalid with object-specific problems and produce no sends.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/storage/communication-objects.integration.spec.js#refuses an object that names another tenant, which is what the grant cannot prevent
Source
services-platform:modules/communications/tests/integration/services/storage/communication-objects.integration.spec.js#refuses an object that names another tenant, which is what the grant cannot prevent
08 Override caller values for reserved rendering fieldsinvariantapinegativetest
Proves
BR-CAP-PFM-NOT-017-08
Preconditions
Prepare a request whose data names another association.
Steps
Process acceptance and inspect the resulting rendered message.
Expected
Rendering uses the actual association name and generated message reference.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/communication-reads.integration.spec.js#sets the association over whatever the caller sent under that name, so a caller cannot rename the association
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#fills the platform’s variables: the association and the message’s own reference
Source
services-platform:modules/communications/tests/integration/services/communication-reads.integration.spec.js#sets the association over whatever the caller sent under that name, so a caller cannot rename the association
09 Send valid caller-rendered content unchangedruleapinegativetest
Proves
BR-CAP-PFM-NOT-017-09
Preconditions
Prepare a invoice e-mail with an attachment.
Steps
Try valid caller content, missing caller content, caller content naming a template and attachment-bearing Platform-rendered content.
Expected
Valid supplied content sends with derived text and its attachment; incompatible or invalid cases are rejected.
Data
Use only records created and owned by this suite.
Bound to
Source
services-platform:modules/communications/tests/integration/services/dispatch/caller-rendered.integration.spec.js#accepts the request without resolving any template
10 Allow display configuration without caller-selected addressesedgeapitest
Proves
BR-CAP-PFM-NOT-017-10
Preconditions
Prepare a request with a display name, reply-to and copies.
Steps
Process the configured message through delivery.
Expected
Delivery uses the workspace sender address, supplied display name and reply-to, and only copies that pass recipient checks.
Data
Use only records created and owned by this suite.
Bound to
Source
services-platform:modules/communications/tests/integration/services/dispatch/caller-rendered.integration.spec.js#sends from the tenant's sender address, under the caller's display name
11 Use pinned Marketing content or record blockingvalidationapinegativetest
Proves
BR-CAP-PFM-NOT-017-11
Preconditions
Prepare a Marketing message version and its template.
Steps
Send it after a newer version exists; send a absent version, another purpose's, an unowned one and a newer contract's.
Expected
Valid pinned content sends; invalid version, owner or contract cases block with reasons and create no message.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/integration/services/dispatch/owned-template.integration.spec.js#still sends a version that is no longer its template’s current one, and sends the pinned content
Source
services-platform:modules/communications/tests/integration/services/dispatch/owned-template.integration.spec.js#still sends a version that is no longer its template’s current one, and sends the pinned content
12 Deny direct association sends from console callerspermissionapinegativetest
Proves
BR-CAP-PFM-NOT-017-14
Preconditions
Prepare a console caller and a system caller.
Steps
Call submission from both the console and system sessions.
Expected
The console request fails; an authorized system caller receives the submission receipt.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#refuses a console caller the system route that asks for a communication
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#answers a receipt naming the request the caller may read it under, and the messages it will have
Source
services-platform:modules/communications/tests/e2e/requests.e2e.spec.js#refuses a console caller the system route that asks for a communication
13 Retain rollback objects until lifecycle cleanupedgeapiproposed
Proves
BR-CAP-PFM-NOT-017-15
Preconditions
Prepare a request object store and a caller transaction.
Steps
Store a request, store its pointer, next roll back the caller transaction.
Expected
No pointer or queued work survives rollback, while its stored object awaits lifecycle removal.
Data
A request object store and a caller transaction.
Source
services-platform:docs/communications/architecture.md#18.12 One S3 write inside the caller's transaction
14 Enforce rendering and version consistencyvalidationapinegativetest
Proves
BR-CAP-PFM-NOT-017-16 INV-DOM-PFM-NOT-005-09
Preconditions
Message persistence with a valid request and optional published version.
Steps
Insert Platform transactional content without a version, Platform test content without a version, caller content without a version, caller content with a version and an unsupported rendering kind.
Expected
Platform transactional content without a version fails. Draft Platform test and version-less caller content succeed. Caller content with a version and unsupported rendering kinds fail.
Data
Use isolated messages and a published version owned by the suite.
Bound to
services-platform:modules/communications/tests/integration/db/communication-messages.table.integration.spec.js#refuses a transactional message Platform rendered, by the version check’s name
services-platform:modules/communications/tests/integration/db/communication-messages.table.integration.spec.js#accepts the same message rendered by the caller, which is the negative control
Source
services-platform:modules/communications/tests/integration/db/communication-messages.table.integration.spec.js#refuses a transactional message Platform rendered, by the version check’s name
15 Accepted content, safeguards and feedback remain connectedinteractionapiproposed
Proves
BR-CAP-PFM-NOT-017-06
Preconditions
Use published compliance content, one eligible contact and one suppressed address.
Steps
Commit the request with its business change, process and send it, report provider delivery and read the request with its messages.
Expected
The eligible contact has one submitted message pinned to the publication. The protected address has a withholding reason, and provider delivery changes the message history without changing the receipt identity.
Data
A suite-owned workspace, named staff accounts and unique occurrence keys; external adapters record attempts without shared writes.
Source
rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-017-ask-platform-to-send-an-association-e-mail.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-018-deliver-association-e-mail-reliably-and-within-sending.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-019-record-what-became-of-each-e-mail.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-020-protect-deliverability-and-the-associations-sending-address.md#frontmatter

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