Repository navigation
feat(filters): consistent provider+account dropdown filtering across all main tabs #186
Description
Background
The provider/account dropdown pair is the primary lens our users have onto the data. Today the coverage is uneven across the five main tabs:
| Tab | Provider dropdown | Account dropdown | Refresh-on-change |
|---|---|---|---|
| Dashboard | ✓ | ✓ | ⚠ flaky — see #185 |
| Recommendations | ✗ | per-column filter only (multi-select popover) | column-filter re-renders client-side, no API re-fetch |
| Purchase Plans | ✓ | ✓ | ✓ both wired |
| Purchase History | ✓ | ✓ | ⚠ provider re-populates account list, but neither dropdown's change event triggers loadHistory() — user must hit the date-range Apply button to actually re-query |
| RI Exchange | ✗ | ✗ | n/a |
This means the same operator action ("scope my view to AWS account 1234") behaves differently on every tab, and on Recommendations + RI Exchange isn't even possible without per-column popovers or backend filters.
Acceptance criteria
For every main tab — Dashboard, Recommendations, Purchase Plans, Purchase History, RI Exchange:
- A consistent Provider + Account dropdown pair is rendered at the top of the tab (or in a tab-local toolbar).
- The Account dropdown is populated from the same
populateAccountFilterhelper used today, scoped to the current provider value. - Changing the Provider dropdown:
- Repopulates the Account dropdown (filtered to that provider's accounts).
- Resets the Account selection to "(All accounts)".
- Calls the tab's
load*()to re-fetch data.
- Changing the Account dropdown:
- Sets
state.currentAccountIDsto[id]or[]for "All accounts". - Calls the tab's
load*()to re-fetch data.
- Sets
- Both dropdowns survive
populateAccountFilterrepopulation without losing theirchangelisteners. - Each tab's load path passes
currentProvider+currentAccountIDsto its API call (most already do). - Tests pin the change-→-load round-trip per tab.
Existing pattern to follow
frontend/src/plans.ts:1080-1100 already gets this right (provider + account filters, both wired to loadPlans). Use it as the template; lift the wiring helper into frontend/src/utils.ts if the duplication starts to bite.
Backend considerations
- Recommendations:
api.getRecommendations(provider, accountIDs)already accepts account IDs (used today by the per-column popover). Top-level dropdown is purely a UI add. - RI Exchange:
api.getRIExchange*calls today don't take an account filter. Likely a small backend change to add?account_id=…query parameter on the relevant endpoints. Verify before estimating effort. - History: dropdowns exist; just need the
change→loadHistory()wiring (one-line per dropdown).
Suggested split
This is naturally a 5-PR feature, one per tab. Suggest landing in this order so the highest-impact tab ships first:
- Recommendations — primary user surface, currently has no top-level account filter.
- RI Exchange — currently has no filter at all.
- History — wire the existing dropdowns to refresh on change (smallest diff).
- Dashboard — fix the refresh-on-change bug (already tracked separately as fix(dashboard): account dropdown change doesn't reliably refresh dashboard data #185).
- Plans — verify already-correct behaviour and add a regression test.
References
frontend/src/dashboard.ts:26-50frontend/src/plans.ts:1080-1100frontend/src/history.ts:69-77frontend/src/recommendations.ts(per-column popover machinery,applyColumnFilters)frontend/src/riexchange.ts:50-58frontend/src/utils.ts:populateAccountFilter
Activity
fix(dashboard): clear stale account state on provider switch + await …
cristim commentedon Apr 30, 2026
Verification
Original concern: Provider+Account dropdown coverage is uneven across the five main tabs. Acceptance criteria: a consistent provider+account dropdown pair on every main tab (Dashboard, Recommendations, Purchase Plans, Purchase History, RI Exchange), Provider change → repopulates Account → resets selection → re-fetches; both dropdowns survive
populateAccountFilterrepopulation; tests pin the round-trip per tab.What merged: PR #190 (
fix(dashboard): clear stale account state on provider switch) is the only merged PR linked here. It addresses sibling issue #185 (Dashboard refresh race) and is a prerequisite for #186, but is scoped to the Dashboard tab only.Code state today (
origin/feat/multicloud-web-frontend):<select id="*-provider-filter">+<select id="*-account-filter">exist infrontend/src/index.html(lines 47-57, 109-119, 191-199).frontend/src/recommendations.ts:53-61). The handler is now a no-op, with column-popover filtering replacing the dropdowns. No new top-level dropdown was reinstated.provider-filter/account-filtercontrols inindex.htmlorriexchange.ts. Grep returns nothing.change → loadHistorywiring (the issue's small History fix bullet) — not verified beyond the dropdown's existence; needs separate confirmation if you keep this open.So the unification across all five tabs is not complete. Dashboard (now correct) and Plans (already correct) are fine. Recommendations + RI Exchange still have no top-level provider/account dropdowns; History's
changewiring is separately untracked.Recommendation: keep-open. Missing: top-level provider+account dropdowns on Recommendations + RI Exchange, plus their backend wiring (
api.getRIExchange*may need anaccount_idquery parameter as the issue flagged), plus History'schange → loadHistory()wiring. Filing a smaller follow-up per remaining tab as the issue's "5-PR feature" plan suggested would also work.feat(filters): wire provider/account subscriptions to RI Exchange tab (…
cristim commentedon May 28, 2026
Verified shipped: merge commit d986b4d (PR #582) is in origin/feat/multicloud-web-frontend (compare API: feat is ahead of d986b4d). PR #582 body says "Closes #186" and wires provider/account subscriptions to the RI Exchange tab. PR #190 (merge commit cedcade, also in feat) contributed the dashboard slice of the same umbrella feature.