Frontend sends provider, account_ids, start, end query params for the Purchase History date filter (row 3.4) and the Purchases-page Global filter (rows 4.2 / 4.4 / 4.5). Backend internal/api/handler_history.go fetchPurchaseHistory (lines 390-419) reads only account_id and limit — the rest are logged-or-silently-dropped. Visible filter affordances are no-ops.
Likely covers issue #503 (Savings History chart same backend gap) — consider bundling.
Fix direction
Backend: extend fetchPurchaseHistory to parse provider, account_ids (via parseAccountIDs), and start/end (validated as YYYY-MM-DD). Add a date-range overload (or nullable params) to the store GetPurchaseHistory family so SQL appends AND provider=$? AND account_id = ANY($?) AND scheduled_date BETWEEN $? AND $?. Mirror to fetchExecutionsAsHistory so both halves of the merged list respect the filter set. Bring both halves into a shared filter struct.
Surfaced by QA spreadsheet rows 3.4 / 4.2 / 4.4 / 4.5.
Frontend sends
provider,account_ids,start,endquery params for the Purchase History date filter (row 3.4) and the Purchases-page Global filter (rows 4.2 / 4.4 / 4.5). Backendinternal/api/handler_history.go fetchPurchaseHistory(lines 390-419) reads onlyaccount_idandlimit— the rest are logged-or-silently-dropped. Visible filter affordances are no-ops.Likely covers issue #503 (Savings History chart same backend gap) — consider bundling.
Fix direction
Backend: extend
fetchPurchaseHistoryto parseprovider,account_ids(viaparseAccountIDs), andstart/end(validated as YYYY-MM-DD). Add a date-range overload (or nullable params) to the storeGetPurchaseHistoryfamily so SQL appendsAND provider=$? AND account_id = ANY($?) AND scheduled_date BETWEEN $? AND $?. Mirror tofetchExecutionsAsHistoryso both halves of the merged list respect the filter set. Bring both halves into a shared filter struct.Surfaced by QA spreadsheet rows 3.4 / 4.2 / 4.4 / 4.5.