feat(settings): inline edit Term/Coverage + Enabled toggle on override rows (closes #110) - #396
Conversation
…e rows (closes #110) V2 of #72. PR #72 made the Payment cell on existing override rows editable; this extends the same sparse-PUT pattern to the remaining editable scalars on `account_service_overrides`. Changes (AWS rows only; Azure/GCP inline editing tracked under the provider-aware modal work): - Term cell: inline <select> (Inherit / 1yr / 3yr) filtered by `getValidTermOptions(provider, service, payment)` so RDS rows with payment=no-upfront do not list term=3 (the one hard AWS rule per commitmentOptions.ts). Inherit is disabled when term is already set (no clear-field channel, same rationale as Payment's Inherit). - Coverage cell: inline numeric <input> (0..100, integer). Fires on change (blur or Enter), not input, so a single PUT per finished edit. Out-of-range or non-integer input reverts to previous value with an error toast; clearing a preset value reverts (no clear-field) with an info toast pointing the user at Delete. - Enabled toggle: per-row checkbox, second-to-last column. Toggling disabled adds `.override-disabled` to the row (CSS `opacity: 0.55`) so the inactive state is visually obvious. Legacy rows with `enabled === undefined` render as ACTIVE; only explicit `enabled: false` renders unchecked + dimmed. For non-AWS rows the new column slot keeps the layout consistent: the Enabled checkbox renders disabled with an explanatory tooltip; Term and Coverage stay as read-only text cells until the provider-aware modal lands. Each handler mirrors `handlePaymentOverrideChange`'s shape verbatim: sparse PUT of just the touched field (backend's `applyOverrideScalars` treats unset request fields as "leave alone"), `loadOverridesPanel` reload + `refreshRecommendationsAfterOverrideChange` on success, revert-and-toast on failure. Tests (15 new in `settings-accounts.test.ts`) cover per-cell render, sparse-PUT payload shape, invalid-input revert paths, Inherit-disabled when value already set, AWS-only guards on non-AWS rows, and one Term sad-path that exercises the shared revert-on-error behaviour. Full frontend suite (46 suites, 1660 tests) green; production webpack build green; npx tsc --noEmit clean. The three new builder/handler pairs share the same template as `buildPaymentOverrideSelect`/`handlePaymentOverrideChange`. Extracting a common helper would also touch the existing Payment code path and expand scope beyond this issue; filing a follow-up refactor after this PR lands. Closes #110
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Summary
V2 of #72. PR #72 made the Payment cell on existing override rows
editable; this extends the same sparse-PUT pattern to the remaining
editable scalars on
account_service_overridesso users no longerhave to Delete and re-create the row just to bump a single field.
Changes (AWS rows only; Azure/GCP inline editing tracked under the
provider-aware modal work):
<select>(Inherit / 1yr / 3yr) filtered bygetValidTermOptions(provider, service, payment)so RDS rows withpayment=no-upfront do not list term=3 (the one hard AWS rule per
commitmentOptions.ts). Inherit is disabled when term is already set(no clear-field channel; same rationale as Payment's Inherit).
<input>(0..100, integer). Fires onchange(blur or Enter), notinput, so a single PUT per finished edit.Out-of-range or non-integer input reverts to the previous value with an
error toast; clearing a preset value reverts with an info toast pointing
the user at Delete.
disabled adds
.override-disabledto the row (CSSopacity: 0.55) sothe inactive state is visually obvious. Legacy rows with
enabled === undefinedrender as ACTIVE; only explicitenabled: falserenders unchecked + dimmed.
For non-AWS rows the new column slot keeps the layout consistent: the
Enabled checkbox renders disabled with an explanatory tooltip; Term and
Coverage stay as read-only text cells.
Each handler mirrors
handlePaymentOverrideChange's shape verbatim:sparse PUT of just the touched field (backend's
applyOverrideScalarstreats unset request fields as "leave alone"),
loadOverridesPanelreload +
refreshRecommendationsAfterOverrideChangeon success,revert-and-toast on failure.
Test plan
npx jest --testPathPattern settings-accounts-- 61 tests pass(46 existing + 15 new for issue ux(settings): inline edit Term/Coverage + Enabled toggle on existing override rows (V2 of #72) #110).
npx jest --testPathPattern settings-- 5 suites, 141 tests, green.npx jest(full frontend suite) -- 46 suites, 1660 passing(1 pre-existing skip, unchanged by this PR).
npx tsc --noEmit-- clean.npx webpack --mode production-- build green.Settings -> Accounts -> Overrides on an AWS account with at least
one override, edit Term / Coverage / Enabled in-place, confirm each
change persists across a reload, and confirm a disabled row renders
dimmed.
Reuse / no-duplication notes
The three new builders share the same template as
buildPaymentOverrideSelect+handlePaymentOverrideChange(added by#72). Extracting a common helper would also touch the existing Payment
code path; doing so here would expand the scope of this PR. Filing a
follow-up refactor issue after this lands.
Closes #110