Why We’re Changing
Onyx’s current permission system offers limited flexibility. You can make someone an Admin (full access), a Basic user (no management access), or a Curator (management access scoped to specific groups). There’s nothing in between. If you want someone to manage connectors but not agents, or view analytics without any management access, the current system can’t do that. The new group-based permission system solves this by assigning permissions directly to groups. Each group can have a specific set of permissions, and users inherit the permissions of every group they belong to. This enables granular delegation. For example, giving a team lead access to manage connectors without granting them full admin or curator powers.What’s Being Removed
- Curator role: Removed
- Global Curator role: Removed
CURATORS_CANNOT_VIEW_OR_EDIT_NON_OWNED_ASSISTANTSenvironment variable: Removed
What Replaces It
Instead of assigning roles to individual users, you assign permissions to groups. Any member of a group automatically inherits that group’s permissions. This is more flexible than the old Curator model:- You can grant connector management without granting agent management
- You can grant read-only analytics access without any management permissions
- You can create purpose-specific groups like “Content Managers” or “Analytics Viewers”
Available Permissions
The following permissions can be assigned to any group:| Permission | Description |
|---|---|
| Manage Connectors | Create and edit all connectors |
| Add Connectors | Create and edit only your own connectors |
| Manage Agents | Create and edit all agents |
| Add Agents | Create and edit only your own agents |
| Manage Document Sets | Create and edit all document sets |
| Manage User Groups | Create and manage all user groups. Automatically grants read access to connectors, document sets, agents, and users. |
| Manage LLMs | Create and edit LLM configurations |
| Manage Actions | Manage custom tools and MCP servers |
| View Agent Analytics | View agent analytics dashboards |
| View Query History | View query history |
| Create User API Keys | Create user-level API keys |
| Create Service Account API Keys | Create service account API keys |
| Create Slack/Discord Bots | Create and configure Slack/Discord bots |
| Full Admin Access | Full access to everything |
Before and After
| Old (Current System) | New (Group-Based Permissions) |
|---|---|
| Admin role | Member of Admins group (full access) |
| Basic role | Member of Basic group (chat, search, personal agents) |
| Curator role (per-group) | No direct single equivalent. See below. |
| Global Curator role | No direct single equivalent. See below. |
What changes for Curators
In the old system, a Curator could manage resources (connectors, agents, document sets) and users scoped to the specific group(s) they curated. A Global Curator had the same powers across all groups they belonged to. In the new system, these capabilities are split into separate permissions:- Managing group membership and resources within a group (adding connectors, agents, document sets, and users to a group) is controlled by the “manage user groups” permission.
- Creating and editing connectors, agents, or document sets themselves is controlled by separate permissions like “manage connectors,” “manage agents,” and “manage document sets.”
What Happens Automatically During Upgrade
The upgrade migration handles the following automatically:Admin users
All users with the Admin role are auto-joined to the Admins group. They retain full system access.
Basic users
All users with the Basic role are auto-joined to the Basic group. Their capabilities are unchanged.
Curator and Global Curator users
All users with Curator or Global Curator roles are auto-joined to the Basic group only.
Default groups created
Two protected groups are automatically created:
- Basic: All users are auto-joined. Grants core platform access (chat, search, personal agents).
- Admins: All former Admin users are auto-joined. Grants full system access.
Existing groups preserved
All your existing custom groups and their resource associations (connectors, document sets, agents) are preserved. No group memberships are lost. You can then assign permissions to these groups after upgrading.
What You Need to Do
The most important action is re-assigning permissions to groups for any workflows that previously relied on Curator or Global Curator roles.
Before Upgrading
- Audit your Curator assignments: Identify all users with Curator or Global Curator roles and note which groups they manage and what actions they perform.
- Plan your permission assignments: For each Curator, determine what capabilities their groups should have in the new system.
After Upgrading
- Assign permissions to groups: Navigate to the group settings page and enable the appropriate permissions for each group.
- Verify access: Confirm that users who previously had Curator access can still perform their required tasks.
Timeline
Specific version numbers and dates have not been finalized yet. This page will be updated as the release schedule is confirmed. Here is the planned rollout sequence:- Now: This documentation is published so you can understand the upcoming changes and start planning.
- Before the release: Deprecation banners will appear in the Admin UI on the Users and Groups pages, warning that Curator and Global Curator roles will be removed.
- On release: The new group-based permission system ships. Curator and Global Curator roles are permanently removed. Migration runs automatically on upgrade.
Frequently Asked Questions
What if I'm not using Curators today?
What if I'm not using Curators today?
If you only use Admin and Basic roles, this change requires no action from you. Your users, groups, and resources will continue to work exactly as they do today. The new permission system gives you additional flexibility if you need it in the future.
What happens to resources that my Curators created?
What happens to resources that my Curators created?
All resources (connectors, document sets, agents) are preserved with their original ownership. The creator remains the owner. However, users will only be able to access and manage these resources once they are granted the appropriate permissions. Until then, the resources exist but are not accessible to former Curators.
Can I recreate Curator-like behavior in the new system?
Can I recreate Curator-like behavior in the new system?
Not exactly. The old Curator role allowed scoped management within a specific group. The new system grants permissions globally, so a user with “manage connectors” can manage all connectors, not just those in a specific group. This is a trade-off for the added flexibility and granularity of the new permission system.
Is this a breaking change for Community Edition (CE) users?
Is this a breaking change for Community Edition (CE) users?
No. CE behavior is identical to today. CE has two default groups (Basic and Admins) that mirror the current Admin/Basic role split. Custom groups with configurable permissions are an Enterprise Edition feature.
What about API keys and service accounts?
What about API keys and service accounts?
Existing Admin API keys are placed in the Admins group. Basic API keys are placed in the Basic group. After upgrading, you can assign service accounts to specific groups for more granular access.