35 lines
1.2 KiB
Markdown
35 lines
1.2 KiB
Markdown
# 03 Project Memberships, Teams, and Permission Model
|
|
|
|
## Goal
|
|
|
|
Implement the first version of project-scoped authorization with direct user permissions, team inheritance, and the base entities needed for future expansion.
|
|
|
|
## Requirements
|
|
|
|
- Introduce project-scoped permissions for:
|
|
- `create`
|
|
- `view`
|
|
- `edit`
|
|
- `delete`
|
|
- Allow project permissions to be assigned directly to users.
|
|
- Introduce teams as first-class entities.
|
|
- Allow teams to receive project permissions.
|
|
- Allow users to belong to teams.
|
|
- Evaluate effective permissions as the union of:
|
|
- direct user permissions
|
|
- team-inherited permissions
|
|
- Keep application-level admin access separate from project-scoped permissions.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- A user with direct project permission can perform the matching action.
|
|
- A user without direct permission but with a team that grants the permission can perform the matching action.
|
|
- A user without direct or inherited permission cannot perform the matching project action.
|
|
- Admin access remains application-wide and does not depend on project membership.
|
|
|
|
## Out of Scope
|
|
|
|
- Complex organization hierarchies
|
|
- Per-field permissions
|
|
- Temporary permissions or expiry rules
|