Rhythm 2.0 Specifications

Appearance

ATS-PFM-CSH-017Understand the workspace’s application availability: Capability Test Specification

Markdown

ATS-PFM-CSH-017

Understand the workspace’s application availability: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-CSH-017

Design

Executed by
TST-PFM-CSH-007, TST-PFM-CSH-011, TST-PFM-CSH-016, TST-PFM-CSH-035

KindAcceptance test setProduct areaPlatformModuleConsole Shell and NavigationRevision3

Read atreact-console baf6dae3services-platform ad3f6a65rhythm-v2-docs 25e253cb

Understand the workspace’s application availability: Capability Test Specification ​

Coverage ​

The coverage map describes specified proof, not a passing run. Each mandatory rule below has a scenario or an explicit finding; a proposed scenario remains an execution obligation even when its expected outcome follows the pinned implementation.

Mandatory RuleScenarios or Finding
BR-CAP-PFM-CSH-017-01ATS-PFM-CSH-007-07, ATS-PFM-CSH-015-07, ATS-PFM-CSH-017-12
BR-CAP-PFM-CSH-017-02ATS-PFM-CSH-017-02, ATS-PFM-CSH-017-03
BR-CAP-PFM-CSH-017-03ATS-PFM-CSH-017-02, ATS-PFM-CSH-017-03, ATS-PFM-CSH-017-04
BR-CAP-PFM-CSH-017-04ATS-PFM-CSH-017-02
BR-CAP-PFM-CSH-017-05ATS-PFM-CSH-017-07
BR-CAP-PFM-CSH-017-08ATS-PFM-CSH-017-05
BR-CAP-PFM-CSH-017-09ATS-PFM-CSH-017-08
BR-CAP-PFM-CSH-017-10ATS-PFM-CSH-017-09
BR-CAP-PFM-CSH-017-11ATS-PFM-CSH-017-06
BR-CAP-PFM-CSH-017-12ATS-PFM-CSH-017-10, ATS-PFM-CSH-017-13
BR-CAP-PFM-CSH-017-13ATS-PFM-CSH-017-11
BR-CAP-PFM-CSH-017-14ATS-PFM-CSH-017-01

Overview coverage needs view authority, first-load progress, retry, empty results, malformed availability, destination-link eligibility, cached-data error suppression and disabled-workspace reads. Customer redaction is tested separately from organization-level availability wording.

The available row offers navigation and the destination refuses missing task authority; the unavailable row offers no configuration link.

The interaction rows cite the contracts they exercise. Related combinations without a complete case remain in the coverage finding, together with cross-capability workflows and permission boundaries. A helper assertion is bound only for its stated outcome; the full browser handoff remains proposed until a suite checks it.

Pinned source and exact test anchors are recorded in frontmatter. Test bindings record static assertion review and use the executable-suite register; no product test result is inferred from that review. The prior planning and design examinations supply context, while this continuation records the remaining proof obligations explicitly.

Coverage

  • Rule covered
  • Transition gap: FND-PFM-CSH-067
  • Validation covered
  • Permission gap: FND-PFM-CSH-067
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-PFM-CSH-067
  • Invariant gap: FND-PFM-CSH-067
  • Interaction gap: FND-PFM-CSH-067

Test Scenarios

14 scenarios proving CAP-PFM-CSH-017; 8 bound to an existing test.

01 The customer API separates three authority outcomespermissionapinegativetest
Proves
BR-CAP-PFM-CSH-017-14
Preconditions
Signed fixtures include an administrator and a caller without the read key; a third call is anonymous.
Steps
Request the workspace application list with each fixture.
Expected
The administrator receives the list; the missing-key and anonymous callers receive forbidden and unauthenticated responses.
Data
The listed signed caller scopes and local application fixtures in the prepared test database.
Bound to
Source
services-platform:modules/licensing/tests/e2e/licensing.e2e.spec.js#serves an administrator of the customer holding platform.tenant-applications.read
02 Sorting and explanation retain readable application statesruleunittest
Proves
BR-CAP-PFM-CSH-017-02 BR-CAP-PFM-CSH-017-03 BR-CAP-PFM-CSH-017-04
Preconditions
Input fixtures cover available applications, unavailability causes and an ending licence.
Steps
Sort them and compute labels and explanations.
Expected
Available applications lead name-ordered groups; reasons are sentences, codes stay hidden and an ending licence retains availability.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/applications/availability.test.ts#lists the available applications first, then by name
03 The overview explains its demonstration fixture rowsinteractionbrowsertest
Proves
BR-CAP-PFM-CSH-017-02 BR-CAP-PFM-CSH-017-03 AS-JNY-PFM-CSH-005-03
Preconditions
The demonstration list includes CRM, Orders, Meetings, Certifications and Membership.
Steps
Open the customer Applications overview.
Expected
The checked rows identify availability, suspension, setup, no licence and an ending licence respectively.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Bound to
Source
react-console:e2e/mock/application-access.mock.spec.ts#the Applications page says which applications there are and why one cannot be used
04 The development overview displays customer-facing state labelsrulebrowsertest
Proves
BR-CAP-PFM-CSH-017-03
Preconditions
A development administrator can read a fixture with an available product.
Steps
Open the customer’s Applications overview.
Expected
The target row says Available, several products are listed and raw enum tokens are absent.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Bound to
Source
react-console:e2e/dev/hq-licensing.dev.spec.ts#the tenant's own administrator reads Configuration › Applications with the same words
05 Initial progress, failure and emptiness have usable statesfailurebrowsernegativeproposed
Proves
BR-CAP-PFM-CSH-017-08
Preconditions
Independent overview fixtures delay the first answer, fail it or return no entries.
Steps
Open the page for each fixture and inspect its body.
Expected
The respective presentations provide progress, retry after failure and the empty-list explanation.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Source
services-platform:modules/licensing/tests/e2e/licensing.e2e.spec.js#refuses a console user who does not hold that key, with 403
06 Missing availability retains the current permissive defaultedgeunitnegativeproposed
Proves
BR-CAP-PFM-CSH-017-11
Preconditions
One keyed input omits availability and has unreadable states; another sets availability to false.
Steps
Parse both application records.
Expected
The incomplete input is considered available while exactly false remains unavailable.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:lib/applications/types.ts:parseTenantApplication
07 Licence dates keep the supplied calendar dayboundaryunittest
Proves
BR-CAP-PFM-CSH-017-05
Preconditions
The formatter loads in a time zone behind UTC.
Steps
Format the fixture licence dates after loading in that zone.
Expected
Displayed dates preserve the calendar day sent by Platform.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/applications/availability.test.ts#reads a licence date as the day Platform sent it, in a zone behind UTC
08 Parser fallback excludes unidentifiable entriesvalidationunitnegativetest
Proves
BR-CAP-PFM-CSH-017-09
Preconditions
The collection includes a missing key and unknown licence and operation states.
Steps
Parse the application records.
Expected
Entries without readable keys disappear; unfamiliar states resolve to unlicensed and not set up.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/applications/availability.test.ts#takes the records it understands and leaves out the ones it does not
09 Overview navigation requires its view grantpermissionunitnegativeproposed
Proves
BR-CAP-PFM-CSH-017-10
Preconditions
Navigation fixtures include and omit the application-view key.
Steps
Assemble the Configuration application links.
Expected
The permitted overview entry leads those links; the fixture without authority omits it.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:components/console/nav-config.ts:configurationArea
10 Disabled-workspace reads retain the customer reach boundaryboundaryapinegativeproposed
Proves
BR-CAP-PFM-CSH-017-12
Preconditions
A disabled workspace is requested by its permitted administrator and an unrelated customer.
Steps
Read the application list under both signed scopes.
Expected
The reachable administrator receives the list; the unrelated customer receives not found.
Data
The listed signed caller scopes and local application fixtures in the prepared test database.
Source
services-platform:modules/tenants/aws/api/tenant-applications.routes.ts:tenantApplicationsRoutes
11 Customer API facts omit staff and commercial detailinvariantapitest
Proves
BR-CAP-PFM-CSH-017-13
Preconditions
Local fixtures establish a grant, withholding and suspension with a staff-authored reason.
Steps
Read the application API as the customer administrator after each fixture.
Expected
Application facts remain while overrides, staff identities and staff reasons are excluded; withholding appears as unlicensed.
Data
The listed signed caller scopes and local application fixtures in the prepared test database.
Bound to
Source
services-platform:modules/licensing/tests/e2e/licensing.e2e.spec.js
12 The overview destination requires console view authoritypermissionbrowsernegativeproposed
Proves
BR-CAP-PFM-CSH-017-01
Preconditions
Two workspace sessions differ only in application-view authority.
Steps
Open Configuration home directly in both sessions.
Expected
The permitted session reads the overview; the other receives its console permission explanation.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Source
react-console:components/configuration/applications/tenant-applications.tsx:TenantApplications; lib/authz/backend-aliases.ts:BACKEND_ALIASES
13 The same read key reaches only the caller’s customerboundaryapinegativetest
Proves
BR-CAP-PFM-CSH-017-12 INV-DOM-PFM-CSH-004-07
Preconditions
Signed callers hold the list-read key in two different customer scopes.
Steps
Request the fixture workspace as its administrator and as the other customer’s administrator.
Expected
The owner receives the list; the unrelated customer receives not found without disclosure of the workspace.
Data
Run-owned API fixtures and caller grants in the prepared local test database.
Bound to
Source
services-platform:modules/licensing/tests/e2e/licensing.e2e.spec.js#serves an administrator of the customer holding platform.tenant-applications.read
14 Overview configuration links defer destination authorizationinteractionbrowserproposed
Proves
BR-CAP-PFM-CSH-017-06 BR-CAP-PFM-CSH-017-07 BR-CAP-PFM-CSH-015-03
Preconditions
An available application has a known configuration page but the person lacks that page’s key.
Steps
Open the overview, select Open Configuration, then repeat for an unavailable application.
Expected
The available row offers navigation and the destination refuses missing task authority; the unavailable row offers no configuration link.
Data
A fresh browser context, isolated account fixtures and controlled responses for the listed transitions.
Source
rhythm-v2-docs:specs/platform/console-shell/planning/capabilities/CAP-PFM-CSH-017-see-which-applications-the-organization-has-and-why-one-is.md

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