Files
supabase/apps/studio/components
Gildas Garcia 6f15081892 Scoped PAT: show dependencies between permissions (#50271)
## Problem

Some permissions require others to actually have an effect, for
instance:

- `api_gateway_keys_secret_read` requires `api_gateway_keys_read` or
`api_gateway_keys_write`
- `data_api_config_secret_read` requires `data_api_config_read` or
`data_api_config_write`

This is not obvious from a user perspective.

## Solution

We decided to make these requirements explicit by:
- Adding a line in the permission item stating the dependency
- Disabling the permission if its dependency isn't met
- Resetting the permission if it was selected but the dependencies
aren't met anymore

## How to test

- On
[staging](https://studio-staging-git-gildasgarcia-fe-4380-dashboa-b2a227-supabase.vercel.app/dashboard/account/tokens)
- Create a new token
- Check that _API Key Secrets_ is greyed out and disabled
- Select _API Key_ read or read-write
-  _API Key Secrets_ shouldn't be greyed out and disabled
- Select a value for _API Key Secrets_
- Set _API Key_ to none
- Check that _API Key Secrets_ is greyed out, disabled and reset to none
too
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
  - Added dependency-aware permissions for scoped access tokens.
- Permission descriptions now show required dependencies and permission
levels.
- Dependent permissions automatically reset to “None” when requirements
are not met.
- Permission controls and unavailable selections reflect dependency
requirements.
- **Accessibility**
- Screen readers now receive an announcement when a permission is reset
to “None” due to unmet dependencies.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-14 11:09:46 +02:00
..

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-cleaned folder 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.tsx as 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>
}