pporto/opportunities-extension
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

Optimized requests to retrieve SRs and Actions

Browse Source
This commit is contained in:
Paulo Porto
2026-09-25 11:08:02 -03:00
parent 86973f7542
commit 6a3e9e6adf
14 changed files with 294 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@@ -27,7 +27,7 @@ If identity or roles cannot be validated, only these two features stay disabled;
other opportunity features continue. Reload the page to refresh identity/roles.
The unused identity token is discarded and redacted from debug responses.
Once per opening of the opportunities modal, `resquestCrmServiceRequest` fetches all pages of
After a completed product-loading cycle with fresh API results, `resquestCrmServiceRequest` fetches all pages of
`CRMServiceRequest` records with `SVC_PENDING_DELIVERY` and `ORA_SVC_MY_SR_TEAM_SRS`,
using the existing general tokenrelay Bearer. It uses the Fusion `searchResources/latest`
query endpoint, independently of the opportunity query version. Calls appear in
@@ -37,22 +37,25 @@ Records are linked by `OpportunityName_Id_c.OptyNumber`. A green SR badge indica
one or more matches; its tooltip lists each SR number, title, reported hours, owner,
email and contact flags. A red badge indicates no match within that query's scope.
A failed lookup shows `SR ?`, not a false no-match result, and opportunities still load.
Badges follow Ramp Months and do not wait for product downloads. SR results remain
in memory only. Reference changes share the in-flight lookup and reuse its result
(including failures) without another request. Closing resets this state; reopening
starts a fresh lookup, and responses from previous openings are ignored.
Badges follow Ramp Months. SR results remain in memory only. CRM SR and Actions
refresh only after actual successful product API requests, not cache reads.
Cache-only, empty and entirely failed cycles neither query nor clear activities.
In mixed cycles, Actions refreshes only workloads from fresh products and CRM SR
refreshes once. Closing and reopening the modal preserves results and does not
reload products or trigger these lookups. Already-running product requests may
finish in the background and update their related activities.
## Workload Actions
Workload Actions are queried in the background after product results arrive,
including cached products. Each distinct `RevnId` uses `requestWlActions` with
Workload Actions are queried in the background after the product cycle completes,
using only fresh API results. Each distinct `RevnId` uses `requestWlActions` with
the `WWB-TS` credential in `Wwb-Provider-Authorization`. The Act badge beside SR
aggregates all products: green means an action's `owner` matches the general
tokenrelay response's `principal`; red means no matching owner was found. `Act ?`
means ownership could not be confirmed (including a missing principal). Tooltips
retain all returned actions, regardless of owner. Principal stays in memory only.
Queries are shared per modal opening (up to four concurrently), reused
across Reference changes, and discarded on close. Reopening queries again.
Queries are shared per product cycle (up to four concurrently). Reference changes
that load products from cache do not refresh activities.
Only the first page is requested for now; `hasNext` is indicated in the tooltip.
The debug panel groups these requests under Actions, with credentials masked.