Администратор

Роль: admin Полномочия: is_staff=True, is_superuser=True. Доступ ко всему — Django Admin, дашборд, все API-эндпоинты.

Чем занимается администратор

• Управляет пользователями всех ролей — создаёт, деактивирует, меняет роли.
• Ведёт клиентскую базу — клиенты, контактные лица, объекты.
• Планирует и создаёт наряды наравне со штатным staff (см. руководство сотрудника → Планирование и создание наряда).
• Управляет шаблонами отчётов — создаёт, редактирует, помечает шаблон по умолчанию.
• Настраивает уведомления — для каждого подписчика индивидуально.
• Поддерживает справочники — материалы, услуги, цены.
• Рецензирует отчёты наравне со штатным staff.
• Решает инциденты — отзывает приглашения, переотправляет уведомления, исправляет данные.

Как зайти в систему

Веб-дашборд: /{ru|en}/dashboard/reports. Django Admin: /admin/. Логин — email + пароль из Supabase Auth.

Управление пользователями

Создание

Через Django Admin (/admin/account/user/add/):

1. Указать email, имя, фамилию.
2. Выбрать роль (admin / staff / brigadier / worker / client).
3. Сохранить. Пароль для входа в Supabase Auth должен быть установлен отдельно — через Supabase Studio (localhost:54323 локально / прод-Studio).

Альтернатива: staff/admin создаёт ContactPerson для клиента и отправляет приглашение — пользователь сам регистрируется по ссылке.

Изменение роли

Поле User.role в Django Admin. После сохранения нужно синхронизировать роль в Supabase Auth — фронтенд читает её из app_metadata.role JWT. Это делается:

• автоматически при следующем перевыпуске токена;
• вручную: фронтенд вызывает Edge Function set-role (внутри сценария «обновить роль»).

Деактивация

Снять User.is_active. Пользователь не сможет войти. Записи (наряды, отчёты) сохраняются.

Управление клиентской базой

См. руководство сотрудника — у admin те же сценарии плюс редактирование напрямую через Django Admin.

Шаблоны отчётов

Путь в Django Admin: Report → Report survey templates.

Шаблон — это JSON-схема в формате SurveyJS (template_json). Каждый шаблон имеет:

• name, version — пара уникальна.
• description.
• is_default — ровно один шаблон в системе помечается этим флагом.

Важно: изменение template_json НЕ влияет на уже созданные отчёты — они хранят свой снимок (Report.template_json_snapshot). Чтобы изменения попали в новые отчёты — обновляйте шаблон.

Создание нового шаблона. Самый простой путь:

python manage.py seed_report_templates

Команда читает дефолтный JSON из кода и обновляет шаблон. Для нестандартных шаблонов — копируйте JSON в Django Admin, версию инкрементируйте.

Настройки уведомлений

Уведомления настраиваются индивидуально для каждого подписчика — пользователя или контактного лица.

В карточке User (для ролей admin/staff/brigadier) и ContactPerson есть inline-блок «Notification preferences». Там видны все подписки в виде:

Topic           Channel    Enabled
work_started    email      [✓]
work_completed  email      [✓]
report_submitted email     [✓]

Что можно делать:

• Поставить или снять галку enabled — топик включается/выключается для подписчика.
• Добавить новую запись — например, продублировать топик с каналом telegram, если у пользователя есть TelegramLink.
• Удалить запись — после удаления применится ролевое умолчание (если есть).

Ролевые умолчания задаются в коде (modules/notification/services/defaults.py). При создании нового пользователя/контакта signal автоматически создаёт записи по умолчаниям — поэтому обычно ручная настройка не нужна.

Подробнее о маршрутизации и каналах — в Архитектура → Уведомления.

Рецензирование отчётов

Сценарий идентичен сотруднику — см. руководство сотрудника → Рецензирование.

Справочники

В Django Admin доступны:

• Materials (mtrl_*) — расходники с SKU.
• Material prices — история цен (effective_from).
• Services (srv_*) — виды работ со slug и category.
• Service prices — история цен на услуги.

При создании ServiceVisitMaterial / ServiceVisitService (это происходит автоматически при утверждении отчёта) — фиксируется текущая цена из истории.

Django Admin и история изменений

Все ключевые модели показывают историю (Object history справа сверху). История пишется через simple_history в таблицы historical_*. По каждой записи видно:

• Когда изменена (history_date).
• Кем (history_user).
• Что изменилось (поле сравнения двух соседних версий).

Это полезно при разборе инцидентов — «кто и когда сменил адрес объекта», «когда отчёт ушёл в rejected», и т. п.

Типичные задачи и где их делать