Skip to content

ATS-PFM-OPS-014Resolve a workspace’s application availability: Capability Test Specification

Markdown

ATS-PFM-OPS-014

Resolve a workspace’s application availability: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-OPS-014

Design

Executed by
TST-PFM-OPS-110, TST-PFM-OPS-112

KindAcceptance test setProduct areaPlatformModuleOperational RecordsRevision2

Read atservices-platform ad3f6a65macroservice-libraries 54536a44react-console baf6dae3

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-PFM-OPS-066
  • Permission not-applicable
  • Edge covered
  • Failure gap: FND-PFM-OPS-066
  • Boundary covered
  • Concurrency gap: FND-PFM-OPS-066
  • Invariant covered
  • Interaction covered

Test Scenarios

15 scenarios proving CAP-PFM-OPS-014; 10 bound to an existing test.

01 Resolve the expected available setruleunittest
Proves
BR-CAP-PFM-OPS-014-01 INV-DOM-PFM-OPS-004-04
Preconditions
Always-available and licensed applications have mixed operational states.
Steps
Resolve workspace availability.
Expected
Only the expected application set is available.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#answers the available ones, and only those, from the same resolution
02 Let an explicit withhold prevailinvariantunitnegativetest
Proves
BR-CAP-PFM-OPS-014-02 INV-DOM-PFM-OPS-003-05
Preconditions
A grant, contract and withhold are effective together.
Steps
Resolve with different input ordering.
Expected
The withhold remains the governing refusal.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#lets a withhold beat a window covering today, the one way to take a bought application away
03 Apply term and grace boundariesboundaryunittest
Proves
BR-CAP-PFM-OPS-014-03
Preconditions
Contract windows ended recently, ended beyond grace or begin tomorrow.
Steps
Resolve today’s availability.
Expected
Current grace remains eligible, elapsed coverage expires and future coverage grants nothing yet.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#answers expired the day after the grace ends, which is when a licence really runs out
04 Prefer current coverage and use a later grant fallbackruleunittest
Proves
BR-CAP-PFM-OPS-014-04
Preconditions
Current and expired windows exist, followed by an expired-only case with a grant.
Steps
Resolve both cases.
Expected
The first reports contract coverage and the second override coverage.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#falls back to a grant override once the contract has expired, which is a goodwill extension
05 Preserve always-available access unless withheldedgeunittest
Proves
BR-CAP-PFM-OPS-014-05
Preconditions
An always-available application failed preparation and later receives a withhold.
Steps
Resolve before and after the decision.
Expected
Failed readiness alone preserves availability while the withhold removes it.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#lets a withhold beat always_available, which is the only way to take one of those away
06 Explain each unavailable result onceruleunittest
Proves
BR-CAP-PFM-OPS-014-06 INV-DOM-PFM-OPS-004-07
Preconditions
Applications have each commercial and operational refusal state.
Steps
Resolve them.
Expected
Each unavailable result contains its governing refusal reason.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#gives each unavailable one the reason its own half of the rule refused by
07 Use the replacement commercial keyruleunittest
Proves
BR-CAP-PFM-OPS-014-09
Preconditions
The grant map contains the renamed accounting application.
Steps
Inspect mapped application keys.
Expected
Accounting is granted and the retired key is absent from grants.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/catalog/product-grants.spec.ts#grant `accounting` and never the retired `collect`, which is the rename of 2026-10-13
08 Restore contract coverage after withdrawing a withholdinteractionapiproposed
Proves
BR-CAP-PFM-OPS-011-04 BR-CAP-PFM-OPS-014-02
Preconditions
An enabled application has current contract coverage and an effective withhold.
Steps
Resolve access, withdraw the withhold, and resolve again.
Expected
The commercial source of the restored result is the surviving contract.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:modules/licensing/tests/e2e/licensing.e2e.spec.js#refuses to withdraw the same override twice, with 409; services-platform:modules/licensing/services/availability/application-availability.ts:licenceStateOf; CAP-PFM-OPS-011; WF-PFM-OPS-016
09 Reflect a cancellation without extending stale coverageinteractionapiproposed
Proves
BR-CAP-PFM-OPS-012-08 BR-CAP-PFM-OPS-014-01
Preconditions
A company has current windows and an enabled workspace application.
Steps
Fail one provider read, then successfully synchronize a cancelled contract and resolve availability.
Expected
The failed read preserves the earlier copy; the successful cancellation removes its contribution to access.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:modules/licensing/tests/integration/services/sync/sync-company-licences.integration.spec.js#changes no snapshot, no window and no last success; services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#answers the available ones, and only those, from the same resolution; CAP-PFM-OPS-012; WF-PFM-OPS-016
10 Separate licensing from operational resumptioninteractionapiproposed
Proves
BR-CAP-PFM-OPS-014-01 BR-CAP-PFM-OPS-015-02
Preconditions
A licensed application is enabled, then suspended by staff.
Steps
Resolve it before suspension, during suspension and after resumption.
Expected
The commercial standing remains traceable while availability follows the operational change.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#answers the available ones, and only those, from the same resolution; services-platform:modules/licensing/tests/integration/services/enablement/provision-tenant-application.integration.spec.js#refuses every move for an application the tenant has never been provisioned for; CAP-PFM-OPS-015; WF-PFM-OPS-016
11 Keep application availability separate from personal authorityinteractionapiproposed
Proves
BR-CAP-PFM-OPS-014-08
Preconditions
A licensed ready application is available to the workspace but the person lacks its application authority.
Steps
Read workspace standing and request a protected action as that person.
Expected
The standing read does not itself grant the person permission to use a protected action.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:docs/licensing.md#9. How a licence reaches the permission check; CAP-PFM-SEC-007; WF-PFM-OPS-016
12 Observe an access change across cache refreshinteractionapiproposed
Proves
BR-CAP-PFM-OPS-014-08
Preconditions
An application decision changes while an older authorization answer remains cached.
Steps
Complete the change, observe the requested refresh job, then request a new access decision.
Expected
The refresh request refers to the changed scope; access reflects the current decision after refresh or expiry.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:docs/licensing.md#9. How a licence reaches the permission check; CAP-PFM-SEC-015; WF-PFM-OPS-016
13 Read commercial standing across a term and gracetransitionunittest
Proves
BR-CAP-PFM-OPS-014-03 INV-DOM-PFM-OPS-003-06
Preconditions
A finite window has a first day, last covered day and last grace day.
Steps
Resolve standing at the first day, immediately after the term, and immediately after grace.
Expected
The clock moves the explanation from current coverage through grace to expired coverage.
Data
Run-owned records and controlled clocks or dependency responses named in the preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#a licence window, read against a day
14 Resolve an empty application registryedgeunittest
Proves
BR-CAP-PFM-OPS-014-01
Preconditions
The resolver receives no registered applications.
Steps
Resolve workspace availability with the empty registry.
Expected
Both the application results and the available set are empty.
Data
Run-owned records and controlled clocks or dependency responses named in the preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#answers nothing at all for a registry with no applications in it
15 Keep HQ available outside workspace application recordsinvariantunittest
Proves
BR-CAP-PFM-OPS-014-05 INV-DOM-PFM-OPS-004-08
Preconditions
HQ has no workspace application catalogue or operational row.
Steps
Evaluate the by-rule availability decision for HQ and for registered workspace applications.
Expected
Only HQ receives the separate by-rule result.
Data
Run-owned records and controlled clocks or dependency responses named in the preconditions.
Bound to
Source
services-platform:modules/licensing/tests/unit/availability/application-availability.spec.ts#is Rhythm HQ and nothing else

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.