2.8 KiB
Purpose
Preserve user preferences and reuse eligible data without allowing expired or invalidated results to silently replace fresh information.
ADDED Requirements
Requirement: Preferences survive reopening
The extension SHALL persist supported filter preferences, theme, opportunity type selections and cache duration in the browser profile. Invalid or unavailable stored values SHALL fall back to usable defaults or in-memory state.
Scenario: Stored preference cannot be read
- WHEN browser storage is unavailable or a saved preference is invalid
- THEN the extension remains usable with its fallback rather than failing to open
Requirement: Sort preferences belong to individual tables
Supported sortable tables SHALL retain their own last sort key and direction without changing other tables' preferences. Product detail tables SHALL remain excluded from this sorting behavior.
Scenario: Two tables use different sorts
- WHEN the user sorts Installed Base by amount and contact opportunities by close date
- THEN reopening each table restores its own saved ordering
Requirement: Cache reuse respects validity and identity boundaries
Product, workload and activity caches SHALL apply their configured lifetimes and existing identity/account/product-update scopes. A missing or expired activity cache SHALL not be represented as a confirmed empty result.
Scenario: Workload token rotates
- WHEN the same user's account workload data is still valid but the authorization token changes
- THEN the account data can be reused without treating the token string as a different customer identity
Requirement: Only eligible reads are reused
Form request caching SHALL reuse only known read operations, share concurrent reads and invalidate applicable entries after successful writes. Create, update and delete operations SHALL not be served from a response cache.
Scenario: Repeated write
- WHEN the user explicitly submits a new valid write operation
- THEN the operation goes through the write transport rather than returning a cached success
Requirement: Refresh all invalidates reusable data safely
Refresh all SHALL invalidate product/activity and related cached data before reloading the active Reference, preserve user preferences and authentication, and prevent pre-invalidation responses from repopulating invalidated cache entries. Cache invalidation errors SHALL be reported.
Scenario: Old product request finishes after refresh
- WHEN an old request completes after its cache has been invalidated
- THEN its result does not restore the invalidated cache snapshot
Scenario: Activity updates arrive
- WHEN only background activity lookup results change
- THEN those lookups do not independently advance the product Last update timestamp