Permissions
Understand the permission model for release groups; who can create, edit, scan, set policies, and generate reports.
Overview
Release groups have their own permission model, separate from project-level permissions. Permissions can be scoped to a specific release group or granted across all release groups in the organization.
Permission types
| Permission | What it controls |
|---|---|
| Edit group | Rename the group, manage its releases, delete the group |
| Create/edit releases | Create, edit, clone, and delete releases within the group |
| Set licensing policy | Assign or change the licensing policy for the group |
| Set security policy | Assign or change the security policy for the group |
| Set quality policy | Assign or change the quality policy for the group |
| Generate reports | Generate licensing, vulnerability, SBOM, and remediation guidance reports |
Settings tab visibility
The Settings tab is shown to any user who has at least one of the following permissions for the group: edit group, set licensing policy, set security policy, or set quality policy. Users who can only generate reports do not see the Settings tab.
Org-wide vs group-specific
Each permission type comes in two scopes:
- Group-specific: applies to one named release group only.
- Org-wide: applies to all release groups in the organization (e.g. a compliance team that manages policy across every product).
Team-based access
Release groups can be assigned to teams during creation or from Settings → General. Team members inherit access to the release group based on their role within the team.
For a full overview of how FOSSA's permission model works, see Organization Management.