Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-013Schedule deliberate workspace deletion: Acceptance Test Set

Markdown

ATS-PFM-TNL-013

Schedule deliberate workspace deletion: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-013

KindAcceptance test setProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Test Scenarios

10 scenarios proving CAP-PFM-TNL-013; 10 bound to an existing test.

01 Customer authority cannot request removalapinegativetest
Proves
BR-CAP-PFM-TNL-013-01
Preconditions
An eligible disabled workspace is available.
Steps
Request deletion as customer-admin and non-staff identities.
Expected
No deletion request is recorded.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted
02 Confirmation rejects stale or mistaken decisionsapinegativetest
Proves
BR-CAP-PFM-TNL-013-03
Preconditions
Staff have read a disabled workspace.
Steps
Submit wrong-name, identifier-as-name, short-reason and stale-version variants.
Expected
Each refuses and name errors identify the confirmation input.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#names the confirmation in that refusal, so the person knows what to type
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a confirmation that repeats the tenant id, which is no longer what the person types
Source
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400
03 Ineligible workspace removal is refusedapinegativetest
Proves
BR-CAP-PFM-TNL-013-04
Preconditions
Fixtures cover enabled, outgoing, locked, parent and protected workspaces.
Steps
Request deletion for each.
Expected
The refusal identifies the failed condition and records no new protected-workspace request.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a well-known tenant the whole development environment is built on
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first
04 Database and service prevent duplicate requestsapinegativetest
Proves
BR-CAP-PFM-TNL-013-05
Preconditions
The workspace has an open request.
Steps
Request another and attempt a direct duplicate insert.
Expected
Both refuse and one open request remains.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#refuses a second open request for the same tenant, by the index and not only by the service
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open
05 Cancellation is retained rather than revivedapitest
Proves
BR-CAP-PFM-TNL-013-06
Preconditions
An earlier request is cancelled.
Steps
Request deletion again.
Expected
A new date and request are recorded beside the cancelled history.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled
06 Standard wait honors the Production floorunittest
Proves
BR-CAP-PFM-TNL-013-07
Preconditions
Waiting-period inputs exercise default and configured values.
Steps
Compute eligibility for ordinary workspaces.
Expected
Default is thirty days; Production rejects thirteen and accepts fourteen 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#refuses a configured period below fourteen days rather than quietly raising it
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#accepts exactly fourteen days (the boundary, the negative control)
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#fixes the date destruction may begin, thirty days on by the calendar of the tenant zone
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request
07 No first activation selects the one-day pathunittest
Proves
BR-CAP-PFM-TNL-013-08
Preconditions
The workspace has no first-activation record.
Steps
Compute eligibility inside and outside Production.
Expected
Both calculations select one day.
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#waits one day in Production too, where the fourteen-day floor does not apply to it
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it
08 Disposable acceleration is environment-limitedunitnegativetest
Proves
BR-CAP-PFM-TNL-013-09
Preconditions
Fixtures include disposable and ordinary workspaces in Production and outside it.
Steps
Request reduced waiting periods.
Expected
Only disposable non-Production fixtures use the minute path.
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#waits ten minutes outside Production, so an automated test can watch a whole deletion
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused a period longer than the configured one, so the field can only shorten
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused for a tenant that is not disposable, rather than ignored
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses the disposable path in Production, where no tenant is disposable
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion
09 Request and watcher are recorded togetherapitest
Proves
BR-CAP-PFM-TNL-013-10
Preconditions
Staff confirm an eligible disabled workspace.
Steps
Submit the deletion decision.
Expected
The scheduled request, copied identities, notice obligations, pending lifecycle and watcher job are recorded.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#moves the tenant to deletion_pending, read back through the tenants API
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone
10 Failed-build disposal uses its shorter waitapitest
Proves
AS-JNY-PFM-TNL-002-03
Preconditions
The recovery journey includes a never-opened failed build.
Steps
Request its deletion after disabling it.
Expected
The recorded request becomes eligible a day later.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day

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