Проекты и администрирование

Роли, права и проекты с точки зрения администратора описаны в разделе Пользователи и проекты.

Проекты

• GET|POST /api/projects, PUT /api/projects/:id — проекты, которые может открыть учётная запись, и создание проекта (администраторы).
• DELETE /api/projects/:id { key, force? } (администратор установки) — удаляет проект со всем содержимым. key — ключ проекта, набранный целиком (иначе 400). Проект по умолчанию и последний проект удалить нельзя (409), как и проект, в котором ещё есть кейсы, прогоны, требования или тест-планы, если не передано force: true.

WARNING

Удаление проекта необратимо: ничего не архивируется и не попадает в корзину.

Участники проекта

GET|PUT /api/projects/:id/members, DELETE /api/projects/:id/members/:userId — кто входит в проект и с какой ролью. GET возвращает полный список при праве settings:read; роли, которая только записывает результаты (runs:write, редактор), он возвращает активных участников как { email, name, active } — для выбора исполнителя, без их ролей.

Вход и сессия

• GET /api/auth/providers — публичный: { passwordLogin, oidc: { enabled, label?, error? }, devRoleSwitch }, плюс demoAccount: { email, password }, если демо-стенд публикует такую учётную запись.
• POST /api/auth/login отвечает { token, user }.
• POST /api/auth/logout — токен сразу перестаёт работать.
• POST /api/auth/password ({ currentPassword, newPassword }) отвечает 403 для учётной записи, которая входит через SSO, и для демо-учётной записи.
• GET /api/auth/oidc/login и /callback — единый вход (SSO, модуль sso, Enterprise; настройка — в разделе SSO). Существующая учётная запись связывается с SSO-идентичностью по email, только если она создана заранее без пароля и не является администратором; любая другая учётная запись подключается так: сначала вход по паролю, затем через SSO в том же браузере.

GET /api/auth/me — сессия, её роль и права, является ли учётная запись администратором установки (installationAdmin), и лицензированные модули (modules).

• Сессия со входом, но без cookie kvalli_signed_in получает его здесь. Этот cookie (путь /, ничего не разрешает) сервер читает при запросе страницы, чтобы отправить гостя на /login?redirect=… до загрузки рабочего пространства; вход ставит его, выход очищает.
• authenticated равно true для допущенного вызывающего (выполнен вход или установка не требует входа).
• Гость без сессии там, где вход обязателен, получает 200 с authenticated: false, user: null и без прав, а не отказ; предъявленная сессия, которая больше не действует (завершена, выполнен выход, отозвана), — по-прежнему 401.

API-ключи

POST|GET /api/apikeys, DELETE /api/apikeys/:id — API-ключи текущего проекта (модуль ci; для просмотра, создания и отзыва нужно settings:write — лид или администратор). В интерфейсе — «Настройки → API-ключи».

• Ключ не может нести scope, которого нет у его создателя (403); неизвестный scope — 400; лимит ключей на проект — 429.
• Сервисные учётные записи не могут создавать ключи.
• POST принимает { name, scopes, expiresDays? }: expiresDays — целое число от 1 до 3650, и ключ перестаёт работать через столько дней; без него ключ бессрочный.
• Сам ключ есть в ответе один раз (rawKey), а хранится только его хеш, так что ключ, который никто не скопировал, придётся создать заново.

Как ключ передаётся в запросах — в разделе Аутентификация.

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

GET|POST /api/admin/users, PATCH /api/admin/users/:id, POST /api/admin/users/:id/password, GET /api/admin/audit — управление пользователями и журнал аудита безопасности.

Каждому маршруту под /api/admin/ нужен администратор установки, а не право: учётная запись, роль которой имеет все права (admin или сервисная учётная запись со scope *). Лид проекта имеет settings:write, но всё равно получает 403. /api/admin/audit дополнительно требует модуль operations.

Лицензия

GET /api/admin/license (администратор установки) — состояние лицензии этой установки в виде { license: { … } }: тариф, модули, даты, лимиты и state (licensed, starter, revoked, grace, expired, over_limit, invalid). Никогда не отказывает в обслуживании; см. раздел Лицензия.

Телеметрия

• GET /api/admin/telemetry (администратор установки, на всех тарифах начиная с 2.0.1) — ровно те данные, которые были бы отправлены, чтобы решение включить телеметрию можно было принять, прочитав их.
• POST /api/admin/telemetry/send (те же требования) — отправить отчёт сейчас; отвечает 409, пока KVALLI_TELEMETRY выключен.

Подробнее — в разделе Телеметрия.

Состояние системы

GET /api/admin/system (администратор установки, модуль operations) — состояние установки; каждая часть читается отдельно (часть, которую не удалось прочитать, выглядит как { unavailable }):

• build;
• process — время запуска, аптайм, память;
• database — reachable, миграции: applied из expected;
• disk — том каталога данных;
• license, telemetry, scale;
• integrations — последняя проверка каждого подключения;
• models — токены по проектам за сегодня и по дням, агентам, провайдерам и моделям за 14 дней;
• jobs — выполняющиеся и последние 15;
• health — последние 24 часа, подсчитанные в этом процессе: запросы, ошибки сервера по областям и по часам, отклонённые запросы, необработанные отклонения промисов, задачи агентов по типу и причине сбоя;
• secrets.unreadable — настройки, для сохранённого секрета которых у этой сборки нет ключа;
• limits — действующие лимиты.

В интерфейсе это раздел «Настройки → Система». POST /api/admin/system/forget-secrets { paths } окончательно отказывается от части этих секретов (путь не из unreadable — 400).

GET /api/admin/system/diagnostics (администратор установки, модуль operations) — диагностический пакет в виде файла: отчёт телеметрии, последние 50 ошибок сервера (время, метод, область, статус, id запроса), недавние задачи по типу и итогу, состояние базы данных, диска и процесса. См. раздел Телеметрия.

Расход по людям

GET /api/admin/usage?days=30&projectId=… (администратор установки, модуль agents: Pro и выше, не только Enterprise) — расход по людям за days (1–365), по всей установке или по одному проекту. По каждой учётной записи (или API-ключу):

• кейсы, созданные вручную, утверждённые из черновика агента и импортированные (cases.unknown — созданные до того, как происхождение стало записываться);
• черновики Агента 1, которые они сохранили, изменили или отбросили;
• автотесты Агента 2, написанные для них и взятые в merge request;
• их вызовы моделей и токены по провайдерам и моделям.

Работа принадлежит тому, кто о ней попросил: кто запустил задачу, отправил сообщение в чат, решил по черновику, открыл merge request; работа воркфлоу — его владельцу. Работа, о которой никто не просил, и всё, что было до того, как стали записываться люди, — одна строка с userId: null. В интерфейсе — «Настройки → Администрирование → Расход по людям».