Перейти к содержимому

GET /api/orgs/:orgId/roles — Роли организации

Сгенерировано из матриц + кода. Правки вносить в источники (docs/matrices/, server/routes/), не здесь.

ПолеЗначение
HTTPGET /api/orgs/:orgId/roles
Auth
Scope токенаread
PG-функции
Таблицы
SRM— (вне SRM, документировано по коду)
RP (права)
Файл роутаserver/routes/orgs.js
Статуспо коду (вне SRM)

Аргументы запроса (best-effort из хендлера; путь-параметры опущены):

аргументов не обнаружено (подтвердить вручную по server/routes/orgs.js)

Коды ответов/ошибок (из хендлера): 200уточнить причины вручную

Для человека

Эндпоинт-заглушка. Управление ролями и их сопоставлениями переехало на уровень спейса: меню организации в шапке → «Управлять» → откройте нужный спейс → «Настройки спейса» → «Специализации». Отдельного экрана «Роли организации» в продукте больше нет.

Раньше этот метод отдавал список ролей организации и их сопоставлений (внешнее, кадровое имя роли → внутренняя роль системы). После переноса он остаётся только для обратной совместимости: всегда возвращает пустые списки { "roles": [], "mappings": [] }, чтобы старые страницы интерфейса не падали при загрузке. Никаких данных он больше не несёт.

Где теперь искать сопоставления ролей: в настройках конкретного спейса, раздел «Специализации». Там сопоставления заводятся и редактируются в контексте спейса, а не всей организации.

Кто может. Метод доступен любому участнику организации (наследует requireAuth роута), но смысла в нём нет — ответ всегда пустой. Реальные права на сопоставления ролей в спейсе — у менеджера спейса и администратора организации.

Для агента

Чтение, scope read достаточно. Путь-параметр :orgId — UUID организации.

Метод устарел и существует только как заглушка совместимости: он всегда возвращает пустые списки, независимо от того, есть ли в организации сопоставления ролей. Реальные сопоставления живут на уровне спейса — см. операции PUT /api/spaces/:id/role-mapping и DELETE /api/spaces/:id/role-mapping/:sourceRole.

Путь /api/orgs/... входит в read-allowlist agent-gate (server/auth/agentGate.js), поэтому токен сюда проходит и получает пустой ответ:

Окно терминала
curl https://specbuilder.vnimanie.ai/api/orgs/8f3a.../roles \
-H "Authorization: Bearer tak_..."

Ответ 200:

{ "roles": [], "mappings": [] }

Markdown-зеркала и ETag у этого метода нет — он отдаёт чистый JSON и не проходит через sendResource. Полезных affordances не публикует. Агенту опираться на этот эндпоинт не нужно; за состоянием сопоставлений обращаться к спейсу.

Связанные