Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-004Prepare the customer’s first access and sender: Acceptance Test Set

Markdown

ATS-PFM-TNL-004

Prepare the customer’s first access and sender: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-004

KindAcceptance test setProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Test Scenarios

9 scenarios proving CAP-PFM-TNL-004; 9 bound to an existing test.

01 Existing customers receive no first-admin invitationapinegativetest
Proves
BR-CAP-PFM-TNL-004-01
Preconditions
The request names a person for an existing customer.
Steps
Complete provisioning.
Expected
No first-administrator invitation is sent.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites nobody when the request did not create the customer
02 New-customer invitation establishes the intended roleapitest
Proves
BR-CAP-PFM-TNL-004-02
Preconditions
A new customer request names its first administrator.
Steps
Run the administration participant.
Expected
One invited console identity receives customer-scoped Administrator authority and one invitation.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#grants that user the Administrator role at the customer, waiting on their acceptance
services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#grants the built-in Administrator role, by the product key the catalog publishes it under
Source
services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#leaves an invited console user of the customer holding the address
03 Administration invitation survives retryapitest
Proves
BR-CAP-PFM-TNL-004-03
Preconditions
The original build recorded its administrator invitation.
Steps
Repeat the provisioning work.
Expected
The ledger retains that invitation without a second send.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites them once, and records the invitation in the ledger
04 Unusable administration authority is refusedunitnegativetest
Proves
BR-CAP-PFM-TNL-004-04
Preconditions
Existing identities exercise suspension, incorrect role or scope and ineffective validity periods.
Steps
Attempt to adopt each identity.
Expected
Each incompatible state reports a refusal that directs staff toward correction.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses a SUSPENDED user, whatever they hold: an administrator nobody can use is none
services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses when the grant is of another role, which administers nothing
services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses when the Administrator grant is at tenant scope rather than the customer’s own
services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#refuses the job rather than reporting an administrator the customer does not have
Source
services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses a SUSPENDED user, whatever they hold: an administrator nobody can use is none
05 Invalid sender inputs retain no workspaceapinegativetest
Proves
BR-CAP-PFM-TNL-004-05
Preconditions
Sender variants violate strategy, domain or address requirements.
Steps
Submit each request.
Expected
The response identifies invalid input and creation leaves no workspace.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses the domain strategy without a domain when the tenant has none of its own to lend it
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses a domain under the address strategy, which proves the one mailbox and nothing else
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses an address outside the domain, because an identity proved for one domain may not send as another
Source
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses the domain strategy without a domain when the tenant has none of its own to lend it
06 Hostname identity supplies a sender domainapitest
Proves
BR-CAP-PFM-TNL-004-06
Preconditions
A hostname workspace identifier accompanies a domain strategy with no supplied domain.
Steps
Submit the sender-bearing request.
Expected
The requested identity uses the workspace hostname as its domain.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#proves the tenant’s own domain, because the request left the strategy’s domain to it
Source
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#proves the tenant’s id as the domain, the id being a hostname
07 Pending DNS does not block openingapitest
Proves
BR-CAP-PFM-TNL-004-07
Preconditions
A domain sender request remains unverified.
Steps
Finish construction and inspect its sender.
Expected
The workspace opens while the pending identity exposes required DNS records.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#leaves its sender identity pending, for the customer to finish in their own time
services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the DNS records the customer must publish, so a support person can read them out
Source
services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#opens the tenant anyway, which is what option A promises
08 Portal construction is deferredunittest
Proves
BR-CAP-PFM-TNL-004-09
Preconditions
The portal participant receives a workspace with recorded portal interest.
Steps
Invoke provisioning.
Expected
The response is not applicable and no pool is built.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
services-platform:modules/tenants/tests/unit/services/lifecycle/participants.spec.js#creates nothing when a tenant is provisioned, because the pool is built when Websites is enabled
Source
services-platform:modules/tenants/tests/unit/services/lifecycle/participants.spec.js#creates nothing when a tenant is provisioned, because the pool is built when Websites is enabled
09 First access and sender setup coexistapitest
Proves
AS-JNY-PFM-TNL-001-04
Preconditions
The new-customer journey includes an administrator and domain sender.
Steps
Complete its provisioning fixture.
Expected
The invitation is recorded once and the workspace opens with verification pending.
Data
Use the workspace, caller and collaborator fixtures declared by the bound tests.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites them once, and records the invitation in the ledger

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