Rhythm 2.0 Specifications

Appearance

ATS-PFM-CSH-014Apply the workspace and person’s application access: Capability Test Specification

Markdown

ATS-PFM-CSH-014

Apply the workspace and person’s application access: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-CSH-014

Design

Executed by
TST-PFM-CSH-017, TST-PFM-CSH-018, TST-PFM-CSH-023, TST-PFM-CSH-033

KindAcceptance test setProduct areaPlatformModuleConsole Shell and NavigationRevision3

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

Apply the workspace and person’s application access: 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-014-01ATS-PFM-CSH-014-01, ATS-PFM-CSH-014-06, ATS-PFM-CSH-014-12
BR-CAP-PFM-CSH-014-02ATS-PFM-CSH-014-09
BR-CAP-PFM-CSH-014-03ATS-PFM-CSH-014-02
BR-CAP-PFM-CSH-014-04ATS-PFM-CSH-014-03
BR-CAP-PFM-CSH-014-05ATS-PFM-CSH-014-04
BR-CAP-PFM-CSH-014-06ATS-PFM-CSH-014-10
BR-CAP-PFM-CSH-014-07ATS-PFM-CSH-014-05
BR-CAP-PFM-CSH-014-08ATS-PFM-CSH-014-05
BR-CAP-PFM-CSH-014-10ATS-PFM-CSH-014-07
BR-CAP-PFM-CSH-014-11ATS-PFM-CSH-014-08

Context derivation needs all product aliases, shared domains, synthetic keys, explicit denies, scoped grants and feature separation. Permission derivation tests do not establish that each service operation enforces its access key.

Only the enabled and permitted combination opens; application absence precedes task denial.

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 covered
  • Validation covered
  • Permission gap: FND-PFM-CSH-064
  • Edge gap: FND-PFM-CSH-064
  • Failure gap: FND-PFM-CSH-064
  • Boundary covered
  • Concurrency gap: FND-PFM-CSH-064
  • Invariant gap: FND-PFM-CSH-064
  • Interaction gap: FND-PFM-CSH-064

Test Scenarios

12 scenarios proving CAP-PFM-CSH-014; 9 bound to an existing test.

01 Known context products enable only their mapped domainsruleunitnegativetest
Proves
BR-CAP-PFM-CSH-014-01
Preconditions
Context fixtures list selected known products and an unknown product.
Steps
Derive entitlements and inspect application-to-domain coverage.
Expected
Known listed products enable their declared domains; the unknown product adds none and the mapping covers registered domains.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#enables only the domains of the applications the context lists
02 Staff wildcard authority cannot invent a productpermissionunitnegativetest
Proves
BR-CAP-PFM-CSH-014-03
Preconditions
The staff fixture grants wildcard actions and lists CRM alone.
Steps
Derive the enabled application domains.
Expected
CRM is enabled while unlisted product domains remain unavailable.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#gives a staff wildcard no domain the applications did not give
03 Backend grants supply their console aliasesruleunittest
Proves
BR-CAP-PFM-CSH-014-04
Preconditions
The context holds recognized backend permission keys.
Steps
Evaluate the corresponding console checks, including a one-to-many alias.
Expected
Every mapped console check receives the authority supplied by its backend key.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/authz/__tests__/authz.test.ts#maps aliases onto registry keys
04 Synthetic keys depend on an enabled keyless domainvalidationunittest
Proves
BR-CAP-PFM-CSH-014-05
Preconditions
Fixtures enable or omit a keyless domain and deny one of its entries.
Steps
Derive keys for each fixture and compare a domain with backend aliases.
Expected
Enabled keyless items receive their synthetic keys except explicit denials; omitted domains receive none and aliased domains require backend grants.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#grants a keyless domain's item keys when its application is enabled
05 Normalized denial and unknown authority fail closedpermissionunitnegativetest
Proves
BR-CAP-PFM-CSH-014-07 BR-CAP-PFM-CSH-014-08
Preconditions
Fixtures supply exact and prefix grants, an explicit denial and absent entitlements.
Steps
Evaluate the matching permission and page decisions.
Expected
Denial prevails in normalized checks, prefixes cover descendants and absent authority does not satisfy a requested permission.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/authz/__tests__/authz.test.ts#grants exact keys and prefix wildcards, and denies win
06 Removing a context product removes its domaintransitionunitnegativetest
Proves
BR-CAP-PFM-CSH-014-01
Preconditions
Two independent context fixtures differ only by CRM’s presence.
Steps
Derive each fixture’s enabled domains.
Expected
Only the fixture that lists CRM enables its domain.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#takes an application away with the access key that named it
07 Scoped authority opens the surface but limits its recordsboundaryunitnegativetest
Proves
BR-CAP-PFM-CSH-014-10
Preconditions
Fixtures supply one custom-type scope and a separate workspace-wide grant.
Steps
Evaluate the surface, named type and another type under both fixtures.
Expected
The scoped fixture permits its surface and named type only; the workspace-wide grant removes that type restriction.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#holds the key on that object and nowhere else
08 Backend allowed authority survives a stale contrary ruleinvariantunittest
Proves
BR-CAP-PFM-CSH-014-11
Preconditions
The context allows contact read and also contains a stale contrary denial.
Steps
Derive the allowed and denied console-key collections.
Expected
Contact view remains allowed and is excluded from the derived denial set.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/authz/__tests__/backend-aliases.test.ts#lets allowed win over a stale deny rule, because allowed is the authority
09 Product aliases and shared domains follow the context mapruleunittest
Proves
BR-CAP-PFM-CSH-014-02
Preconditions
Contexts list Platform, Collect, Commerce, Events and each Publications provider separately.
Steps
Derive enabled domains from each context.
Expected
The output matches the declared product-to-domain mapping, including each provider of Publications.
Data
Independent in-memory fixtures for each listed input.
Bound to
Source
react-console:lib/security-context/entitlements.test.ts#maps the applications whose Rhythm name is not the console's
10 Derived frame access distinguishes staff and customer contextpermissionunitproposed
Proves
BR-CAP-PFM-CSH-014-06
Preconditions
Context fixtures cover an empty application list, one application, staff identity and an explicit domain-access deny.
Steps
Derive normalized console keys for each fixture.
Expected
Frame access, staff access and domain-access results match the corresponding rule without a wildcard creating an unlisted product.
Data
Independent in-memory fixtures for each listed input.
Source
rhythm-v2-docs:specs/platform/console-shell/planning/capabilities/CAP-PFM-CSH-014-offer-exactly-the-applications-the-workspace-and-the-person.md
11 Feature values remain separate from domain availabilityinvariantunitproposed
Proves
BR-CAP-PFM-CSH-014-09 INV-DOM-PFM-CSH-004-08
Preconditions
The context supplies one feature and omits another.
Steps
Derive entitlements and evaluate both feature keys.
Expected
Only the supplied feature is enabled; its presence supplies no additional product domain.
Data
Independent in-memory fixtures for each listed input.
Source
rhythm-v2-docs:specs/platform/console-shell/planning/capabilities/CAP-PFM-CSH-014-offer-exactly-the-applications-the-workspace-and-the-person.md
12 Application and task authority produce separate page decisionsinteractionbrowserproposed
Proves
BR-CAP-PFM-CSH-014-01 BR-CAP-PFM-CSH-015-01 BR-CAP-PFM-CSH-015-03
Preconditions
CRM availability and contact-view permission vary independently.
Steps
Derive the context entitlements and evaluate the contact page in each combination.
Expected
Only the enabled and permitted combination opens; application absence precedes task denial.
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-014-offer-exactly-the-applications-the-workspace-and-the-person.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