Роли и разрешения

Статус: актуально для текущего интерфейса платформы

Доступ в платформе задаётся на уровне рабочего пространства. Роли определяют, какие разделы пользователь видит и что именно он может делать внутри них.

Как устроен доступ

В актуальной модели есть два уровня контроля:

роли workspace — задают общий набор разрешений по модулям;
ограничения на уровне ресурса — например, на отдельную базу знаний, папку или документ.

Сначала платформа смотрит на роль пользователя в workspace, а затем, если на ресурс наложено отдельное ограничение, дополнительно проверяет его.

Важно:

ограничения на ресурсе не повышают права выше роли workspace;
они только сужают доступ к конкретным объектам.

Системные роли

В workspace по умолчанию используются четыре системные роли:

owner;
manager;
member;
viewer.

В зависимости от конфигурации workspace дополнительно могут использоваться кастомные роли.

Что может owner

owner — это владелец workspace с полным доступом.

Обычно он может:

управлять настройками пространства;
управлять участниками;
управлять ролями;
менять тарифные параметры, если это разрешено конфигурацией;
работать со всеми прикладными сущностями: ассистентами, чатами, знаниями, действиями, workflow и интеграциями.

В workspace должен оставаться как минимум один владелец.

Что может manager

manager — это административная роль workspace без полного контроля над всем административным контуром.

Обычно manager может:

приглашать и удалять участников;
менять состав участников;
редактировать workspace;
управлять ассистентами, чатами, базами знаний, действиями, workflow и интеграциями.

При этом у manager есть важные ограничения:

нет права управлять тарифом workspace;
нет права управлять кастомными ролями.

Что может member

member — это основная рабочая роль для повседневного использования платформы.

Обычно member может:

создавать и редактировать базы знаний и документы;
импортировать документы и запускать индексацию;
экспортировать документы;
создавать и редактировать ассистентов;
подключать действия к ассистентам и запускать доступные действия;
создавать и редактировать workflow-сценарии;
создавать и редактировать действия;
создавать, удалять и вести чаты;
загружать файлы в чат;
работать с интеграциями и векторными коллекциями;
видеть настройки workspace и данные по плану и кредитам.

Но member не является административной ролью. Для него важны такие ограничения:

нельзя удалять базы знаний;
нельзя управлять доступом к базам знаний;
нельзя удалять ассистентов;
нельзя удалять действия;
нельзя публиковать и архивировать workflow-сценарии;
нельзя управлять участниками и ролями.

Что может viewer

viewer — это не полностью пассивная роль. В актуальной модели она даёт доступ к просмотру большинства разделов, но при этом разрешает базовое использование чата.

Обычно viewer может:

просматривать базы знаний;
просматривать ассистентов;
просматривать workflow-сценарии;
просматривать действия и запускать доступные действия;
просматривать участников, настройки workspace и интеграции;
открывать чаты;
создавать чат;
отправлять сообщения в чат.

При этом viewer не может:

загружать файлы в чат;
создавать или редактировать ассистентов;
редактировать базы знаний и документы;
менять настройки workspace;
управлять участниками;
управлять интеграциями.

Если нужен пользователь, который может задавать вопросы ассистентам, но не должен менять прикладные сущности, viewer часто подходит лучше, чем member.

Модули, на которые обычно смотрят при настройке доступа

В интерфейсе и в матрице ролей права обычно сгруппированы по модулям:

базы знаний;
ассистенты;
workflow-сценарии;
действия;
чат;
настройки workspace;
участники;
интеграции;
коллекции;
дашборд.

При создании кастомной роли именно эти блоки чаще всего становятся основой для настройки доступа.

Кастомные роли

Если в workspace включена работа с кастомными ролями, можно создавать собственные наборы разрешений под конкретные сценарии.

Типовые примеры:

редактор базы знаний;
оператор чата;
владелец ассистентов без прав на участников;
пользователь только для запуска сценариев и просмотра результатов.

Обычно кастомные роли используют, когда стандартных owner/manager/member/viewer недостаточно для разделения обязанностей.

Несколько ролей у одного пользователя

В workspace может использоваться несколько назначенных ролей на одного участника. В этом случае итоговый доступ складывается из выданных разрешений.

Практически это означает:

если одна роль даёт просмотр, а другая редактирование, пользователь получает более сильный доступ;
если ресурс дополнительно ограничен ACL, роль сама по себе не обходит это ограничение.

Ограничения на уровне базы знаний

Помимо ролей workspace, отдельные базы знаний, папки и документы можно ограничивать через кнопку Доступ.

Можно задавать правила:

для роли;
для конкретного пользователя.

Уровни такого доступа:

Просмотр;
Редактирование;
Полный доступ.

Это особенно полезно, если:

одна команда должна видеть все знания, а другая только часть;
внутри базы есть закрытые папки;
отдельные документы нужно показывать только ограниченному кругу пользователей.

Подробнее: Базы знаний

Где управлять ролями

Раздел Рабочее пространство → Роли обычно включает:

список ролей;
матрицу разрешений;
историю изменений.

Раздел Рабочее пространство → Участники используют для того, чтобы:

приглашать пользователей;
назначать роли;
менять состав команды;
отзывать или повторно отправлять приглашения.

Подробнее: Рабочие пространства

Типовые сценарии

Пользователь должен только задавать вопросы в чате

Обычно подходит viewer, если не требуется загрузка файлов в чат.

Пользователь должен вести диалоги и загружать вложения

Обычно нужен как минимум member, потому что viewer не может загружать файлы в чат.

Пользователь должен вести базы знаний, но не управлять людьми

Обычно подходит member или кастомная роль с доступом к знаниям без прав на участников.

Пользователь должен управлять командой, но не тарифом

Обычно подходит manager.

Пользователь должен полностью администрировать workspace

Нужен owner.

Частые проблемы

Пользователь не видит базу знаний

Проверьте:

роль пользователя в workspace;
не ограничена ли база знаний или папка через кнопку Доступ;
не был ли пользователь удалён из workspace.

Пользователь видит чат, но не может прикрепить файл

Такое поведение ожидаемо для viewer. Для загрузки файлов в чат обычно требуется уровень не ниже member.

Пользователь может редактировать ассистентов, но не может публиковать workflow

Это типичное поведение роли member: прикладное редактирование доступно, публикация и архивирование workflow — нет.

Менеджер не видит управление кастомными ролями

Это ожидаемо. Управление кастомными ролями относится к более высокому уровню доступа и обычно доступно только владельцу.