Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-015Keep deletion decisions visible to staff: Acceptance Test Set

Markdown

ATS-PFM-TNL-015

Keep deletion decisions visible to staff: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-015

KindAcceptance test setProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Test Scenarios

5 scenarios proving CAP-PFM-TNL-015; 5 bound to an existing test.

01 Reminder timing follows the chosen waitunittest
Proves
BR-CAP-PFM-TNL-015-01
Preconditions
The fixture covers long, boundary and short waiting periods.
Steps
Calculate request notice obligations.
Expected
Seven-day reminders require at least eight days and final reminders become immediate below two days.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes the notice at request, the seven-day reminder and the one-day reminder, in that order
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is owed at exactly eight days, the shortest period with room for it
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is skipped just below eight days, where it would fall before the request itself
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once just below two days, so a short period still has the notice destruction waits for
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once for a one-day period, the never-active tenant
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes both of those notices due at once, or a tenant with a one-day period could never be deleted
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes the notice at request, the seven-day reminder and the one-day reminder, in that order
02 State changes create notice obligationsapitest
Proves
BR-CAP-PFM-TNL-015-02
Preconditions
Fixtures exercise hold, release, execution, completion and failure.
Steps
Inspect notice obligations after each event.
Expected
Each event retains the corresponding notice kind.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a notice, because a schedule that changes silently is a schedule nobody can trust
services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes an executing notice, so somebody is told the point of no return was passed
Source
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a notice, because a schedule that changes silently is a schedule nobody can trust
03 Recipients remain internalapitest
Proves
BR-CAP-PFM-TNL-015-03
Preconditions
The request advances through its waiting period.
Steps
Inspect captured recipients for each notice.
Expected
Recipients are the staff list and requester, with no customer-facing addition.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells the staff list and the requester, and nobody else
04 Notice slots deduplicate recorded obligationsapitest
Proves
BR-CAP-PFM-TNL-015-04
Preconditions
A thirty-day request is scheduled.
Steps
Run its notice schedule and append an existing slot again.
Expected
Notices occur at their due times and repeated slot insertion adds no duplicate record.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a notice whose schedule slot is already taken, so a re-run sends nothing twice
Source
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends the requested notice on the day of the request
05 Failed gating notices prevent destructionapinegativetest
Proves
BR-CAP-PFM-TNL-015-05
Preconditions
A required notice has failed and another fixture is environment-suppressed.
Steps
Advance schedules beyond eligibility.
Expected
Failure continues waiting with the notice identified, while suppression satisfies the gate.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#still lists a failed notice, so a send that never worked never lets a tenant be deleted
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a seven-day reminder that was never sent: only two kinds gate destruction
Source
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced

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