docs: БД clinic_tests + hr_bot_test, staff_id, RBAC, telegram_id справка

Made-with: Cursor
This commit is contained in:
Константин Лебединский
2026-04-24 20:23:59 +05:00
parent 675555531f
commit 7fa6f98ee1
7 changed files with 41 additions and 9 deletions
+10
View File
@@ -13,6 +13,7 @@
- [Функциональные возможности](#функциональные-возможности)
- [Роли и права доступа](#роли-и-права-доступа)
- [Установка и запуск](#установка-и-запуск)
- [Данные, сотрудники, интеграция с HR](#данные-сотрудники-интеграция-с-hr)
- [Нефункциональные требования](#нефункциональные-требования)
- [Вне scope](#вне-scope-не-реализуется-в-данной-версии)
@@ -119,6 +120,15 @@
Старый вариант **только** с локальным Postgres на порту 5433: корневой `docker compose up -d` в TestingWebApp и в `.env` порт `5433` (или отдельные `DB_*` без `DATABASE_URL`) — оставлен для разработки без общего `Postgres_TG_Bots`.
### Данные, сотрудники, интеграция с HR
- **Две роли кластера Postgres:** в **`clinic_tests`** — только сущности модуля тестирования (тесты, версии, назначения, попытки, локальные технические учётки при необходимости). В **`hr_bot_test`** (Postgres_TG_Bots / hr_web_viewer) — штат, справочники, существующий **RBAC** и веб-логины. Так мы не смешиваем схемы и не дублируем «источник правды» по людям.
- **Сотрудник в процессах** (назначения, дашборды, доступ к результатам) — везде по **`staff_members.id`**. Ссылки в `clinic_tests` храним как **тот же идентификатор** (логическая связь с `staff_members` в `hr_bot_test`); **ФИО, отдел, роли** подтягиваем из HR при отображении или кэшируем по согласованной политике, а не ведём второй кадровый учёт.
- **`telegram_id`** в данных сотрудника **не участвует** в бизнес-логике модуля: ни вход, ни проверка прав, ни выбор сотрудника в сценариях, ни фильтрация — только **справочная** информация при необходимости (отображение, история).
- **RBAC в перспективе:** единая система разрешений — та, что уже в HR (роли, `staff_role_assignments`, permissions). Модуль тестирования **не** развивает отдельную полную копию матрицы; проверка действий в целевом виде — через **HR** (внутренний API / токен / согласованные запросы к БД). Пока договор и API не готовы — допустимы временные флаги в `clinic_tests`, явно помечаемые как MVP.
Детализация задач и варианты A.x: [docs/revision_task/card1.md](docs/revision_task/card1.md).
---
## Нефункциональные требования