Documentation / Teams and agencies
Sharing Services
Give another team access to an Odoo service, with a role that controls what it may do.
Sharing lets your team give another calmo.cloud team access to one of your Odoo services — without copying anything and without adding its people to your team. The service keeps running on your server and stays yours. The partner team simply sees it in its own service list and can work with it as far as the role you chose allows.
Typical situations:
- Agency and client — the agency hosts the service and gives the client's team Operator access, so the client can restart the service and download backups but cannot change anything
- External developers — you host the service and give a freelancer's team Developer access for the duration of a project, then revoke it
- Group companies — subsidiaries with their own teams get access to a shared ERP instance without sharing servers or credentials
Sharing is being rolled out team by team. If you don't see a Sharing tab on your services yet, it isn't enabled for your team — get in touch and we'll switch it on. A team can always accept invitations it has received, whether or not it can share services itself.
Hosting team and partner teams #
The team that created the service is the hosting team. It owns the service, runs the server it lives on, and is the only team that decides who else gets access. Every other team with access is a partner team.
A partner team:
- sees the service in its own service list
- works with the service through the same pages as the hosting team, limited by its role
- never gets access to the hosting team's server, its other services, or its team settings
The hosting team keeps full control at all times and can change a partner's role or revoke its access whenever it likes.
Roles #
When you share a service you pick a role for the partner team. Roles build on each other: every role can do everything the roles below it can.
| Role | What the partner team can do |
|---|---|
| Viewer | Sees the service, its status and its logs. |
| Operator | Additionally starts, stops, restarts and redeploys the service and creates or downloads backups. |
| Developer | Additionally edits settings, creates copies, manages addons and modules, opens the terminal, runs scripts and starts coding-agent sessions. |
| Manager | Additionally restores backups and manages hostnames. |
In detail:
| Viewer | Operator | Developer | Manager | |
|---|---|---|---|---|
| View the service, its status and its logs | ✓ | ✓ | ✓ | ✓ |
| Start, stop and restart | ✓ | ✓ | ✓ | |
| Redeploy and pull images | ✓ | ✓ | ✓ | |
| Create and download backups | ✓ | ✓ | ✓ | |
| Edit settings and see the admin credentials | ✓ | ✓ | ||
| Create copies | ✓ | ✓ | ||
| Neutralize copies | ✓ | ✓ | ||
| Update, deploy and remove attached addons | ✓ | ✓ | ||
| Install and upgrade modules | ✓ | ✓ | ||
| Create preview deployments | ✓ | ✓ | ||
| Open the web terminal | ✓ | ✓ | ||
| Run scripts | ✓ | ✓ | ||
| Start coding-agent sessions | ✓ | ✓ | ||
| Restore backups | ✓ | |||
| Manage hostnames | ✓ |
Viewers and Operators see the service settings read-only, and the admin credentials are hidden from them.
Coding-agent sessions belong to the team that started them: a partner team never sees the hosting team's sessions on a shared service, and the hosting team cannot open the partner's sessions or act on them. Webhooks about a partner's sessions, however, go to the hosting team — to its webhooks with the source Agent sessions — and not to the partner's. They include the session's title, the tools the agent asks to use and its questions, and they link to the service rather than to the session. Whoever started the session in the partner team is still told in the panel's notification bell when the session needs their attention. See Webhooks.
Reserved for the hosting team #
Some things are never granted to a partner team, whatever its role:
- Sharing the service, changing roles and revoking access
- Deleting the service or any of its copies
- Running commands on the server and reading command output in the Actions tab
- Changing the backup configuration and its destinations, and importing backups from the server
- Attaching repositories and adding addons from the hosting team's catalog
Notifications and outgoing webhooks for a shared service are sent to the hosting team only. The dashboard's backup overview and the security page only cover the services your team hosts, so a shared service is not counted there.
Sharing a service #
You need to be an admin of the hosting team to share a service.
1. Open the Sharing tab #
Open the service and switch to the Sharing tab. It lists every team the service is currently shared with.
2. Click Share with a team #
Click Share with a team and fill in:
- Team slug — the slug of the partner team, as it appears in that team's calmo.cloud URL. Ask the partner team for it; calmo.cloud does not look up other teams for you.
- Role — what the partner team may do. You can change this later.
3. Send the invitation #
Click Send invitation. The owner and the admins of the partner team receive an email and an in-app notification. Nothing is shared until one of them accepts.
Invitations stay open for 7 days. The Share invitations tab shows the ones that are still pending, declined or expired. Pending and expired invitations can be sent again with Resend, and Withdraw removes any of them. A declined invitation cannot be resent — withdraw it and invite the team again.
As soon as the partner team accepts, it shows up in the Sharing tab and the service appears in its service list.
Accepting an invitation #
If another team has shared a service with you:
- Open Shared with you from your team menu. You need to be an admin of your team.
- Review the service, the hosting team and the role you are offered.
- Click Accept or Decline.
After accepting, the service appears in your service list next to your own services.
Changing a role or revoking access #
In the Sharing tab of the service, the hosting team can:
- Change role — takes effect immediately
- Revoke — removes the team's access immediately
A partner team can end its own access at any time with Leave in the same tab.
Revoking a team, or a team leaving on its own, removes it from every copy of the service, including copies the team created itself. Those copies stay with the hosting team.
Copies of a shared service #
Copies work as usual, with a few sharing-specific rules:
- When the hosting team creates a copy, the copy is shared with the same partner teams at the same roles. The copy dialog lets you pick which partners the copy keeps under Share the copy with.
- When a partner team creates a copy (Developer or Manager), the copy still runs on the hosting team's server and belongs to the hosting team, but it is shared with the partner team alone — at the same role it has on the original. The hosting team sees the copy too.
- A partner team cannot create a copy of a copy.
See Creating Copies for how copies work in general.
Using the API #
Everything above is also available through the REST API. API tokens belong to a team, so what a token may do depends on whether that team hosts the service or is a partner.
| Endpoint | Who |
|---|---|
GET /api/service-odoo/{uuid}/shares |
hosting team |
POST /api/service-odoo/{uuid}/shares |
hosting team — invite a team |
GET /api/service-odoo/{uuid}/share-invitations |
hosting team |
PATCH /api/service-odoo/{uuid}/shares/{team-uuid} |
hosting team — change the role |
DELETE /api/service-odoo/{uuid}/shares/{team-uuid} |
hosting team, or a partner team for its own share |
GET /api/share-invitations |
invited team |
POST /api/share-invitations/{uuid}/accept |
invited team |
POST /api/share-invitations/{uuid}/decline |
invited team |
Request and response formats are in the API reference.