- Добавлен эндпоинт удаления комментариев к заявкам (DELETE /api/v1/requests/{pk}/comments/{comment_id}/)
- Исправлены references на переменную в сигналах комментариев (comment -> instance)
- Добавлена обработка статуса cancelled для заявок в notification_type_map
- Обновлены процессоры уведомлений в task_base.py (правильные поля моделей)
- Создан скрипт генерации тестовых пользователей (scripts/create_test_users.py)
Обновлены сигналы для полностью асинхронной обработки:
- requests_app: новые заявки, комментарии, изменения статуса
- documents: новые документы для всех сотрудников
Добавлена задача process_document_notifications_task
Все циклы for recipient in recipients теперь выполняются в фоне:
✅ Сигналы используют transaction.on_commit + .delay()
✅ Signal handlers сразу возвращают управление
✅ API не блокируется при массовых рассылках
Fixes: Блокировка транзакций при создании заявок/документов
- Добавлена конфигурация Celery (eusrr_backend/celery.py)
- Созданы async задачи для уведомлений (notifications/tasks.py)
- Обновлены все notification_signals на create_notification_async()
- Добавлен метод NotificationService.create_notification_async() с fallback
- Установлены пакеты: django-celery-beat, django-celery-results, flower
- Применены миграции для Celery приложений
- Документация: CELERY_SETUP.md, CELERY_INTEGRATION_PLAN.md
Производительность: уменьшение времени отправки сообщений с ~500ms до <50ms
- Удалено исключение employee.id из notify_status_change()
- Коммит 087cff79 ошибочно исключал автора, предполагая что он видит результат на странице
- После удаления alert() в коммите 1a5de8c уведомление стало единственным способом информирования
- Теперь автор получает уведомление о одобрении/отклонении заявления
- Approver остается исключенным (он сам нажал кнопку, не нужно ему уведомление)
Fixes: Users not receiving notifications when their request is approved/rejected
- Полная переделка шаблона request_detail.html с единообразными стилями
- Новая структура: основная карточка (8 колонок) + боковая панель комментариев (4 колонки)
- Единообразные иконки типов заявлений (calendar-check, capsule, umbrella-fill и т.д.)
- Единообразные бейджи статуса и типа как в списке
- Информационные блоки для автора, описания, получателей, одобрившего
- Форма комментариев с правильным стилем message-field--compact
- Emoji picker с поддержкой dropdown-menu поверх контента
- AJAX обработка отправки и удаления комментариев
- Новый CSS файл request-detail.css с адаптивностью
- Добавлена функция _add_type_display() в views.py для отображения типа
Улучшения:
- Единство дизайна со страницей списка заявлений
- Правильное позиционирование emoji picker (fixed positioning)
- Sticky боковая панель с комментариями
- Форма комментария как в ленте (message-field--compact)
- Кнопки одобрения/отклонения с правильными иконками
ПРОБЛЕМА: Уведомления не отправлялись при создании нового заявления
ПРИЧИНА: Сигнал post_save срабатывал ДО установки ManyToMany связей (recipients, cc_users)
РЕШЕНИЕ:
- Добавлен сигнал m2m_changed для отслеживания установки recipients/cc_users
- При создании заявления оно помечается как ожидающее отправки уведомлений
- После установки recipients через .set() срабатывает m2m_changed и отправляет уведомления
- Используется глобальный set _pending_new_requests для отслеживания
УЛУЧШЕНИЯ:
- Добавлено подробное логирование процесса создания и отправки уведомлений
- Разные эмодзи-иконки для разных типов получателей (� адресовано, � в копии, ✅ на согласование)
- Все типы используют notification_type='request_new' (существующий в БД)
Файлы:
- notification_signals.py: добавлены сигналы m2m_changed
- serializers.py: добавлено логирование создания и установки recipients
Добавлено подробное логирование для диагностики проблемы с уведомлениями:
- Логируется срабатывание сигнала create_request_notifications
- Логируется статус заявления при создании
- Логируется каждый добавленный получатель
- Логируется итоговый список получателей
- Логируется роль каждого получателя при отправке уведомления
- Исправлена терминология: 'заявка' → 'заявление' во всех уведомлениях
- Добавлены эмодзи-иконки для визуального различия типов уведомлений
- Разделены типы уведомлений для основных получателей и cc_users:
* request_new_primary - � адресовано непосредственно
* request_new_cc - � в копии (информирование)
* request_new_approver - ✅ на согласование
* request_new_dept - � в отделе
- Добавлены детали в уведомления:
* Имя автора заявления
* Тип заявления
* Превью комментария (до 150 символов)
* Имя approver в уведомлениях о решении
- Улучшены заголовки с указанием типа заявления
- В metadata добавлены employee_name и approver_name
- Approver (тот кто принял решение) не получает уведомление о своем действии
- Исключены employee.id и approver_id из recipients при approve/reject
- Упрощен signal create_request_notifications (убран лишний запрос в БД)
- Теперь передается актуальный request_obj с установленным approver_id
- Заменено employee_departments на departments_links в notification_signals.py
- Добавлен импорт Department в serializers.py
- Создан комплексный тестовый скрипт test_recipients.py (7 тестов)
- Создан скрипт test_recipients_api.py для API тестирования
- Добавлены утилиты для создания тестовых данных
Результаты тестирования:
✓ 7/7 тестов модели прошли успешно (100%)
✓ Проверены все методы: add_recipient, is_recipient, all_recipients
✓ Проверена работа с ManyToMany полями
✓ Проверена сериализация через API
✓ Проверен флаг sent_to_all_department
- notify_new_request теперь отправляет уведомления всем recipients и cc_users
- При sent_to_all_department уведомления идут всем сотрудникам отделов
- notify_status_change уведомляет автора, получателей, CC и сотрудников отделов
- create_comment_notification уведомляет всех заинтересованных лиц
- Добавлены метаданные is_primary_recipient, is_cc, is_approver
- Сохранена обратная совместимость со старым полем department
- ApiClient теперь обрабатывает 401 и 403 ошибки для обновления токена
- Добавлен JWTRefreshMiddleware для проактивного обновления токенов за 5 минут до истечения
- Добавлена настройка JWT_REFRESH_THRESHOLD_MINUTES (по умолчанию 5)
- Исправлена проблема с периодическими 403 ошибками после истечения access token
