Rhythm 2.0 Specifications

Appearance

FAS-PFM-NOT-07Association Communication Delivery

Markdown

FAS-PFM-NOT-07

Association Communication Delivery

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Feature
FEAT-PFM-NOT-07
Capabilities
CAP-PFM-NOT-016, CAP-PFM-NOT-017, CAP-PFM-NOT-018, CAP-PFM-NOT-019, CAP-PFM-NOT-020
Executed by
TST-PFM-NOT-030

Product areaPlatformModuleStaff Notifications and Association CommunicationsRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

Association Communication Delivery: Feature Acceptance Suite ​

What the Feature Must Do as a Whole ​

This suite follows the feature from its initial inputs through the outcomes people inspect. Its cases combine capability results so that a change at one stage is checked against the later stages that depend on it.

Interactions Between Capabilities ​

Record a permanent bounce, replay the feedback and submit another request to the same address. The bounce has one retained event; the next request records a protected withholding outcome with no provider send.

The feature cases retain their prerequisite scenario references. A component test alone does not establish execution of the complete feature chain.

Regression Record ​

RevisionChangeScenarioWhy
1initialAll initial casesEstablish cumulative feature coverage and preserve its dependencies for later revisions.

Scenarios

5 scenarios proving FEAT-PFM-NOT-07 as a whole.

01 Published compliance content yields protected recipient outcomes behaviour test
Exercises
CAP-PFM-NOT-016 CAP-PFM-NOT-017 CAP-PFM-NOT-018 CAP-PFM-NOT-020
Relies on
ATS-PFM-NOT-016-08 ATS-PFM-NOT-017-06 ATS-PFM-NOT-018-13 ATS-PFM-NOT-020-06
Preconditions
Use an owner publication, an eligible recipient, a suppressed recipient and an environment-restricted address.
Steps
Commit the request, process its content and dispatch the accepted messages.
Expected
The request pins its publication and only the eligible recipient crosses the provider transport seam.
Data
Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes.
Bound to
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js
02 Bounce feedback changes the next request outcome interaction test
Exercises
CAP-PFM-NOT-019 CAP-PFM-NOT-020
Relies on
ATS-PFM-NOT-019-01 ATS-PFM-NOT-019-02 ATS-PFM-NOT-020-01 ATS-PFM-NOT-020-12
Preconditions
Send a compliance message and retain provider correlation tags.
Steps
Record a permanent bounce, replay the feedback and submit another request to the same address.
Expected
The bounce has one retained event; the next request records a protected withholding outcome with no provider send.
Data
Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes.
Bound to
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js
03 Publication, acceptance and provider history retain distinct facts lifecycle test
Exercises
CAP-PFM-NOT-016 CAP-PFM-NOT-017 CAP-PFM-NOT-018 CAP-PFM-NOT-019
Relies on
ATS-PFM-NOT-016-14 ATS-PFM-NOT-017-06 ATS-PFM-NOT-018-13 ATS-PFM-NOT-019-02
Preconditions
A record owns no publication initially and an eligible contact is ready for compliance mail.
Steps
Submit before publication, publish corrected content, submit and send again, then report delivery and late deferral.
Expected
The first request stays blocked; the accepted request retains its version and submission, while late feedback does not reverse delivery.
Data
Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes.
Bound to
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js
04 Submission, message history and body access remain separate permissionnegative proposed
Exercises
CAP-PFM-NOT-017 CAP-PFM-NOT-019
Relies on
ATS-PFM-NOT-017-12 ATS-PFM-NOT-019-05 ATS-PFM-NOT-019-07
Preconditions
Use a console caller, an authorized system caller and a message reader without sensitive content authority.
Steps
Attempt submission and then read request detail, messages and stored bodies under the relevant identities.
Expected
Only the system caller submits; workspace history and sensitive body access retain their separate checks.
Data
Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes.
Source
rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-017-ask-platform-to-send-an-association-e-mail.md#ATS-PFM-NOT-017-12,rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-05,rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-07
05 Replayed queue work and feedback add no second send regression test
Exercises
CAP-PFM-NOT-017 CAP-PFM-NOT-018 CAP-PFM-NOT-019
Relies on
ATS-PFM-NOT-017-03 ATS-PFM-NOT-018-02 ATS-PFM-NOT-019-01
Preconditions
Retain the accepted compliance request and a previously recorded delivery event.
Steps
Repeat publication, dispatcher processing, completed sending and delivery feedback.
Expected
The ordinary completed-message path keeps one submitted message and one copy of the provider event.
Data
Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes.
Bound to
Source
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js

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