mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 10:55:06 +03:00
2a3025df25
## 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? Logic-only extraction from #48742. Scoped PATs are enforced server-side as the intersection of the token's granted scopes and the owner's live role, re-checked on every request. This lands the pure inference layer that will power advisory (never blocking) UI feedback; no UI consumes it yet. - FGA_SCOPE_MINIMUM_ROLE: all 83 permission scopes transcribed from the OpenFGA model's role unions, mapped to the lowest base role that holds them. A drift-guard test pins the key set to the scope ids published in @supabase/shared-types, so upstream additions fail CI here with re-transcription instructions. - estimateRoleLevel: derives the user's base role per org (or per project for project-invited members) from the ungated /platform/profile/ permissions rows via four discriminating ABAC probes. Works for every member type with no permission-gated endpoint. - computeTokenRoleContext + applySelectionToRoleContext: role resolution (expensive, memoized) is split from selection evaluation (cheap, re-run per permission toggle). AccessToken.permissions.ts gains only what the roles module needs: the PermissionLevel type and the catalog's `level` field (decides whether an org or project role governs a resource), plus getEntryScopes, which selectionToScopes now reuses. The UI-only additions from #48742 (risk badge/dot variants, mode labels, the OverallRisk.text -> description rename) are deliberately left out so this PR touches no .tsx. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added role-aware evaluation for scoped access-token permissions. * Added support for organization- and project-level permission scoping. * Added guidance when selected permissions exceed the current role, including read-only downgrades and inaccessible resources. * Added clearer grouping of permission access issues by resource. * **Tests** * Added comprehensive coverage for role mapping, permission evaluation, scoping, and failure scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Wen Bo Xie <wenbox323@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.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 — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}