fix(settings): expose Azure payment default + correct misleading help text#27
Conversation
… text Issue #12 reported two linked gaps in Settings → Purchasing: 1. The four Azure service-defaults cards (VM / SQL / CosmosDB / Redis) had no Payment selector; `SERVICE_FIELDS` flagged the rows with `paymentId: null`, so the save path fell back to the global default_payment silently. Users who preferred Monthly Azure payments couldn't persist the preference. 2. The "Global Purchase Defaults" help text falsely stated *"Payment options only apply to AWS services; Azure and GCP reservations are always paid upfront."* — Azure reservations actually support upfront + monthly (already reflected in the plan form via AZURE_PAYMENTS in commitmentOptions.ts). Backend validation only accepts the AWS-style values `[no-upfront, partial-upfront, all-upfront]` for `ServiceConfig.Payment` (internal/config/validation.go:14), so the Azure cards store AWS-style values with user-visible labels: - "Upfront" → `all-upfront` - "Monthly" → `no-upfront` `normalizePaymentValue` in commitmentOptions.ts already bridges these back to Azure-native rendering at display time, so the round-trip stays consistent. - Add `<label>Payment: <select id="azure-{vm,sql,cosmosdb,redis}- payment">…</select></label>` to each of the four Azure cards. - Flip the four Azure rows in `SERVICE_FIELDS` from `paymentId: null` to the new element IDs. - Correct the help text to describe per-provider payment semantics (AWS: three upfront variants; Azure: upfront or monthly; GCP: monthly only). - New `describe('Azure payment defaults (issue #12)')` test block covers load → value applied, save → per-service payment (not global default) sent via `api.updateServiceConfig`, and a regression check on the help-text copy. Closes #12.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 36 minutes and 43 seconds. ⌛ 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)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
cristim
added
type/bug
1 participant
Summary
all-upfront, Monthly →no-upfrontSERVICE_FIELDSentries for the four Azure services flipped frompaymentId: nullto the new element IDs, so load/save pick up the per-service payment instead of silently falling back to the global defaultWhy AWS-style values on the Azure card
Backend validation at
internal/config/validation.go:14only acceptsno-upfront,partial-upfront,all-upfrontforServiceConfig.Payment.normalizePaymentValueincommitmentOptions.tsalready bridges the storage values back to Azure-native "Upfront"/"Monthly" at display time, keeping the plan-form rendering consistent.Closes #12.
Test plan
npx jest— 1220 tests pass (33 suites)npx tsc --noEmit— clean