Guides · Administration
Roles
What admins, developers, editors and readers may do in Obelism Content, and how tokens and agents act with a person's role.
People belong to an organization with one role, managed on www.obelism.studio for every Obelism product. The role applies to every space of the organization.
| May… | Admin | Developer | Editor | Reader |
|---|---|---|---|---|
| Read content, the model, assets, locales and the preview URL | ✓ | ✓ | ✓ | ✓ |
| Comment on entries | ✓ | ✓ | ✓ | ✓ |
| Create, save, publish, move and delete entries; upload assets | ✓ | ✓ | ✓ | |
| Prompt, save and publish on the site | ✓ | ✓ | ✓ | |
| Promote content between environments | ✓ | ✓ | ✓ | |
| Promote the content model along | ✓ | ✓ | ||
| Export and import content (backups, moving content) | ✓ | ✓ | ||
| Change the content model | ✓ | ✓ | ||
| Create spaces; change locales, preview URL, prompt endpoint | ✓ | ✓ | ||
| Open Settings and Activity | ✓ | ✓ | ||
| See, create and revoke API tokens and webhooks | ✓ | ✓ | ||
| Invite and remove members, rename the organization | ✓ | |||
| Roles per space; reviewed publishing, and approving reviews | ✓ | |||
| Transfer or delete a space | ✓ |
Roles per space
By default a member has their organization role in every space. An admin can give someone a role in some spaces only, under Settings → People: from then on they only see the spaces they have a role in, with that role in each (developer, editor or reader; it can be more than their organization role, say a client's editor who is a developer in their own space). Agencies use it to give a client's people their own space and nothing else.
- Every space, as … puts someone back in every space with their organization role.
- Not in this space takes one space away, but not their last: choose every space, or remove them from the organization on www.
- Admins are always in every space; to restrict an admin, change their role on www first.
- Everything follows the role in the space: the dashboard, the agent API and MCP, management and site tokens (as their creator) and editing on the site. Spaces someone wasn't given don't show up anywhere, as if they didn't exist.
Agents use GET …/spaces/{space}/members and PUT …/spaces/{space}/members/{userId} with { "access" } (admins).
In an environment whose publishing is reviewed (Settings → Publishing), only admins publish, unpublish, schedule, delete published entries and promote or import published content there; developers and editors ask for review instead, and an admin approves or sends it back. Changing the setting is for admins too.
Access per product
An admin can keep a member out of Content (or out of Improve) on www, under the organization's Product access. For Content they are then no member at all: the organization doesn't show up, and its spaces answer as if they didn't exist, in the dashboard, the agent API, MCP and their tokens. Their role and access to the other products stay as they are. Agents use PATCH https://www.obelism.studio/api/agent/organizations/{org}/members/{membershipId} with { "products": ["improve"] }, or null for every product (admins).
An admin can also turn Content off for the organization on www. The dashboard, the agent API, MCP and the management API then refuse it (product_disabled), while delivery keeps serving your sites.
Tokens and agents act as a person
- Management tokens and site tokens act as the person who created them, with that person's role at the time of each request: they stop working when the person leaves, and lose rights when the role changes.
- MCP and the agent API run as the person who signed in.
- Delivery and preview tokens only read, and belong to the space environment, not to a person.