Context
Issue #111 sub-option (ii) — per-bucket Payment seeding in the fan-out modal — landed in PR #193. The seed walks (provider, service, term) buckets and pulls each one's per-account AccountServiceOverride.payment when all recs in the bucket share one cloud_account_id. When a bucket spans 2+ distinct cloud_account_id values, no single account's override applies cleanly, so the bucket falls back to the toolbar Payment.
The fallback is documented and correct (toolbar's "Payment" is what the user explicitly clicked) — but it's also the only case where the user's per-account override silently has no effect on a bulk purchase. For accounts with strong policy preferences (e.g. "this account only does no-upfront"), bulk-purchasing across that account + others ignores the policy.
What needs to happen
Pick one of two designs:
A) Sub-divide buckets by account
The current bucket key is (provider, service, term). Adding cloud_account_id to the key would produce per-account buckets, each cleanly eligible for its own override seed. Trade-off: more buckets = more approval emails for the user (one per bucket already).
B) Per-rec dropdowns inside a multi-account bucket
Keep the bucket boundary as today, but render per-rec Payment dropdowns inside the bucket section when it spans multiple accounts. Trade-off: more complex UI; users have to think harder about a bulk purchase.
Likely lighter-touch: (B) for visibility, with a "split bucket by account" affordance for users who'd prefer (A)'s clean per-account audit emails.
Acceptance criteria
- A test in
frontend/src/__tests__/recommendations.test.ts covering a multi-account bucket where each rec gets its own per-account override default.
- The fan-out modal renders the chosen UX (sub-divided or per-rec).
getFanOutBuckets() / handleFanOutExecute reflect the user's per-account choices in their POST bodies.
References
Effort & priority
- Effort: S-M (frontend-only; no backend changes)
- Priority: P3 (cosmetic — toolbar fallback is correct, just unsurprising for accounts with strong override policy)
Context
Issue #111 sub-option (ii) — per-bucket Payment seeding in the fan-out modal — landed in PR #193. The seed walks
(provider, service, term)buckets and pulls each one's per-accountAccountServiceOverride.paymentwhen all recs in the bucket share onecloud_account_id. When a bucket spans 2+ distinctcloud_account_idvalues, no single account's override applies cleanly, so the bucket falls back to the toolbar Payment.The fallback is documented and correct (toolbar's "Payment" is what the user explicitly clicked) — but it's also the only case where the user's per-account override silently has no effect on a bulk purchase. For accounts with strong policy preferences (e.g. "this account only does no-upfront"), bulk-purchasing across that account + others ignores the policy.
What needs to happen
Pick one of two designs:
A) Sub-divide buckets by account
The current bucket key is
(provider, service, term). Addingcloud_account_idto the key would produce per-account buckets, each cleanly eligible for its own override seed. Trade-off: more buckets = more approval emails for the user (one per bucket already).B) Per-rec dropdowns inside a multi-account bucket
Keep the bucket boundary as today, but render per-rec Payment dropdowns inside the bucket section when it spans multiple accounts. Trade-off: more complex UI; users have to think harder about a bulk purchase.
Likely lighter-touch: (B) for visibility, with a "split bucket by account" affordance for users who'd prefer (A)'s clean per-account audit emails.
Acceptance criteria
frontend/src/__tests__/recommendations.test.tscovering a multi-account bucket where each rec gets its own per-account override default.getFanOutBuckets()/handleFanOutExecutereflect the user's per-account choices in their POST bodies.References
resolveBucketPaymentSeedinfrontend/src/recommendations.ts, with a TODO(verify recommendations engine actually consumes per-account service overrides #111-followup) breadcrumb comment.Effort & priority