Rhythm 2.0 Specifications

Appearance

ATS-PFM-CSH-016Refresh application choices when access changes: Capability Test Specification

Markdown

ATS-PFM-CSH-016

Refresh application choices when access changes: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-CSH-016

Design

Executed by
TST-PFM-CSH-011, TST-PFM-CSH-030

KindAcceptance test setProduct areaPlatformModuleConsole Shell and NavigationRevision3

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

Refresh application choices when access changes: 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-016-01ATS-PFM-CSH-016-01, ATS-PFM-CSH-016-02, ATS-PFM-CSH-016-09
BR-CAP-PFM-CSH-016-02ATS-PFM-CSH-016-02
BR-CAP-PFM-CSH-016-03ATS-PFM-CSH-016-03, ATS-PFM-CSH-016-08
BR-CAP-PFM-CSH-016-04ATS-PFM-CSH-016-05
BR-CAP-PFM-CSH-016-05ATS-PFM-CSH-016-06, ATS-PFM-CSH-016-07
BR-CAP-PFM-CSH-016-06ATS-PFM-CSH-016-04

Refresh coverage needs the exact five-minute endpoint, hidden tabs, failures, shared requests, narrow replacement, HQ no-op and superseded successful timestamps. A second workspace can share the previous workspace’s pending read; that race remains unexecuted.

The refreshed sidebar removes CRM and retains Membership without a page reload.

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

Test Scenarios

9 scenarios proving CAP-PFM-CSH-016; 3 bound to an existing test.

01 A coded refusal refreshes offered applicationsinteractionbrowsertest
Proves
BR-CAP-PFM-CSH-016-01
Preconditions
CRM and Membership are offered before mock CRM requests begin failing.
Steps
Navigate to Tasks to trigger the application-refusal signal.
Expected
The refreshed sidebar removes CRM and keeps Membership visible.
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#brings the launcher up to date instead of leaving it offering what is gone
02 Only recognized application refusals notify listenersvalidationunitnegativetest
Proves
BR-CAP-PFM-CSH-016-01 BR-CAP-PFM-CSH-016-02
Preconditions
Error fixtures cover both application codes and unrelated failures.
Steps
Classify the errors and publish them to subscribed listeners.
Expected
Recognized codes notify each active listener once; unrelated failures produce no application notification.
Data
Independent fixture inputs for the variants listed in this case.
Bound to
Source
react-console:lib/security-context/application-refusal.test.ts#reads the two application codes off a 403
03 An aged returning tab requests new application databoundaryunitproposed
Proves
BR-CAP-PFM-CSH-016-03
Preconditions
The tab’s recorded application timestamp is six minutes old.
Steps
Bring the visible tab back to the foreground.
Expected
The provider requests an application refresh.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:lib/security-context/provider.tsx:SecurityContextProvider
04 A late refresh cannot install the previous workspace’s listconcurrencyunitnegativeproposed
Proves
BR-CAP-PFM-CSH-016-06
Preconditions
An application read remains pending while another workspace is entered.
Steps
Complete the old read after the workspace change.
Expected
The new workspace’s held application list is not replaced by the superseded response.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:lib/security-context/provider.tsx:refreshApplications
05 A narrow refresh retains the other access snapshotsinvariantbrowserproposed
Proves
BR-CAP-PFM-CSH-016-04 INV-DOM-PFM-CSH-004-04
Preconditions
Roles, rules and reachable workspaces are distinctive; the next answer changes all fields.
Steps
Complete an application refresh and compare each held field.
Expected
Applications and features change while roles, rules and reachable workspaces remain the earlier snapshot.
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-016-keep-the-menu-current-when-what-a-person-may-open-changes.md
06 Failed refresh keeps the list and its old timestampfailurebrowserproposed
Proves
BR-CAP-PFM-CSH-016-05
Preconditions
The held application list has an aged timestamp.
Steps
Reject a refresh and regain focus again.
Expected
The list remains usable without a dedicated error screen; the aged timestamp permits another focus refresh.
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-016-keep-the-menu-current-when-what-a-person-may-open-changes.md
07 Overlapping refresh triggers share the pending readconcurrencybrowserproposed
Proves
BR-CAP-PFM-CSH-016-05
Preconditions
A refresh remains unresolved in the current workspace.
Steps
Trigger application refusal, focus and an explicit refresh before answering.
Expected
Only one read is in flight and all callers await that request; its completion releases the next refresh.
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-016-keep-the-menu-current-when-what-a-person-may-open-changes.md
08 The five-minute refresh threshold includes its endpointboundarybrowserproposed
Proves
BR-CAP-PFM-CSH-016-03
Preconditions
The provider clock is controlled and the tab is visible.
Steps
Dispatch focus at just under five minutes and at exactly five minutes; repeat while hidden.
Expected
The recent and hidden cases make no read; the visible threshold case requests applications.
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-016-keep-the-menu-current-when-what-a-person-may-open-changes.md
09 A coded refusal changes the menu in the same sessioninteractionbrowsertest
Proves
BR-CAP-PFM-CSH-016-01 BR-CAP-PFM-CSH-006-02
Preconditions
CRM and Membership are visible before CRM authority is withdrawn.
Steps
Trigger a mocked application refusal through Tasks.
Expected
The refreshed sidebar removes CRM and retains Membership without a page reload.
Data
A fresh browser context, isolated account fixtures and controlled responses for the listed transitions.
Bound to
Source
react-console:e2e/mock/application-access.mock.spec.ts#brings the launcher up to date instead of leaving it offering what is gone

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