fix(billing): Account for gifted quantities in productIsEnabled check

[dashed]

Problem

On the subscription page, orgs on am3_t_ent with legacy soft cap see "Upgrade required — You currently do not have access to this feature" for Cron Monitors and Uptime Monitors, even when those monitors are gifted.

Root Cause

productIsEnabled() (frontend) decides whether a billing category is active or locked. Three bugs compounded:

Bug 1: Gifted quantities ignored

// billing.tsx:1043 (before)
const isPaygOnly = metricHistory.reserved === 0;

Only checks reserved (plan-included quota), ignoring free (gifted quota).

Bug 2: Per-category soft cap type ignored

A category with softCapType = 'TRUE_FORWARD' or 'ON_DEMAND' represents soft cap billing — the org can use the product via forward/ondemand billing. But the function didn't check softCapType.

Bug 3: Subscription-level legacy soft cap flag ignored (the main miss)

subscription.soft_cap (legacy boolean, serialized as hasSoftCap) and metric_history.soft_cap_type (per-category enum) are orthogonal fields in getsentry that are not kept in sync. Verified across the getsentry codebase:

• change_soft_cap() (getsentry/billing/soft_cap.py:17-54) toggles subscription.soft_cap but does NOT touch any metric history's soft_cap_type.
• Salesforce provisioning sets subscription.soft_cap = "enable soft-cap" in deal_terms independently from per-category soft_cap_type_* fields.
• create_new_category_histories (getsentry/models/billingmetrichistory.py:301) creates rows for backfilled categories (like MONITOR_SEAT, UPTIME) with soft_cap_type = None — it does NOT inherit from siblings or from the subscription-level soft_cap flag.

So legacy soft cap orgs whose Cron/Uptime categories were backfilled after original provisioning have hasSoftCap = true but softCapType = null on those categories. This is exactly the am3_t_ent scenario reported.

Data for the affected orgs

Field	Value	Meaning
hasSoftCap	true	Subscription-level legacy soft cap flag
reserved	0	Plan tier includes 0 monitors by default
free	0	No gifted monitors
prepaid	0	reserved + free
softCapType	null	Not set on backfilled category
onDemandBudget	0	Legacy soft cap orgs have no PAYG budget

Fix

billing.tsx:1043

// Before:
const isPaygOnly = metricHistory.reserved === 0;

// After:
const isPaygOnly =
  (metricHistory.prepaid ?? 0) === 0 &&
  !metricHistory.softCapType &&
  !subscription.hasSoftCap;

• prepaid = reserved + free — accounts for gifted quantities
• !softCapType — treats soft cap categories as enabled
• !subscription.hasSoftCap — treats legacy soft cap subscriptions as enabled

This matches the backend-wide pattern: subscription.soft_cap OR metric_history.soft_cap_type is not None used in:

• getsentry/quotas.py
• getsentry/billing/seat_policy/monitor.py
• getsentry/billing/tally_usage.py
• getsentry/models/billingseatassignment.py

index.tsx (URL product selection)

Parallel changes to the selectability check: use prepaid, add softCapType check, add hasSoftCap check (guarded on the category existing on the subscription).

Tests Added (16 new across 4 files)

billing.spec.tsx (6 new in productIsEnabled describe):

• Gifted-only category (reserved=0, free>0) → enabled
• No quota at all → disabled
• Mixed reserved + gifted → enabled
• softCapType TRUE_FORWARD with no prepaid → enabled
• softCapType ON_DEMAND with no prepaid → enabled
• hasSoftCap=true with null softCapType and no prepaid → enabled (the am3_t_ent bug)

index.spec.tsx (4 new):

• URL selects gifted-only product
• URL does not select zero-quota product
• URL selects product with softCapType
• URL selects product with hasSoftCap=true and null softCapType (the am3_t_ent bug)

panel.spec.tsx (4 new):

• Gifted monitors don't show "Upgrade required"
• Gifted uptime doesn't show "Upgrade required"
• Soft cap monitors don't show "Upgrade required"
• hasSoftCap=true with null softCapType doesn't show "Upgrade required" (the am3_t_ent bug)

table.spec.tsx (2 new):

• Gifted monitors render as enabled rows
• hasSoftCap=true with null softCapType renders as enabled (the am3_t_ent bug)

Why this matches the backend

The backend serializer (getsentry/api/serializers/customer.py:499) sends hasSoftCap: sub.soft_cap directly. Every quota/seat check in the backend uses the OR pattern. The frontend now matches that invariant.

[krithikravi]

not ultra familiar with react but the code changes look good to me

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c8d7ebe. Configure here.}