69 lines
3.0 KiB
Plaintext
69 lines
3.0 KiB
Plaintext
---
|
|
description: Permissions
|
|
globs: apps/**,packages/**
|
|
alwaysApply: false
|
|
---
|
|
|
|
# Access Control & Permissions Guidelines
|
|
|
|
This rule provides guidance for implementing access control, permissions, and subscription-related functionality in the application.
|
|
|
|
## Role-Based Access Control
|
|
|
|
### Account Roles
|
|
- Roles are defined in the `roles` table with hierarchy levels (lower number = higher privilege)
|
|
- Default roles include `owner` (hierarchy_level=1) and `member` with specific permissions
|
|
- Primary account owner has special privileges that cannot be revoked
|
|
- Role hierarchy controls what actions users can perform on other members
|
|
|
|
### Role Permissions
|
|
- Permissions are stored in `role_permissions` table mapping roles to specific permissions
|
|
- Core permissions:
|
|
- `roles.manage`: Manage roles of users with lower hierarchy
|
|
- `billing.manage`: Access/update billing information
|
|
- `settings.manage`: Update account settings
|
|
- `members.manage`: Add/remove members
|
|
- `invites.manage`: Create/update/delete invitations
|
|
|
|
### Permission Checking
|
|
- Use `has_permission(user_id, account_id, permission_name)` to check specific permissions
|
|
- Use `can_action_account_member(target_team_account_id, target_user_id)` to verify if a user can act on another
|
|
- Use `is_account_owner(account_id)` to check if user is primary owner
|
|
- Primary owners can perform any action regardless of explicit permissions
|
|
|
|
## Team Account Access
|
|
|
|
### Team Membership
|
|
- Use `has_role_on_account(account_id, account_role)` to check if user is a member with specific role
|
|
- Use `is_team_member(account_id, user_id)` to check if a specific user is a member
|
|
- Use the authenticated user's `TeamAccountWorkspaceContext` to access current permissions array
|
|
|
|
### Invitations
|
|
- Only users with `invites.manage` permission can create/manage invitations
|
|
- Users can only invite others with the same or lower role hierarchy than they have
|
|
- Invitations have expiry dates (default: 7 days)
|
|
- Accept invitations using `accept_invitation` function with token
|
|
|
|
## Subscription Access
|
|
|
|
### Subscription Status Checking
|
|
- Check active subscriptions with `has_active_subscription(account_id)`
|
|
- Active status includes both `active` and `trialing` subscriptions
|
|
- Guard premium features with subscription checks in both frontend and backend
|
|
|
|
### Billing Access
|
|
- Only users with `billing.manage` permission can access billing functions
|
|
- All billing operations should be guarded with permission checks
|
|
- Per-seat billing automatically updates when members are added/removed
|
|
|
|
## Row Level Security
|
|
|
|
### Table RLS
|
|
- Most tables have RLS policies restricting access based on team membership
|
|
- Personal account data is only accessible by the account owner
|
|
- Team account data is accessible by all team members based on their roles
|
|
|
|
### Actions on Members
|
|
- Higher roles can update/remove lower roles but not equal or higher roles
|
|
- Primary owner cannot be removed from their account
|
|
- Ownership transfer requires OTP verification and is limited to primary owners |