Участники и роли
Приглашение участников, назначение ролей, контроль мест, передача владения и модель прав в панели.
Страница Members по адресу /[orgSlug]/settings/members контролирует, кто имеет доступ к рабочему пространству AACsearch и что может делать. Модель прав ролевая и действует на уровне организации — каждое членство связывает пользователя с организацией ровно одной ролью.
Роли
В AACsearch четыре роли. По убыванию привилегий:
| Роль | Что может |
|---|---|
owner | Всё, что admin, плюс: передача владения, смена плана биллинга, удаление организации. Ровно один owner в каждый момент. |
admin | Приглашать/удалять участников (любую роль, кроме owner), создавать/удалять индексы, управлять API-ключами, редактировать релевантность, запускать реиндекс, управлять коннекторами, видеть аудит, управлять биллингом (кроме смены плана и удаления). |
member | Читать данные панели, выполнять поиск в Песочнице, видеть аналитику, читать аудит. Не может создавать/удалять индексы, ключи, изменять релевантность, приглашать. |
viewer | Только чтение overview, аналитики, аудита, списка участников. Никаких записей. Полезно стейкхолдерам без оперативных привилегий (продакт-менеджер, аудитор). |
Роли проверяются middleware oRPC в packages/api/orpc/procedures.ts:
publicProcedure— без роли (логин, публичный widget).protectedProcedure— любой авторизованный.protectedProcedure.use(requireOrgRole("admin"))— admin или owner.adminProcedure— платформенный админ (отдельно от org-admin; см. Планы и лимиты).
Серверные проверки авторитативны. Скрытие кнопок в UI — лишь удобство; на submit роль проверяется заново.
Приглашение участника
Из /[orgSlug]/settings/members:
- Нажмите Invite member.
- Введите email.
- Выберите роль (по умолчанию
member). - Нажмите Send invite.
Приглашённый получает письмо со ссылкой, действительной 14 дней. Он:
- Кликает по ссылке.
- Логинится или регистрируется (Better Auth: пароль, OAuth, passkey).
- Попадает в организацию с назначенной ролью.
Приглашение фиксируется в аудите (add_member) в момент принятия, не отправки.
Массовое приглашение
Для крупных раскаток вставьте список email через запятую или с новой строки. Все получают одну роль. Невалидные адреса помечаются и не отправляются.
CSV-загрузки нет — массовая вставка покрывает несколько сотен адресов, что подходит под лимиты мест всех платных планов.
Смена роли
Из row actions выберите Change role. Новая роль действует немедленно для новых запросов. Уже авторизованные in-flight запросы доходят до конца.
Owner не может понизить себя. Передача владения — через Transfer ownership (ниже).
Аудит-трейл
| Действие | Когда |
|---|---|
add_member | Принятие приглашения |
remove_member | Удаление (любая роль) |
change_member_role | Изменение роли (с old/new в details) |
Удаление участника
Из row actions выберите Remove from organization. Доступ теряется немедленно. Личный аккаунт не трогается — отзывается только членство в этой организации.
Удаление не отзывает API-ключи, созданные этим участником. Обрабатывайте ключи отдельно:
- Просмотрите ключи, созданные ушедшим участником (фильтр аудита по
userId+create_api_key). - Отзовите всё, что должно перестать существовать (см. API-ключи).
- Зафиксируйте ротацию в access-review.
Передача владения
Передавать может только owner. Из row actions на другом admin выберите Transfer ownership.
- Текущий owner подтверждает паролем (re-auth gate).
- Целевой пользователь повышается до
owner. - Текущий owner понижается до
admin.
Owner всегда ровно один — повышение и понижение происходят атомарно.
Если текущий owner ушёл и других owner-ов нет, обратитесь в поддержку — платформенный админ переназначит владение через /admin/organizations.
Использование мест
У каждого платного плана есть потолок мест (maxSeats). Список показывает Active members: N / cap сверху. Правила счёта:
- Owner, admin, member, viewer — все занимают место.
- Удалённые участники освобождают место мгновенно.
- Pending-приглашения не занимают мест; считаются только принятые.
Когда достигнут потолок, кнопка Invite становится неактивной с подсказкой. Обновите план или удалите неактивных — чтобы освободить места.
Потолки по планам и поведение overage — в Планы и лимиты.
Сервисные аккаунты
Отдельной сущности «сервисный аккаунт» нет. Для серверной автоматизации без привязки к человеку:
- Создайте общий ящик (например,
aacsearch-bot@yourcompany.com). - Пригласите как
member(илиadmin, если нужны записи в индекс). - Используйте API-ключи (
ss_search_*,ss_connector_*) для трафика данных — ключи не занимают мест и создаются любым admin.
Большинству автоматизации хватает API-ключей. Членство нужно только если бот должен управлять самим UI панели (редко).
SCIM (enterprise)
В enterprise-планах поддерживается SCIM 2.0. Когда SCIM включён, идентичности зеркалируются из вашего IdP (Okta, Entra ID, Google Workspace):
- Пользователи автопровижинятся при первом входе, если входят в маппированную группу.
- Деактивация в IdP отзывает членство в AACsearch.
- Маппинг ролей — в таблице IdP-группа → AACsearch-роль по адресу
/admin/scim.
SCIM-эндпоинты — /scim/v2/, документация в API Reference → SCIM. Доступ: только enterprise — см. Планы и лимиты.
Частые сценарии
«Подрядчик правит релевантность на две недели»
Пригласите как admin. Через две недели удалите. Проверьте по аудиту, какие ключи он создавал, и отзовите их.
«Продакт-менеджер хочет видеть аналитику, но я не хочу, чтобы он мог удалять»
Пригласите как viewer. Доступ к overview, аналитике и аудиту. Не может запускать реиндекс, править релевантность, трогать ключи.
«Оncall-инженер должен мочь запускать реиндекс, но не менять биллинг»
Пригласите как admin. Только owner может менять план биллинга или удалять организацию.
«Нужно сменить владельца, потому что основатель уходит»
Передайте владение входящему owner-у до потери доступа основателем. После передачи прежнего owner-а можно удалить безопасно.
Связанные страницы
- Обзор панели — что показывает экран обзора организации.
- API-ключи — программный доступ вне зависимости от членства.
- Журналы аудита — отслеживание каждой смены членства.
- Планы и лимиты — потолки мест и enterprise SCIM.