mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix — copy + visibility logic on the org Usage page. ## What is the current behavior? On `/org/<slug>/usage` during a grace period, customers see two banners that read as contradictory: 1. *"Organization plan has exceeded its quota — grace period until {date}."* 2. *"You have not exceeded your Pro Plan quota in this billing cycle."* <img width="1680" height="372" alt="image" src="https://github.com/user-attachments/assets/13826260-55dd-4b55-a3dc-5afc51e6436e" /> Both are individually correct. The first is sticky from the previous cycle's overage (`org.restriction_status`); the second is a live scan over the current cycle. Neither anchors to which cycle it's talking about, so together they read like the dashboard contradicting itself. Surfaced by support off SU-368527 and SU-368395. ## What is the new behavior? - Top chrome banner copy: *"Organization exceeded its quota in the previous billing cycle / You have a grace period until {date} to bring usage back under quota."* - Inline `<Restriction />` grace-period alert switches from "is over its quota" to "went over its quota in the previous billing cycle." Same temporal anchor. - The "…in this billing cycle" summary line in `<TotalUsage>` is hidden whenever `restriction_status` is set. Mirrors the precedence rule `<Restriction />` already applies internally — backend status flag wins over the live cycle scan. <img width="1678" height="937" alt="CleanShot 2026-05-06 at 12 58 02" src="https://github.com/user-attachments/assets/df55eaed-1029-4f39-bea0-df77bcc5151e" /> ## Additional context Left the `gracePeriodOver` copy alone on purpose — it doesn't make a current-overage claim, so there's nothing to contradict, and adding "previous cycle" would muddy which cycle "previous" refers to. **Verified** - Lint and typecheck pass on `apps/studio`. **Before merge** - [ ] Load a grace-period org locally: confirm new copy on top banner and inline `<Restriction />`, and that the "not exceeded in this billing cycle" line is gone. - [ ] Copy review with support — happy to workshop wording. GROWTH-823 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Updated grace period alert messaging to clarify organization quota status * Refined date formatting in billing restriction notifications * Modified usage display to conditionally hide certain information when account restrictions are active <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA