Organization-level roles
Each user in your Tidelift Subscription is assigned a role. There are currently three roles available:
Administrator – An administrator is typically a manager of people, a manager of open source (e.g. Open Source Program Officer), or both. An administrator has full access to the Tidelift Subscription. They can manage catalogs, invite new users, and update roles. Administrators have access to all reports and can make policy decisions for the organization. Administrators receive email notifications for new tasks.
Member – A member is typically a consumer of open source within their organization. They are able to integrate the Tidelift Subscription and catalogs with their projects. Members have access to view global information within Tidelift, but do not have access to make policy decisions or edit any configurations. They can view standard configurations and reports, so they have the ability to see risk across the organization.
Developer - A developer is typically a front line user within their organization. Developers have access to view information within Tidelift that they are directly related to. They can view standard configurations, but cannot see any violation data (tasks or reports) at the catalog level. They are able to see projects that they are related to (via groups) and can see vulnerability data about packages for research purposes.
Catalog-level roles
Roles can also be assigned for specific catalogs.
You can upgrade a member to have administrator access, making them a Catalog Administrator for a specific catalog from the Catalog > Roles page.
Organization-level administrators will have catalog-level admin access for all catalogs.
Inviting New Users, Deleting Users, and Managing Roles
Administrators can invite new users to their organization, delete users, and edit roles from the Settings > Users page.
Group access: things to note
- If an organization does not have groups in use, then users will have access to all projects.
- If a user is added to a group, but the group is not associated with any projects, the user will only be able to see projects which are not associated with any group.
- Group access does not impact access to catalogs, so if a user only has access to projects that are aligned to Catalog A, they would still be able to see the standards set in Catalog B.
User roles break down
Function | Admin | Member | Developer |
Users | Create/Modify/Delete | Read only | No access |
Groups | Create/Modify/Delete | Read only | No access |
API keys |
Create/Modify/Delete | Create/Modify/Delete user and project keys. No Access to organization keys. |
Create/Modify/Delete user. Can view project keys for projects the user has access to. No Access to organization keys. |
Catalogs | Create/Modify/Delete | Read only | Read only |
Standards | Enable/Disable/Modify | Read only | Read only |
Tasks |
Can action |
No access |
No access |
Reports | Request | No access | No access |
Activity feed | Read only | Read only | Read only |
Projects | Create/Modify/Delete |
Create/Modify |
Read Only (Limited by group association) |
Packages | Modify (Limited) | Read only | Read only |