Roles and permissions
In Karizma One, rights are given project by project: each person with access to a project is a collaborator on it, with one role. The same person can be Admin on one project and Tester on another. This page describes the four roles and what each one allows.
To add a collaborator or change a role, contact your Karizma representative.
The four roles
| Role | For whom |
|---|---|
| Super Admin | The project owner. Has every right, including the terminal (SHELL) and the MCP service. |
| Admin | Project administrator: settings, collaborators, backups, domains, services, merge requests. No terminal access. |
| Developer | Developer: manages branches and stagings, edits code in the Web IDE, updates modules on stagings. No access to the settings. |
| Tester | Testing and review: sees the project, its branches and its code, without changing anything. This is the default role of a new collaborator. |
What each role can do
Legend: Yes / No / staging only. These are the default rights (see Roles adapted to your organization).
Project and settings
| Action | Super Admin | Admin | Developer | Tester |
|---|---|---|---|---|
| Open the project, see branches and the HISTORY, LOGS, MONITORING tabs | Yes | Yes | Yes | Yes |
| Open the project settings (Settings) | Yes | Yes | No | No |
| Read the Audit Logs | Yes | Yes | No | No |
| Manage domains and SSL certificates | Yes | Yes | No | No |
| Manage Cloud Armor | Yes | Yes | No | No |
| Change resources (CPU, storage) | Yes | Yes | No | No |
| Activate and manage services, pay for an order | Yes | Yes | No | No |
| See the credit pool | Yes | Yes | No | No |
| Manage the project's Karizma AI key | Yes | Yes | No | No |
| Delete the project | Yes | Yes | No | No |
Branches and environments
| Action | Super Admin | Admin | Developer | Tester |
|---|---|---|---|---|
| Create, edit, delete branches; deploy and destroy a staging | Yes | Yes | Yes | No |
| Restart a staging (Restart) | Yes | Yes | Yes | No |
| Stop or restart production (Stop, Restart) | Yes | Yes | No | No |
| Update Odoo modules (CONFIG tab) | Yes | Yes | staging only | No |
| Configure the branch token, change the Odoo image | Yes | Yes | No | No |
| Open a terminal (SHELL) on production or a staging | Yes | No | No | No |
| Use the MCP service (staging) | Yes | No | No | No |
| See Odoo version upgrades | Yes | Yes | Yes | Yes |
| Start or cancel an Odoo version upgrade (UPGRADE) | Yes | Yes | No | No |
Code
| Action | Super Admin | Admin | Developer | Tester |
|---|---|---|---|---|
| Browse code in the Web IDE | Yes | Yes | Yes | Yes |
| Edit and commit in the Web IDE (subject to the person's Web IDE access) | Yes | Yes | Yes | No |
| Create, review and merge merge requests | Yes | Yes | No | No |
| Manage submodules | Yes | Yes | No | No |
Data and backups
| Action | Super Admin | Admin | Developer | Tester |
|---|---|---|---|---|
| See and download backups | Yes | Yes | Yes | No |
| Create or upload a backup | Yes | Yes | No | No |
| Restore a backup | Yes | Yes | No | No |
| Use SQL INSIGHTS (read, test, run) | Yes | Yes | No | No |
Team
| Action | Super Admin | Admin | Developer | Tester |
|---|---|---|---|---|
| See collaborators | Yes | Yes | Yes | Yes |
| Add, edit, remove collaborators | Yes | Yes | No | No |
| Appoint a Super Admin, change a Super Admin | Yes | No | No | No |
| Change a collaborator's Web IDE access | Yes | No | No | No |
Technical permission codes (for reference)
Each action above maps to one or more permission codes. You may see them when talking to Karizma support.
| Action | Codes |
|---|---|
| Open the project, see branches | org.projects.view, org.branches.view |
| Open the settings | org.projects.edit |
| Audit Logs | org.audit-logs.view |
| Domains and SSL | org.project-domains.create, org.project-domains.edit, org.project-domains.renew-ssl |
| Cloud Armor | org.security.view, org.security.edit, org.security.disable |
| Resources | org.projects.scale |
| Services | org.project-services.edit |
| Credit pool | org.project-credits.view |
| Karizma AI key | org.ai.keys.manage |
| Delete the project | org.projects.delete |
| Branches and stagings | org.branches.create, org.branches.edit, org.branches.delete |
| Module updates | org.odoo-modules.update (Developer: staging environment only) |
| Branch token, Odoo image | org.branches.configure-token, org.branches.update-image |
| Terminal | org.terminal.use-prod, org.terminal.use-staging |
| Odoo version upgrades | org.odoo-upgrade.view, org.odoo-upgrade.create, org.odoo-upgrade.delete |
| Odoo contract (automated upgrade) | org.odoo-contract.view, org.odoo-contract.edit |
| Web IDE | org.ide.view, org.ide.edit |
| Merge requests | org.merge-requests.* |
| Submodules | org.submodules.* |
| Backups | org.backups.view, org.backups.create, org.backups.edit, org.backups.restore |
| SQL Insights | org.sql-insights.* |
| Collaborators | org.collaborators.view, org.collaborators.create, org.collaborators.edit, org.collaborators.delete |
The MCP service has no code: the check is made directly on the Super Admin role. The Super Admin holds every code; the Developer holds 15 by default.
Rights limited to some environments
A right can apply to some environments only (production, staging, development). By default:
- the Developer updates Odoo modules on stagings only, never on production;
- the Developer can restart a staging, but cannot stop or restart production.
Two settings come on top of the role, collaborator by collaborator:
| Setting | Effect |
|---|---|
| Web IDE Access | The environments where the person can edit code in the Web IDE (All branches, a selection such as Prod + Staging, or No access for read-only). Always All branches for a Super Admin. Only a Super Admin can change it. |
| Auto-Connect | Enabled: the Connect button signs the person in to the production Odoo instance as administrator automatically. Super Admins and Admins always are; on a staging, everyone is. |
Assign a role
Adding collaborators and assigning roles are handled by the Karizma team:
- The person signs in to Karizma One at least once: there is no e-mail invitation.
- You contact your Karizma representative with the person to add and the role you want.
- Unless stated otherwise, the person is added with the Tester role.
Only a Super Admin can appoint another Super Admin or change a Super Admin's settings.
Access to the GitLab repository
If the person added has the GitLab User type, they are also invited to the project's GitLab repository, with an access level that follows their role:
| Karizma One role | GitLab access |
|---|---|
| Super Admin, Admin | Maintainer |
| Developer | Developer |
| Tester | Reporter |
User types
On top of per-project roles, each account has one or more types, set by Karizma:
| Type | Effect |
|---|---|
| Internal | A member of the Karizma team. Has access to the Deploy wizard, which records orders for new projects. |
| Client | A user from a customer company. No access to Deploy; their rights depend on their project roles. A new project is created with the activation code received once the order is paid (see Your projects). |
| GitLab User | Is invited to the GitLab repository of the projects they are added to (see above). |
Roles adapted to your organization
The rights on this page are the default ones. Karizma can adapt them for your organization. If a right does not match what is described here, or if you need a different role, contact your Karizma representative.
When an action is refused
- A greyed-out button with the tooltip You don't have permission to perform this action: your role does not allow that action.
- A greyed-out button with the tooltip This project subscription has expired: the project's subscription has expired (see Subscription, services and credits).
- The UPGRADE and CONFIG tabs are hidden when you are not allowed to use them; a tab such as SHELL is shown greyed out.
- Without access to the settings, the gear icon on a project card shows You don't have the permissions to access this page.