Настройки системы

Общие настройки биллинга и шаблоны печати. Отдельными страницами: фискализация, платёжные системы, банковские выписки, обмен с 1С, почта и домены.

Интерактивные схемы этого раздела

Тот же механизм, но нарисованный: узлы можно подсвечивать, связи — разбирать по шагам. Открывается в новой вкладке.

Банковская выписка Поток данных Путь чека до ОФД Состояния Разделение по организациям Поток данных

Все схемы системы

Настройки

Раздел меню «Настройки» объединяет все параметры биллинга, интеграции, шаблоны печати, управление персоналом и обслуживание базы данных.

Настройки системы

Единая страница системных параметров (/admin/settings/system/). Вкладки идут по частоте использования — первой открывается «Брендинг», диагностические (Аудит, Логи, Скорость, EBS-виджет) уходят в конец; не поместившиеся сворачиваются в пункт «Ещё N» (компонент SmitChipBar), справа — строка поиска настройки (Ctrl+K). Все параметры страницы общесистемные — общие для всех организаций; фирменный стиль конкретной компании (логотип, цвета, название) задаётся отдельно, в её карточке в разделе Справочники → Организации.

12 вкладок: Брендинг · Безопасность · Блокировки · Прокси · Сообщения · RADIUS · Профиль · Маркетинг · Аудит · Логи · Скорость · EBS-виджет. Карточки внутри вкладки раскладываются masonry — пакуются по фактической высоте, без пустот от равновысоких рядов, плоскими (без теней) и на всю ширину экрана. Кнопки «Сохранить» неактивны, пока нет изменений (js-dirty-save); тёмная тема оформлена полностью, включая поля ввода.

flowchart LR
  P["⚙ Настройки системы"]:::root
  P --> G1["Оформление
и доступ"]:::g
  P --> G2["Сеть, биллинг,
связь"]:::g
  P --> G3["Диагностика"]:::g
  G1 --> Brand["Брендинг
по умолчанию"]
  G1 --> Sec["Безопасность"]
  G1 --> Prof["Профиль клиента"]
  G2 --> Blk["Блокировки"]
  G2 --> Rad["RADIUS"]
  G2 --> Prx["Прокси"]
  G2 --> Msg["Сообщения"]
  G2 --> Mkt["Маркетинг"]
  G2 --> Ebs["EBS-виджет"]
  G3 --> Aud["Аудит"]
  G3 --> Log["Логи"]
  G3 --> Perf["Скорость"]
  classDef root fill:#2b8455,stroke:#256a47,color:#fff;
  classDef g fill:#e8f5e9,stroke:#43b77a,color:#14532d;

Вкладка «Брендинг» — фирменное оформление по умолчанию

Открывается по умолчанию. Название продукта, логотип, favicon, акцентный цвет, контактные данные. Применяется в админке, в личном кабинете, в шаблонах печати и для записей без привязки к организации. Модуль «Свой бренд» (Whitelabel) снимает ограничения на замену названия продукта.

Вкладка «EBS-виджет» — синхронизация с EBS

Управление переносом данных из внешней системы EBS: платежи (задача каждые 10 минут), счета/абоненты, обещанные платежи и сверка балансов (reconcile) раз в час. Фильтр «какие типы операций переносить» не даёт задвоить то, что биллинг принимает сам (модуль выписок, ЮKassa). Кнопки на единых компонентах: «Сохранить» неактивна без изменений, быстрые действия выбора типов — на SmitButton.

Вкладка «Безопасность» — политика финансовых операций

На Безопасности — глобальные ограничения для ручных финансовых операций (создание/редактирование/удаление через UI). Доступна только пользователям группы root или is_superuser=True.

5 настроек (все по умолчанию выключены — стандартное поведение Django admin):

Все ограничения проверяются и в backend (HTTP 403/400 на endpoints finops_ajax, finops_crud_ajax, FinOpChangeView) и в frontend (кнопки/ссылки/поля скрыты в HTML).

Важно: ограничения касаются только ручных операций через UI. Автоматические процессы — Celery worker billing_worker для абонплаты, webhook ЮKassa, обещанный платёж, auto-block по отрицательному балансу — работают как обычно, без проверок. Это нужно чтобы политика «только суперюзер» не сломала автоматическое начисление.

Вкладка «Безопасность» — авторизация: FIDO2, reCAPTCHA, блокировка, сессии

Ниже блока «Финансовые операции» на странице /admin/settings/system/security/ расположены 4 блока управления безопасностью входа.

Все настройки в категории security, по умолчанию выключены. Миграция 0230 добавляет модель StaffWebAuthnCredential (passkey сотрудников).

Вкладка «Аудит» — настройки журнала действий по клиентам

Управление параметрами вкладки Аудит в карточке клиента и общим поведением логирования. Доступна по адресу /admin/settings/system/?tab=audit только пользователям группы root или с is_superuser=True.

Все 4 настройки хранятся в таблице system_settings (category = audit), читаются через хелперы в billing/services/settings_service.py (get_audit_default_period_months(), get_audit_per_page(), get_audit_csv_export_limit(), is_audit_hide_system_events()) с clamp в коде на случай некорректного значения в БД.

Срок хранения записей аудита (по умолчанию 365 дней) настраивается отдельно в разделе Очистка БД — параметр DB_CLEANUP_AUDIT_DAYS. Это сделано чтобы retention-политика управлялась рядом с другими параметрами очистки (MSG_STACK, RADIUS_SESSIONS), а не дублировалась.

Быстрый переход в настройки: для пользователей с is_superuser=True в toolbar вкладки «Аудит» карточки клиента появляется иконка-шестерёнка справа от кнопки CSV-экспорта — клик ведёт прямо в /admin/settings/system/?tab=audit.

Вкладка «Логи» — хранение и уровень логирования

Управление файлами журналов в /var/log/django/: ротация, сжатие, уровень логирования Django и FreeRADIUS. Без ограничения по сроку хранения журнал FreeRADIUS на уровне trace вырастает до десятков гигабайт за месяц.

Параметры:

Справа на вкладке — таблица текущего размера всех файлов в /var/log/django/ с подсветкой больших (≥100 МБ оранжевый, ≥1 ГБ красный). Клик по имени файла → переход в просмотр содержимого (/admin/reports/dev/logs/).

Вкладка «Скорость» — Gunicorn / Celery / БД / Throttling (переименована)

Параметры процессов и ресурсов. Изменения требуют перезапуска контейнеров (web, celery). 4 группы настроек раскладываются masonry + статус-блок снизу.

Статус-блок снизу (read-only метрики, обновляется при загрузке страницы): CPU, RAM, Load average, PostgreSQL соединений (с алертом если >80%), размер БД, Celery очередь, Redis память.

Вкладка «RADIUS» — таймауты, retention, NAS auto-assign (переименована)

Параметры RADIUS-сессий, NAS-мониторинга и хранения истории. Применяются при следующей авторизации или ближайшем прогоне Celery beat (cleanup-stale-sessions — каждую минуту, db-cleanup-daily — раз в сутки по интервалу 86400 с от старта Celery beat, без привязки к фиксированному часу).

Статус-блок снизу: NAS всего / UP / DOWN (если есть), Сейчас онлайн (LOGGED), Активных RADIUS-сессий, Расхождение, размер таблиц RADIUS_SESSIONS / AUDIT_OPERATIONS / MSG_STACK.

Вкладка «Сообщения клиентам» — политика уведомлений

Единая страница для управления всеми каналами доставки сообщений: Email, SMS, Push, Telegram, VK. Объединяет настройки из 4 разных мест в одну ментальную модель оператора («Сообщения»). 4 группы раскладываются masonry + статистика снизу.

Подключение: billing/services/notification_policy.py::should_send(channel, abonent_id, head_txt, kind, phone) вызывается в billing/tasks/messaging.py:_dispatch_message для каждого канала. Порядок проверок: общий выключатель → канал → стоп-лист → тихий час → антидубль (стоп-лист раньше антидубля, чтобы запрещённое сообщение не ставило отметку «уже отправлено»). SMS из очереди повторно не уходит: у каждого сообщения своя запись в журнале отправок, и перезапуск задачи после сбоя его пропускает. Пропущенные сообщения логируются в MsgStack.sms_status='skipped' с sms_error=причина — оператор видит почему сообщение не доставлено.

Шлюзы каждого канала настраиваются в отдельных разделах: Email /admin/settings/email/, SMS /admin/settings/sms/, Push /admin/settings/firebase/. Здесь — общая политика на уровне всей системы.

Статистика снизу: отправлено сегодня по каналам, в очереди, SMS-ошибки, SMS-пропуски (тихий час / дубль), бейдж «Тихий час сейчас».

Доступ суперпользователя — 2FA, IP-ограничение, политики паролей

В правой колонке вкладки Безопасность — карточка «Доступ суперпользователя». Все политики применяются только к is_superuser и по умолчанию выключены (поведение входа не меняется, пока администратор не включит их осознанно). Управление доступно только суперпользователю.

Двухфакторная аутентификация (TOTP). Подключение в профиле: сканируете QR-код приложением-аутентификатором, подтверждаете кодом — 2FA активна. При активации выдаются 10 резервных кодов (формат XXXX-XXXX, показываются один раз) — на случай потери телефона. При входе после логина/пароля запрашивается 6-значный код (можно ввести backup-код). Отключить 2FA нельзя, пока включена политика «Обязательная 2FA».

Защита от self-lockout: все политики выключены по умолчанию; backup-коды 2FA; IP-список fail-open при пустоте; аварийный сброс через консоль сервера (set_setting('SU_REQUIRE_2FA', False)). Каждое изменение политик пишется в AuditOperations.

Подключение: billing/services/su_security.py (логика IP/2FA/паролей), billing/views/auth.py (вход), billing/views/profile.py (2FA + смена пароля).

Вкладка «Блокировки и финансы» — captive-portal + бизнес-правила

Управление блокировкой клиентов за долг и базовыми правилами биллинга. 4 группы 2×2 + статус блокировок. Закрывает давнюю боль «Не авторизовать по RADIUS при отрицательном балансе» и задачу №4 Марии (captive-portal).

Подключение: billing/services/block_policy.py в 4 точках кода — radius_python/internet.py:authorize() (kill-switch ДО soft-block), billing/models/abonents.py:block() (пропуск CoA), billing/tasks/billing_worker.py:_process_service() (skip списания), billing/views/finops_list.py (queryset filter).

Статус-блок снизу: Активных / Заблокированных клиентов, по b_negbal / b_admin / b_own, активных Обещанных Платежей, заблокировано/разблокировано сегодня. Большой красный alert над формой если включён аварийный kill-switch.

Вкладка «Прокси» — пул прокси для Telegram и Нейросети

Из России api.telegram.org и внешние API AI-провайдеров недоступны — биллинг ходит к ним через прокси. Раздел Настройки системы → Прокси (/admin/settings/system/proxy/) — единый пул прокси с ролями, авто-проверкой и журналом. Заменил прежний блок «Прокси для Telegram» из Интеграций (старые плоские ключи остаются как fallback).

Как работает выбор прокси (fallback):

Переключатель «Использовать прокси»

Глобальный тоггл сверху. Выключен → get_api_proxies() возвращает None, Telegram/Нейросеть подключаются напрямую (настройка PROXY_ENABLED в БД). При выключении форма/таблица/журнал скрываются.

Добавление прокси

Список прокси по одному на строку. Поддерживаемые форматы: ip:port:login:password, login:password@ip:port, ip:port (без авторизации). Тип — Авто-определение (по умолчанию; живая проба HTTP→SOCKS5), HTTP или SOCKS5. Роли — «для Telegram» / «для Нейросети» (можно обе). При добавлении параллельно определяется тип и геолокация по IP (ip-api.com). Прокси добавляется всегда, даже если автопроверка не достучалась — со статусом 🔴 и подсказкой (например провайдер отвечает 407 при неверных кредах / IP-binding).

Таблица «Прокси-серверы»

Колонки: Тип (бейдж HTTP/SOCKS5), Адрес (ip:port, иконка-ключ + тултип логин/пароль), Гео (флаг страны + город), Роли (TG / Нейросеть), Статус (🟢 доступен · 🔴 недоступен · ⚪ не проверялся, с латентностью в тултипе), Приоритет, Ред (kebab-меню действий). Действия в kebab: Проверить, Включить/Выключить, Назначить роль (Только Telegram / Только Нейросеть / Обе), Удалить.

«Проверить все» — проверяет все прокси и расставляет приоритеты: живые по возрастанию задержки (быстрый = приоритет 1), мёртвые в конец. Если есть нерабочие — кнопка превращается в «Удалить нерабочие (N)».

Автопроверка и уведомления

Celery beat proxy-pool-check проверяет пул каждые PROXY_CHECK_INTERVAL_MIN минут (default 60). При переходе прокси в недоступное состояние и при полном отсутствии живых прокси для роли — Telegram-алерт (тоггл PROXY_ALERTS_ENABLED). События пишутся в Аудит (добавление/удаление — с указанием кто, системное «нет доступных прокси»).

Журнал событий

Правая колонка — последние 50 событий (проверки, переходы up/down, добавление/удаление) с авто-обновлением каждые 30с. Кнопка «Скачать» выгружает журнал в CSV (до 1000 записей).

Тёмная тема и работа с телефона поддержаны. Потребители прокси (Telegram-рассылки, AI-чаты ЛК/мобильного, геокодер и др., ~18 точек) используют пул автоматически через get_api_proxies().

Шаблоны печати

Документы, которые сотрудник печатает из карточки клиента, финансовой операции или заявки: договор, счёт, акт, кассовый ордер, счёт-фактура. Шаблон — HTML с подстановками языка шаблонов Django ({{ org.legal_name }}, {{ abonent.name }}, {{ summa_due|floatformat:2 }}, {% if … %}). Реквизиты, логотип, печать и цвет берутся из брендинга организации записи. Раздел: Настройки → Шаблоны печати (/admin/settings/print_forms/).

• Сводка — сколько шаблонов и чей фирменный стиль подставляется: организация из шапки, цвет, есть ли логотип. Если реквизиты организации заполнены не все, рядом ссылка на брендинг.
• Срезы по разделу, где печатается документ, и поиск по названию и файлу.
• Для операции — у какого типа финансовой операции появится кнопка печати: акт — 1, оплата — 2, счёт — 5, договор — 6, счёт на предоплату — 9, счёт-фактура — 14, расторжение — 15.
• Меню строки: открыть, предпросмотр, сделать копию, удалить.

Окно шаблона

Три вкладки: Шаблон, Предпросмотр и Параметры.

• Шаблон — редактор кода с подсветкой подстановок и тегов. Справа — подстановки по группам (организация, документ, клиент, суммы): нажатие вставляет её в место курсора, «Логотип» и «Печать» вставляются сразу с условием, чтобы при пустом брендинге не было битой картинки.
• Предпросмотр — шаблон на последней подходящей записи. Если операций нужного типа ещё нет (так бывает со счетами и договорами), берётся последняя операция любого типа. Предпросмотр ничего не сохраняет и не создаёт.
• Параметры — название, где печатается, для какой операции, формат (HTML или DOCX), размер и ориентация листа, файл шаблона.

• Сохранение проверяет, что шаблон разбирается: незакрытый {% if %} или {% for %} останавливает сохранение с номером строки. Раньше такая ошибка всплывала только при печати документа клиенту.
• Перед сохранением — окно со списком изменений, в журнал действий (PRINT_FORMS) пишется то же словами; сохранение без изменений ничего не пишет.
• Создавать, менять и удалять шаблоны может сотрудник с правом «Настройки · Финансы»; остальные видят шаблоны только на чтение.

AI-помощник: создать шаблон в фирменном стиле

Помощник раздела (кнопка в правом нижнем углу или «AI» в редакторе) знает фирменный стиль организации — цвет, шрифт, логотип, печать, реквизиты — и все подстановки шаблонов.

flowchart LR
  A["Создать новый шаблон"] --> Q["До трёх вопросов:
какой документ,
где печатать, что в нём"]
  Q --> D["Шаблон в фирменном
стиле организации"]
  D --> OK{"Открыть в окне?"}
  OK -->|"да"| W["Окно «Новый шаблон»:
поля заполнены,
открыт предпросмотр"]
  W --> S["Сотрудник проверяет
и сохраняет"]

• Создать новый шаблон — помощник задаёт уточняющие вопросы с готовыми вариантами ответа (можно ответить своими словами), собирает шаблон и открывает окно «Новый шаблон» с заполненными названием, разделом, типом операции и листом.
• Оформить в фирменном стиле и Проверить шаблон — для открытого шаблона. Помощник видит и несохранённый текст из редактора; исправленный шаблон заменяет текст в окне только после подтверждения.
• Помощник ничего не сохраняет: сохраняет сотрудник, как при ручной правке. Разговор и расход попадают в общий журнал AI.