Permission Hierarchy
Permissions in Gitea are organized in a hierarchy:Access Modes
Gitea defines five core access modes, each granting progressively more permissions:None
Level 0 - No access to the resource
Read
Level 1 - View and clone repositories, read issues and PRs
Write
Level 2 - Read access + push code, create issues, comment
Admin
Level 3 - Write access + manage settings, webhooks, collaborators
Owner
Level 4 - Full administrative control over the organization
Access Mode Implementation
models/perm/access_mode.go:14-39
Organization Permissions
Organization Roles
Within an organization, users can have three roles:- Owner
- Admin
- Member
Full ControlOwners have complete control over the organization:Source:
- Create, edit, and delete teams
- Add and remove members
- Manage organization settings
- Access all repositories
- Delete the organization
- Manage webhooks, labels, and packages
models/organization/org_user.go:61-72Team Permissions
Teams provide the primary mechanism for granting repository access within organizations.Base Team Permissions
Each team has a base access mode that applies to all repositories it has access to:models/organization/team.go:74-86
Permission Inheritance
When a user belongs to multiple teams:Gather repository access
For a specific repository, collect permissions from all teams that have access
- User is in Team A (read access to repo)
- User is in Team B (write access to repo)
- Result: User has write access
Maximum Team Authorization
The system calculates the maximum authorization level across teams:models/organization/org.go:396-407
Repository Unit Permissions
Repositories are divided into units, each with independent permission controls:Available Units
| Unit | Description | Access Levels |
|---|---|---|
| Code | Git repository access | Read, Write, Admin |
| Issues | Issue tracking | Read, Write |
| Pull Requests | Code review and merging | Read, Write |
| Releases | Release management | Read, Write |
| Wiki | Repository wiki | Read, Write |
| External Wiki | External wiki link | Read only |
| External Tracker | External issue tracker link | Read only |
| Projects | Project boards | Read, Write |
| Packages | Package registry | Read, Write |
| Actions | CI/CD workflows | Read, Write |
Unit-Level Access Control
models/organization/team.go:174-189 and models/organization/team_unit.go:14-21
Unit-level permissions enable scenarios like:
- Developers with write access to code but read-only access to issues
- Support team with write access to issues but read-only access to code
- Documentation team with write access to wiki only
Organization Visibility and Access
Organization visibility affects who can see the organization and its repositories:models/organization/org.go:421-440
Visibility Rules
Public Organization
- Visible to everyone
- Repositories follow their own visibility
- Anonymous users can view public org page
Limited Organization
- Visible to authenticated users
- Hidden from anonymous visitors
- Repositories accessible to signed-in users
Private Organization
- Visible only to members
- All repositories effectively private
- Only members can view org page
Repository Creation Permissions
Teams can be granted permission to create repositories:models/organization/org_user.go:107-115
Permission Checking Best Practices
1. Always Check at the Lowest Level
Check permissions for the specific action being performed:2. Use Highest Permission When Multiple Teams
When a user belongs to multiple teams, always use the maximum permission:3. Consider Organization Visibility
Always check if a user can see the organization before checking repository permissions.4. Handle Special Cases
- Site administrators always have full access
- Blocked users have no access
- Restricted users have limited visibility
Frequently Asked Questions
What happens when a user is in multiple teams with different permissions?
What happens when a user is in multiple teams with different permissions?
The user receives the highest permission level granted by any of their teams. For example, if Team A grants read access and Team B grants write access, the user will have write access.
Can a team have different permissions for different repositories?
Can a team have different permissions for different repositories?
No, a team’s permission settings apply to all repositories it has access to. To achieve different permissions for different repositories, create separate teams.
What's the difference between Admin and Owner access?
What's the difference between Admin and Owner access?
Owner (level 4) is the highest level and is reserved for organization ownership. Owners can manage all aspects of the organization including deletion. Admin (level 3) provides administrative access to repositories but not to organization-level settings.
Can team permissions override owner permissions?
Can team permissions override owner permissions?
No, organization owners always have full access to all repositories and settings, regardless of team membership.
How do external wiki and tracker permissions work?
How do external wiki and tracker permissions work?
External wiki and external tracker units can only have read permissions since they link to external services. Even if a team has admin access, these units remain read-only.
What permissions does a restricted user have?
What permissions does a restricted user have?
Restricted users can only see organizations they are explicitly members of and can only interact with repositories they have been explicitly granted access to through team membership. They cannot see public organizations or repositories unless they are members.
How are permissions recalculated when team settings change?
How are permissions recalculated when team settings change?
When team permissions change, Gitea automatically recalculates access for all team members across all team repositories. This ensures permissions are immediately updated.Source:
services/org/team.go:133-146Permission Reference Table
Organization Level
| Action | Owner | Admin | Member |
|---|---|---|---|
| View organization | ✓ | ✓ | ✓ |
| Create teams | ✓ | ✗ | ✗ |
| Delete teams | ✓ | ✗ | ✗ |
| Manage members | ✓ | ✗ | ✗ |
| Organization settings | ✓ | ✗ | ✗ |
| Delete organization | ✓ | ✗ | ✗ |
Repository Level (per team)
| Action | Owner | Admin | Write | Read |
|---|---|---|---|---|
| View code | ✓ | ✓ | ✓ | ✓ |
| Clone repository | ✓ | ✓ | ✓ | ✓ |
| Push code | ✓ | ✓ | ✓ | ✗ |
| Create issues | ✓ | ✓ | ✓ | Unit-based |
| Close issues | ✓ | ✓ | ✓ | ✗ |
| Merge PRs | ✓ | ✓ | ✓ | ✗ |
| Repository settings | ✓ | ✓ | ✗ | ✗ |
| Manage webhooks | ✓ | ✓ | ✗ | ✗ |
| Delete repository | ✓ | ✓ | ✗ | ✗ |
Related Resources
- Organizations - Creating and managing organizations
- Teams - Team management within organizations
- Repository Collaborators - Direct repository access
- Branch Protection - Protecting branches with rules