105 lines
11 KiB
Markdown
Executable File
105 lines
11 KiB
Markdown
Executable File
# Отчёт №1 — Роли и ограничения (для согласования с заказчиком)
|
||
|
||
Документ описывает роли портала МКД, их ограничения по разделам и данным, связь с базой данных и соотношение с ролями workflow согласования счетов. После согласования используется как основа для отчёта №2 и переработки логики прав.
|
||
|
||
---
|
||
|
||
## 1. Список ролей портала (после переработки)
|
||
|
||
Рекомендуется сохранить текущие коды ролей в БД. Ниже — код, название для UI и краткое описание назначения.
|
||
|
||
| Код (БД) | Название для UI | Описание назначения |
|
||
|------------|-----------------|----------------------|
|
||
| DIRECTOR | Директор | Полный доступ ко всем разделам портала. Руководство, контроль показателей, настройки. |
|
||
| ENGINEER | Гл. Инженер | Производство, участки, заявки, офис, развитие. Оперативное управление технической и производственной частью. |
|
||
| MASTER | Мастер | Участки и заявки. Работа в рамках назначенных участков (дома, заявки, штат участка). |
|
||
| LAWYER | Юрист | Сводка, юр. отдел, участки, заявки. Работа с договорами, судами, досудебной работой, долгами. |
|
||
| FINANCIER | Финансист | Сводка, финансы, офис, участки. Реестр счетов, календарь оплат, отчёты, закупки. |
|
||
| HR_MANAGER | HR-менеджер | Сводка, кадры, офис. Сотрудники, календарь, вакансии, подбор, охрана труда. |
|
||
| PR_MANAGER | PR-менеджер | Сводка, PR и NPS, заявки. SMM, мероприятия, обратная связь, отчёты, NPS, негатив. |
|
||
|
||
---
|
||
|
||
## 2. Ограничения по каждой роли
|
||
|
||
### 2.1 Разделы по умолчанию
|
||
|
||
При пустом поле `permissions` у пользователя применяются разделы по роли (из таблицы ниже). «all» означает доступ ко всем разделам портала.
|
||
|
||
| Роль | Разделы по умолчанию |
|
||
|------------|------------------------|
|
||
| DIRECTOR | all (все разделы) |
|
||
| ENGINEER | dashboard, objects, requests, office, development |
|
||
| MASTER | objects, requests |
|
||
| LAWYER | dashboard, legal, objects, requests |
|
||
| FINANCIER | dashboard, finance, office, objects |
|
||
| HR_MANAGER | dashboard, hr, office |
|
||
| PR_MANAGER | dashboard, pr, requests |
|
||
|
||
Соответствие кодов разделов и названий: dashboard — Сводка; objects — Участки; requests — Заявки; pr — PR и NPS; finance — Финансы; legal — Юр. отдел; development — Развитие; hr — Кадры; office — Офис; admin — Панель управления.
|
||
|
||
### 2.2 Уровень доступа по умолчанию
|
||
|
||
По умолчанию для роли по всем доступным разделам и подразделам задаётся уровень **«редактирование»** (edit): пользователь может просматривать и изменять данные в рамках своих разделов. Различие «только чтение» / «только своё» задаётся только через кастомные `permissions` у пользователя или через шаблоны прав.
|
||
|
||
### 2.3 Ограничение по данным (участки)
|
||
|
||
| Роль | Scope по умолчанию | Пояснение |
|
||
|------------|--------------------|------------|
|
||
| DIRECTOR | all | Все участки |
|
||
| ENGINEER | all | Все участки |
|
||
| MASTER | own_district | Только свои назначенные участки (из employee_districts / assigned_district_id) |
|
||
| LAWYER | all | Все участки |
|
||
| FINANCIER | all | Все участки |
|
||
| HR_MANAGER | all | Все участки |
|
||
| PR_MANAGER | all | Все участки |
|
||
|
||
При `scope = own_district` список разрешённых участков для фильтрации данных (дома, заявки и т.д.) формируется из таблицы **employee_districts** (многие ко многим); при отсутствии записей — из поля **employees.assigned_district_id**.
|
||
|
||
### 2.4 Особые ограничения
|
||
|
||
- **Счета на оплату:** в API поддерживается параметр `scope=own` — показ только счетов, созданных текущим пользователем (`created_by = employee_id`). Это отдельно от роли портала и может использоваться для любой роли при необходимости.
|
||
- **Workflow согласования счетов** задаётся таблицей **user_roles** (manager, finance_manager, director и т.д.) и не дублирует роли портала (см. раздел 4).
|
||
|
||
При необходимости в будущем можно ввести особые ограничения вида «только свои заявки» через уровень доступа «только своё» (own) по подразделу и проверки на бэкенде.
|
||
|
||
---
|
||
|
||
## 3. Связь с базой данных
|
||
|
||
### 3.1 portal_users
|
||
|
||
- **role** (VARCHAR) — код роли портала (DIRECTOR, ENGINEER, MASTER, LAWYER, FINANCIER, HR_MANAGER, PR_MANAGER).
|
||
- **permissions** (JSONB) — массив строк прав. Если массив не пустой — используются только эти права (разделы/подразделы и уровни); иначе применяются права по роли из единого справочника (ROLE_ACCESS и уровень edit по умолчанию).
|
||
- **scope** (VARCHAR: 'all' | 'own_district') — ограничение по участкам: все участки или только назначенные сотруднику.
|
||
|
||
При пустом `permissions` бэкенд и фронт вычисляют доступ по полю `role` и единому справочнику разделов/уровней по умолчанию.
|
||
|
||
### 3.2 employees и участки
|
||
|
||
- **employees.assigned_district_id** (VARCHAR, один участок) — для обратной совместимости; используется как fallback, если у сотрудника нет записей в employee_districts.
|
||
- **employee_districts** (таблица связей employee_id, district_id) — многие ко многим: один сотрудник может быть назначен на несколько участков.
|
||
|
||
При **scope = own_district** список доступных district_id для фильтрации данных должен формироваться так: сначала выборка из **employee_districts** по employee_id пользователя; если записей нет — использовать **assigned_district_id** (один участок). Все API, которые фильтруют данные по участку (дома, при необходимости заявки, отчёты и т.д.), должны использовать этот единый список.
|
||
|
||
### 3.3 permission_templates
|
||
|
||
- Шаблоны хранят: name, description, **permissions** (JSONB), **scope**, for_position, suggested_role. Применение шаблона к пользователю подставляет permissions и scope (и при необходимости suggested_role) в portal_users. Структура БД менять не требуется; при переработке важно сохранять тот же формат permissions и scope.
|
||
|
||
### 3.4 Новые поля или таблицы
|
||
|
||
- Текущей модели достаточно. Матрица «роль → разделы/уровень/scope» по умолчанию может храниться в едином модуле констант в коде (общий для фронта и бэкенда). При желании в будущем можно вынести матрицу в таблицу (например, role_default_access) для настройки без деплоя.
|
||
|
||
---
|
||
|
||
## 4. user_roles (workflow) и роли портала
|
||
|
||
- **user_roles** — таблица для цепочки согласования счетов на оплату. Роли: manager, finance_manager, financier, finance_director, director, top_management. Используются только в модуле согласования счетов (paymentInvoiceWorkflow и связанные API).
|
||
- **Роли портала** (portal_users.role) определяют доступ к разделам и данным портала (меню, вкладки, фильтр по участкам). Они не задают права согласования счетов.
|
||
- Связывать user_roles с portal_users.role не обязательно: один и тот же человек может быть DIRECTOR в портале и не иметь роли в user_roles, или иметь роль manager/finance_manager в user_roles при другой роли в портале.
|
||
- В админке целесообразно показывать «роль в портале» и «роли в workflow» отдельно (например, в карточке пользователя — раздел «Согласование счетов» с назначением ролей из user_roles).
|
||
|
||
---
|
||
|
||
После согласования данного отчёта переходим к отчёту №2: большая таблица доступов (раздел × подраздел × роль), рекомендуемые шаблоны прав и пошаговый план переписывания логики прав с чек-листом файлов.
|