Member permissions and resource access

How permissions work

Every workspace member's access is decided in three layers:

• Role: an Admin has full access, like the owner. A Member starts with no access, and you grant what they need.
• What they can reach: which servers, projects and instances the member can see at all.
• What they can do: workspace-wide permissions (servers, dashboard, job queue, audit log, billing) plus console permissions granted one project at a time, with optional overrides on single instances.

For a member to act on something, they must be able to reach it and hold the matching permission. Anything not granted is denied. The workspace owner always has full access and is never restricted by these settings.

Only the owner and admins can change permissions, and only the owner can change an admin's permissions.

Open the Member Permissions wizard

1. Open Settings and go to the Workspaces tab.
2. In the Members card, click the shield icon (Manage permissions) next to the member. You can also do this for an invite that is still pending signup; the permissions apply once they join.
3. The Member Permissions wizard opens with four steps: Role, Servers, Projects and Instances.
4. Move between steps with Next and Back, or click a step name at the top.
5. Click Done when you are finished.

There is no Save button. Each change is saved on its own a moment after you make it, and the footer shows "Saving..." and then "All changes saved". If a change fails, a Retry button appears.

Step 1: set the role and workspace permissions

1. Choose a Role: Member or Admin. Admins bypass every permission and resource check, so nothing in the remaining steps applies to them.
2. For a member, decide whether to switch on Access all workspace resources. This lets them reach every project, server and instance, including anything created later. It decides what they can reach, not what they can do inside each project.
3. Set the workspace-wide permissions:
   • View servers, with Add servers, Edit server settings, Deploy servers and Delete servers underneath.
   • View projects & console, with Create projects and Delete projects underneath. Turning View projects & console off closes every project permission on the Projects step, whatever is set there.
   • View the workspace dashboard. Without it, the member opens the workspace on Projects.
   • View the job queue.
   • View the audit log, which shows who did what across the workspace. See Audit log and server activity.
   • Under Billing: Subscriptions and agent hours, including buying hours, and View and download invoices. Either one opens Settings to this member, on the Billing tab only.

Step 2: choose servers

1. Tick each server the member should be able to reach. Use the search box, Select all or Deselect all to speed this up.
2. If Access all workspace resources is on, there is nothing to choose here; every server is already included.

Step 3: grant console access per project

Console access is granted one project at a time. A project set to No access grants nothing, and a project created later starts with nothing until you come back and grant it.

1. Find the project in the list (use Search projects... if the list is long).
2. Pick a level from the selector on the project's row:
   • No access: grants nothing on this project.
   • Visible only: the member can see the project but cannot act on it.
   • Read only: Logs and Monitoring.
   • Operate only: Restart, Stop, Backups, Merge, Logs and Monitoring. The member can run the instances without reading the code.
   • Full access: every project permission.
   • Any workspace template you have created, listed under Workspace templates.
3. To fine-tune, click the project name to open its individual switches. Changing any switch makes the row show Custom.
4. To apply one level to every listed project, use Set all to at the top of the list.

The individual project permissions are:

• Project settings: change the project's settings.
• Agent tasks: see and use agent tasks on the project.
• Approve plans: approve an agent's plan so it can write and push code. Only available when Agent tasks is on.
• Create instances and Remove instances.
• Restart: restart and upgrade instances.
• Stop: stop instances.
• Backups: create and manage backups.
• Merge: merge branches between stages.
• Connect as user: sign in to the Odoo instance as one of its users.
• SSH & database: open SSH and database access to the instance. This is separate from Connect as user. See SSH access to instances.
• Instance settings: change an instance's settings.
• IDE: use the web editor.
• Logs: view instance logs.
• Monitoring: view instance monitoring. This is separate from Logs.

While you grant permissions that reach source code (such as IDE, Connect as user, SSH & database, Instance settings, Project settings, Agent tasks or Approve plans), a warning above the footer lists the projects whose code this member will be able to read.

Step 4: adjust single instances

Every instance follows its project's permissions. Switch one to Custom when this member needs different access on that instance alone, for example the IDE on staging but not on production.

1. The step opens on the instances this member already has settings for. To bring in another project's instances, type in Filter by project (Add a project...) and pick the project.
2. If the member does not have Access all workspace resources, switch on each instance they should be able to reach (or use Select all / Deselect all). An instance the member cannot reach stays out of the console even when its project is granted.
3. To override one instance, change its selector from Same as project to Custom, click the instance name to open its switches, and set them. The instance then no longer follows its project, so a permission the project gains later will not reach it.
4. To see only the instances you have overridden, switch on Only show overrides.

Create instances, Remove instances, Project settings, Agent tasks and Approve plans are set per project only; they cannot be overridden on a single instance.

Save a project's permissions as a template

1. On the Projects step, set up a project row the way you want it.
2. Click the bookmark icon (Save these permissions as a workspace template) on that row. The icon is not shown on a row that already follows a template.
3. Enter a Template name and click Save template.

The row now follows the template. If you later change a switch on that row, it detaches from the template and stops following later edits to it.

Manage permission templates

Permission templates are your own named bundles of project permissions. A project set to a template follows it: when you edit the template, every project using it changes with it. Only the owner and admins see this card.

1. Open Settings, go to the Workspaces tab and find the Permission Templates card (above the Members card).
2. To create one, click Add template, enter a Name, switch on the Grants you want, and click Save template.
3. To change one, click its Edit (pencil) icon, adjust the grants and click Save template. If members follow it, you are asked to confirm, because their access changes immediately. Instances switched to Custom keep their own permissions.
4. To remove one, click its Delete (trash) icon and confirm. Members who followed it keep exactly the access they have now; deleting a template does not revoke anything.

Each template shows how many of the permissions it grants and how many members and projects use it.

Note: A member with no project grants is allowed; the wizard warns "This member will have no console access on any project." They can still use whatever workspace-wide permissions you gave them.

Related: Inviting workspace members, A member cannot see or use a resource, Workspaces and team collaboration.

If you get stuck, open a support ticket from the Tickets page or the chat widget.