ролевая моделю доступа + загруженность по кафедрам и преподавателям + просморт расписания

docs/BUSINESS_LOGIC.md

@@ -2,19 +2,33 @@
 
 ## Ролевая модель
 
-Система поддерживает три роли пользователей:
+Система поддерживает шесть ролей пользователей:
 
 | Роль | Enum | Возможности |
 |------|------|------------|
-| **Администратор** (Деканат) | `ADMIN` | Полный доступ: CRUD пользователей, групп, аудиторий, дисциплин, расписания. Управление тенантами (БД). |
+| **Администратор** | `ADMIN` | Полный доступ: пользователи, справочники, тенанты, роли, архивирование и восстановление. |
+| **Учебный отдел** | `EDUCATION_OFFICE` | Редактирование расписания, точечные переносы/замены/отмены, временные слоты, аудитории, загруженность. |
+| **Кафедра** | `DEPARTMENT` | Дисциплины своей кафедры, загрузка дисциплин, привязки преподавателей, комментарии, расписание и нагрузка кафедры. |
+| **Просмотр расписаний** | `SCHEDULE_VIEWER` | Read-only просмотр расписаний по группам, преподавателям, аудиториям и кафедрам в недельных матричных таблицах. |
 | **Преподаватель** | `TEACHER` | Просмотр своего расписания. В перспективе — подача заявок на перенос. |
 | **Студент** | `STUDENT` | Только просмотр расписания (Read-only). |
 
 После авторизации пользователь перенаправляется на свой интерфейс:
 - `ADMIN` → `/admin/`
+- `EDUCATION_OFFICE` → `/admin/#schedule-view`
+- `DEPARTMENT` → `/admin/#department-workspace`
+- `SCHEDULE_VIEWER` → `/admin/#schedule-view`
 - `TEACHER` → `/teacher/`
 - `STUDENT` → `/student/`
 
+Bearer-токен проверяется на backend. Frontend-скрытие пунктов меню является только удобством, а не источником прав.
+
+Для роли `DEPARTMENT` backend дополнительно ограничивает изменения рамками кафедры текущего пользователя:
+
+- загрузка и комментарии дисциплин идут через `/api/department/*`;
+- общий `/api/subjects` доступен кафедре только на чтение;
+- привязки `/api/teacher-subjects` разрешены только если преподаватель и дисциплина относятся к кафедре текущего пользователя.
+
 ---
 
 ## Управление ресурсами
@@ -52,6 +66,7 @@
 - **Поля:** Название (уникальное), вместимость (> 0), корпус, этаж, доступность
 - **Оборудование:** К каждой аудитории привязывается список оборудования (Many-to-Many) с указанием количества
 - **Статус:** Флаг `is_available` для блокирования назначения пар
+- **Жизненный цикл:** `status=ARCHIVED` означает вывод из эксплуатации. Такая аудитория отображается в прошлом расписании, но запрещена для новых назначений.
 
 ### Оборудование (Equipments)
 
@@ -64,6 +79,26 @@
 
 - **Поля:** Название (уникальное), код, кафедра, описание
 - Привязка преподавателей через `teacher_subjects` (Many-to-Many)
+- Кафедра может добавлять комментарии к дисциплине и загружать список дисциплин через кабинет кафедры
+
+### Жизненный цикл справочников
+
+Справочники, которые участвуют в расписании и отчётах, не удаляются физически. Для них используется архивирование:
+
+- `ACTIVE` — запись доступна для выбора;
+- `ARCHIVED` — запись остаётся в истории, но не используется в будущих назначениях.
+
+Архивирование уже применяется к пользователям, аудиториям, оборудованию, кафедрам, специальностям, группам, подгруппам, дисциплинам и профилям обучения. Исторические отчёты используют записи, действовавшие на дату занятия.
+
+### Перевод преподавателей между кафедрами
+
+Текущая кафедра преподавателя хранится в `users.department_id`, но история переводов фиксируется в `teacher_department_assignments`.
+
+Правила:
+
+- у преподавателя должна быть одна открытая основная кафедра;
+- при переводе старая запись закрывается датой `valid_to`, новая открывается с `valid_from`;
+- расписание и отчёты за прошлые периоды не теряют связь с прежней кафедрой.
 
 ---
 
@@ -86,6 +121,7 @@
 | `schedule_rule_groups` | Группы правила, включая потоковые лекции |
 | `schedule_rule_slots` | День, чётность, слот, преподаватель, аудитория, тип и формат занятия |
 | `schedule_rule_slot_subgroups` | Подгруппы лабораторного слота |
+| `schedule_overrides` | Точечные переносы, отмены и замены конкретных сгенерированных пар |
 
 Генератор `ScheduleGeneratorService` рендерит расписание по запросу:
 1. Определяет семестр для каждой даты диапазона.
@@ -98,6 +134,7 @@
 8. Подставляет эффективную сетку времени даты: ручную, субботнюю или базовую.
 9. Считает уже проведённые часы отдельно для лекций, практик и каждой лабораторной подгруппы.
 10. Останавливает вывод слотов конкретного типа, когда достигнут его лимит часов.
+11. Применяет точечные изменения из `schedule_overrides` в расширенном поиске и отчётах.
 
 Лабораторные работы могут делиться на подгруппы через `schedule_rule_slot_subgroups`. Если подгруппы выбраны, занятие выводится только для родительских групп этих подгрупп, а лимит лабораторных часов списывается отдельно по каждой подгруппе. Если лабораторная проводится у нескольких групп одновременно, один слот может содержать разные подгруппы разных групп. Лекции и практики не делятся на подгруппы.
 
@@ -129,6 +166,18 @@
 - **Связанные сущности:** базовый временной слот, преподаватель, аудитория и тип занятия должны существовать в БД.
 - **Подгруппы:** `subgroupIds` разрешены только для лабораторных слотов, должны относиться к группам правила, и в одном слоте можно выбрать не больше одной подгруппы каждой группы.
 - **Формат:** `lessonFormat` обязателен и хранится в слоте правила.
+- **Жизненный цикл:** архивные преподаватели, аудитории, группы и дисциплины не принимаются в новых правилах.
+- **Доступность аудитории:** `is_available=false` запрещает новые назначения, но не удаляет историю.
+
+### Точечные изменения расписания
+
+Учебный отдел может создать изменение конкретной пары:
+
+- `CANCEL` — отменить пару;
+- `MOVE` — перенести пару на другой временной слот или в другую аудиторию;
+- `REPLACE` — заменить преподавателя, аудиторию или формат.
+
+Изменения не переписывают базовое правило, а накладываются поверх сгенерированного расписания на конкретную дату.
 
 ---