Repository navigation
feat(ui/approvals): Approval queue missing Account/Term/Payment/Monthly columns + shows user-id instead of email #704
Description
Approval queue renderer at frontend/src/history.ts:848-899 shows only Date / Provider / Service / Count / Upfront / Monthly Savings / Created by (raw user_id) / Actions. Operators approving purchases need Account, Term, Payment, Monthly/Yearly Cost — the backend PurchaseHistoryRecord (internal/config/types.go:445-516) already carries AccountID/Term/Payment/MonthlyCost but the frontend HistoryPurchase (frontend/src/types.ts:174-233) doesn't expose them and the renderer doesn't read them. The "Created by" column shows a UUID instead of email.
Also covers row 1.3 — once the Payment and MonthlyCost columns are surfaced, the divergence between Approval-queue "Eff. Savings" and Opportunities table's effective-savings formula can be reconciled (or the column renamed to "Monthly Savings" to match its actual semantic).
Fix direction
(a) Extend HistoryPurchase with account_id, term, payment, monthly_cost (already in JSON).
(b) Backend: add a CreatedByUserEmail field populated by joining executions → users in internal/api/handler_history.go executionToHistoryRow (~lines 180-215). Keep created_by_user_id for the cancel-own UX gate.
(c) Render the new columns in renderApprovalQueue; resolve account name via accountNamesCache (already imported by recommendations.ts — export it to a shared module).
(d) Decide: compute Effective Savings in the queue (same formula as Opportunities), or rename the column to "Monthly Savings".
Surfaced by QA spreadsheet rows 1.1 and 1.3.
Activity
feat(approvals): surface Account/Term/Payment/Monthly + user email in…
feat(approvals): surface Account/Term/Payment/Monthly + user email in…
cristim commentedon May 26, 2026
QA verification still failing after PR #713 merged
Re-tested row 1.1 (Approval queue columns, spreadsheet row 274). The columns were added but the data is missing:
So the column headers/cells render but the underlying API/data wiring doesn't populate them. Likely:
account_name/payment_optionfields on the executions endpoint.-because the value is null/undefined.Reopening this thread - please trace the data path from DB -> API -> frontend cell and ensure the Account/Payment values populate.
fix(approvals): use rec-level account fallback in matchesExecution (#704
fix(approvals): use rec-level account fallback in matchesExecution (#704
fix(approvals): use rec-level account fallback in matchesExecution (#704
cristim commentedon May 28, 2026
Verified as resolved via QA exploratory testing (marked Pass in the QA spreadsheet). Shipped in PR #713 (and follow-up PR #738 merged to backfill Account/Payment/MonthlyCost data). Closing.