Repository navigation
ux(home): Account filter doesn't affect Home page Savings-over-time graph (data identical across accounts) #498
Description
Repro
On the Home page (the top-level dashboard, not Opportunities):
- Open the Account filter dropdown in the top-bar.
- Switch the selected Account one at a time, going through every available account.
- Observe the Savings over time chart (and any other graphs) at the top of the page.
Expected
KPIs and graphs re-query and re-render so they show data for only the selected account.
Actual
"The potential Savings graph shows the same data for each account. Can't confirm if data itself is correct."
The Home page graph renders identical data for every account selection — the account filter does not appear to affect the data flowing into the graph at all. (Provider filter is similarly unreliable per row 2.2 — see Notes.)
Why this matters
The data on the Home page is the first thing users see. If the Account filter silently no-ops, users can be looking at a graph they believe represents one account while it actually aggregates across all accounts — that's misleading data on the most-visible surface.
Relationship to #477
#477 fixed an analogous bug on the Opportunities page (provider/account filter changes didn't re-render the list). PR #488 wired up state subscribers + URL persistence there. The Home page likely needs the equivalent wiring on its own chart/KPI render path — the chart subscriber should fire load(...) for the selected provider+account on every chip change, not just on initial route enter.
Suggested fix path:
- Find the Home page chart's data load function (likely a
loadHomeSavingsChart()or similar). - Subscribe to
state.subscribeProviderandstate.subscribeAccountfrom the chart module's init. - Each callback fires the chart's data load only when the Home tab is active.
- Persist filter state to URL params (matches PR fix(ux/opportunities): re-query on filter change and persist to URL #488's pattern, gives shareable links).
- Add regression tests that fire a chip change and assert the chart re-queries.
QA reference
Home page sheet, row 8 (step 2.3).
Provider-filter caveat (row 2.2)
Row 2.2 (Provider filter) reports "graph adjusts. Can't confirm if data itself is correct." — the symptom there is less clearly broken (the graph at least changes shape), but a re-test once the account filter is fixed would tell us whether the provider path is sound.
Activity
fix(ux/home): re-query Savings-over-time chart on filter chip change
cristim commentedon May 28, 2026
Verification: shipped in PR #747 (SHA 3931e9e, merged 2026-05-27). dashboard.ts wires subscribeAccount/subscribeProvider to scheduleDashboardReload; loadSavingsTrendChart passes account_ids and provider to the analytics call. Confirmed present on origin/feat/multicloud-web-frontend.
fix(config/store): match purchase history on account UUID AND externa…
fix(api): filter purchases/analytics/inventory by account UUID AND ex…
test(api): cover dual-column account filtering across history/analyti…
fix(api): filter purchases by account UUID AND external id (closes #701…
fix(dashboard): apply provider filter to savings-history chart (refs #…
fix(api): compute active commitments via uncapped SQL active-only read
fix(api): compute active commitments via uncapped SQL active-only read
fix(api): compute active commitments via uncapped SQL active-only read
fix(api): compute active commitments via uncapped SQL active-only read
fix(api): filter purchases by account UUID AND external id (closes #701…