BREAKING CHANGES (backward compatible):
- All code updated to support both old and new fields
- context_object (GenericFK) and flags now primary
- department and is_main still work (DEPRECATED)
FILES UPDATED:
1. signals.py:
- create_main_department_chat() uses context_object + flags
- Creates both old and new fields for compatibility
- Checks existence using Q() for both fields
2. views.py (4 critical updates):
- has_user_access_to_chat(): uses get_participants() (supports both)
- ChatListView.get_queryset(): checks department OR context_object
- ChatDetailView.get_queryset(): checks department OR context_object
- mark_as_read_ajax(): uses get_participants() and include_all_users
3. rules.py:
- is_department_chat(): checks both department and context_object
- Supports GenericFK for Department context
4. apps.py:
- create_main_global_chat(): checks and sets flags['is_primary']
- Backward compatible with is_main
5. admin.py:
- get_readonly_fields(): checks flags['is_primary'] OR is_main
- Prevents editing primary chats
6. notifications/config.py:
- get_chat_display_name(): uses context_object OR department
7. models.py:
- Chat.__str__(): uses context_object OR department
TESTED:
✅ Signal creates chat with context_object + flags
✅ get_participants() works with both fields
✅ __str__ displays correctly
✅ is_department_chat rule works
✅ Backward compatibility preserved
Изменено: notifications.tasks.* → notifications.*
Проблема: задачи регистрируются как 'notifications.send_*',
а не 'notifications.tasks.send_*', поэтому старый паттерн
не совпадал и задачи шли в дефолтную очередь 'celery'.
Теперь задачи корректно роутятся в очередь 'notifications',
которую worker слушает с флагом -Q celery,notifications
- Исправлена логика подсчёта уведомлений по категориям (n.verb вместо n.category)
- Добавлена синхронизация между компонентами через CustomEvent API
- Реализована автоматическая отметка категории уведомлений при переходе в раздел
- Backend: универсальный endpoint /category/read/ принимающий список verbs
- Frontend: функция getVerbsByCategory() для маппинга категорий
- Счётчики обновляются в реальном времени через WebSocket
- Синхронизация работает между всеми вкладками браузера
Модуль уведомлений остался переиспользуемым - категории управляются на фронте
- Добавлено поле unread_count в ChatReadState для кеширования счетчика
- Создана миграция 0030 с автоматическим пересчетом существующих данных
- Обновлен _auto_mark_read() для обнуления счетчика при прочтении
- Добавлен signal increment_unread_count_on_new_message для автоинкремента
- Упрощен get_queryset() - убраны подзапросы, используется Prefetch
- Обновлены сериализаторы для использования denormalized поля
Производительность: 4 SQL запроса вместо 100+ подзапросов
Решает проблему N+1 при загрузке списка чатов
Архитектура описана в backend/docs/architecture/UNREAD_COUNT_OPTIMIZATION.md
- Удалены logger для 'bots' и 'aiogram' (telegram bot библиотека)
- Почищены пустые папки bots/ и hikcentral/ оставшиеся после merge
- Все остальные упоминания уже удалены в feature ветке
Merge прошел корректно, просто git не удаляет пустые директории автоматически.
Проблема:
- Монолитный notification_signals.py (~220 строк) смешивал разные concerns
- Логика отслеживания изменений полей переплетена с signal receivers
- Вспомогательные функции без четкой структуры
Решение:
Разделен на модульную структуру calendar_app/notifications/:
- config.py - NotificationVerbs, MessageTemplates, ActionURLs, константы полей,
вспомогательные функции (format_date, format_changes, FIELD_NAMES, IMPORTANT_FIELDS)
- handlers.py - get_event_recipients(), notify_event_created(), notify_event_changed(),
notify_event_cancelled()
- signals.py - Django signal receivers (@receiver) для CalendarEvent
- __init__.py - публичный API модуля
Изменения:
- Создан: calendar_app/notifications/ модуль с 4 файлами
- Переименован: notification_signals.py → notification_signals.py.old
- Изменен: apps.py - обновлен импорт на calendar_app.notifications
Логика уведомлений:
1. Новое событие → получатели по типу (компания/отдел/личное)
2. Изменение события → участники события (если изменены важные поля)
3. Отмена события → все участники
Преимущества:
- ✅ Единообразие со всеми остальными приложениями
- ✅ Четкое разделение ответственности (SRP)
- ✅ Отслеживание изменений полей вынесено в отдельный signal
- ✅ Централизованные константы для важных полей
- ✅ Легче тестировать компоненты
- ✅ Публичный API для переиспользования
Верификация:
- python manage.py check - успешно
- constants.py → config.py для более точного отражения содержимого
- Файл содержит не только константы, но и конфигурацию уведомлений:
* NotificationVerbs - типы уведомлений
* MessageTemplates - шаблоны сообщений
* ActionURLs - URL для переходов
- Обновлены импорты во всех зависимых файлах:
* handlers.py
* __init__.py
Название 'config' более семантически верное для файла с конфигурацией.
- Создана папка backend/requests_app/notifications/ вместо одного файла
- Разделена логика на модули:
* constants.py - типы уведомлений (verbs) и шаблоны сообщений
* handlers.py - бизнес-логика отправки уведомлений
* signals.py - Django сигналы для автоматической генерации
* __init__.py - публичный API модуля
Преимущества новой структуры:
- ✅ Лучшая организация кода (SRP - Single Responsibility Principle)
- ✅ Легче поддерживать и расширять
- ✅ Константы в одном месте (NotificationVerbs, MessageTemplates)
- ✅ Переиспользуемые шаблоны сообщений
- ✅ Обратная совместимость через __init__.py
Удален: notification_signals.py (сохранен как .old для истории)
Добавлен: notifications/ модуль с 4 файлами
- Исправлена миграция 0010: добавлено удаление старых моделей из Django state
- Добавлен default='notification' для поля verb в модели Notification
- Создана чистая миграция 0011_initial с новыми моделями:
* Notification (с GenericForeignKey)
* UserChannelPreferences
- Удалены автоматически сгенерированные некорректные миграции
Fixes: KeyError при попытке удалить unique_together с несуществующими полями
- Remove hard-coded Russian translations from backend API
- Backend now returns raw verb values (language-agnostic)
- Implement frontend translation functions for notification titles and categories
- Add category badge system with filters on notifications page
- Create translation utilities in frontend (verbTranslations.ts)
- Add notification settings page structure
- Update API endpoints to return simplified notification data
- Refactor notification signals across all apps
- Remove deprecated code and tests
- Add comprehensive documentation for v2 migration
Backend changes:
- notifications/api/views.py: Remove translation logic, simplify responses
- All notification_signals.py: Update to use consistent patterns
- Remove deprecated Telegram bot command
- Update Celery tasks for new notification structure
Frontend changes:
- app/notifications/page.tsx: Add translation functions and category badges
- hooks/useNotificationWebSocket.ts: New WebSocket hook for real-time updates
- lib/verbTranslations.ts: Centralized translation mappings
- components/NotificationCenter.tsx: Update to use new API format
This makes the notifications module fully reusable and project-independent.
- Создан requirements.txt с основными зависимостями (Django, DRF, Celery, Channels)
- Обновлена секция установки с подробными инструкциями
- Добавлена структура модуля и описание компонентов
- Обновлены TODO (убраны выполненные задачи)
- Добавлена информация о production-safe миграциях
- Добавлены секции: настройка конфигурации, запуск Celery worker
- Модуль полностью самостоятельный и готов к переносу в другие проекты
Исправлено:
- channels.py: удалены осиротевшие строки после рефакторинга
- api/v1/notifications/urls.py: исправлен file для реэкспорта
- notifications/urls.py: создан для обратной совместимости
Миграции:
- 0010_userchannelpreferences_and_more.py: переход на v2 модели
* Notification с GenericForeignKey (actor/action_object/target)
* UserChannelPreferences вместо UserNotificationSettings
* Удалены старые модели (NotificationCategory, NotificationType и тд.)
* Переименована таблица в notifications_notification_v2
КРИТИЧНЫЕ УЛУЧШЕНИЯ:
✅ Убран хардкод 'EUSRR' → универсальное 'My Site'
✅ Созданы email шаблоны внутри модуля (4 файла)
✅ Централизованная конфигурация в config.py
✅ API перемещен в notifications/api/
Новые файлы:
- config.py - централизованные настройки с fallback значениями
- templates/notifications/email/*.html/*.txt - HTML и текстовые шаблоны
- api/__init__.py, api/views.py, api/urls.py - REST API внутри модуля
Изменения в существующих файлах:
- senders/email.py: использует config.site_name() и config.from_email()
- tasks/email.py: rate_limit, max_retries, retry_delay из config
- tasks/push.py: rate_limit, max_retries, retry_delay из config
- tasks/websocket.py: max_retries, retry_delay из config
- api/v1/notifications/urls.py: реэкспорт из notifications.api (обратная совместимость)
Структура шаблонов:
📁 notifications/templates/notifications/email/
├── notification.html - красивый HTML для обычных уведомлений
├── notification.txt - текстовая версия
├── digest.html - HTML дайджест (daily/weekly)
└── digest.txt - текстовая версия дайджеста
Конфигурация (config.py):
- DEFAULT_CONFIG с fallback значениями для всех параметров
- get_config() - объединяет с settings.NOTIFICATIONS_CONFIG
- Удобные функции: email_rate_limit(), push_max_retries(), site_name()
- Полностью настраиваемо через settings проекта
API внутри модуля:
- notifications/api/views.py - все endpoint'ы
- notifications/api/urls.py - URL patterns
- Относительные импорты (from ..models)
- Обратная совместимость через api/v1/notifications/urls.py
УНИВЕРСАЛЬНОСТЬ:
✅ Нет хардкода проекта
✅ Все шаблоны внутри модуля
✅ API внутри модуля
✅ Конфигурация через settings
✅ Можно скопировать в любой проект Django 5.2+
Критичные задачи:
- Создать email шаблоны (notification.html/txt, digest.html/txt)
- Написать unit и integration тесты (coverage >80%)
- Убрать хардкод 'EUSRR' из email sender
Важные улучшения:
- Вынести настройки rate_limit, max_retries в settings
- Переместить API endpoints в notifications/api/
- Централизовать конфигурацию в notifications/settings.py
Желательные доработки:
- setup.py для публикации в PyPI
- Sphinx документация
- CI/CD pipeline
- Pre-commit hooks
Затронуты файлы:
- models.py - TODO для тестов моделей
- signals.py - TODO для тестов сигналов
- channels.py - TODO для integration тестов
- senders/email.py - TODO для шаблонов и хардкода
- tasks/email.py - TODO для конфигурации
- tasks/push.py - TODO для конфигурации
- README.md - секция TODO с чеклистом
- Файл task_base.py (500 строк) использовал удаленный NotificationService API
- Нигде не импортировался и не использовался
- Создавал путаницу с новым tasks/base.py
- Экономия: -500 строк кода
BREAKING CHANGES:
- API полностью переписан под новую модель (verb вместо category/type)
- NotificationService заменен на stub с NotImplementedError
- Удалена обратная совместимость
API endpoints (обновлены):
- GET /api/v1/notifications/ - новый формат ответа
- GET /api/v1/notifications/verb-types/ - вместо categories
- GET/PUT /api/v1/notifications/preferences/ - вместо settings
- POST /api/v1/notifications/<id>/unread/ - новый endpoint
- DELETE /api/v1/notifications/delete-all-read/ - новый endpoint
Удалены endpoints:
- /api/v1/notifications/categories/ (нет категорий в v2)
- /api/v1/notifications/settings/* (заменено на preferences)
- /api/v1/notifications/telegram/* (Telegram отключен)
- /api/v1/notifications/push/vapid-key/ (не нужен)
- /api/v1/notifications/push/subscriptions/ (не нужен)
services.py:
- Заменен на stub с NotImplementedError
- Все методы выбрасывают исключения с подсказками миграции
- Документация как мигрировать со старого API
Новая структура ответа API:
- verb вместо category/type
- actor (GenericForeignKey) вместо sender
- description вместо message/title
- timesince() вместо created_at
- unread вместо is_read
Старые файлы:
- Удалены все *.old файлы
BREAKING CHANGES:
- Удалена старая система (6 моделей → 2 модели)
- models_new.py → models.py (Notification, UserChannelPreferences)
- signals_new.py → signals.py (notify.send API)
- admin_new.py → admin.py
Новая архитектура:
- Все отправки через Celery (полностью асинхронно)
- Модульная структура tasks/ (base, email, push, websocket)
- Каждый канал - отдельный класс задачи наследующий BaseNotificationTask
- Rate limiting, retry, приоритеты из коробки
Обратная совместимость:
- Создан services.py facade для старого API
- NotificationService.create_notification() работает через notify.send()
- Старый код продолжает работать без изменений
Удалено:
- Старые models.py, signals.py, admin.py, tasks.py (→ .old)
- telegram_bot.py, telegram_models.py (Telegram отключен)
- test_views.py, views.py, urls.py (устаревшие)
Создано:
- tasks/ модуль с классовой архитектурой (как senders/)
- tasks/base.py - BaseNotificationTask
- tasks/email.py - EmailNotificationTask + DigestEmailTask
- tasks/push.py - PushNotificationTask
- tasks/websocket.py - WebSocketNotificationTask
Обновлено:
- apps.py - загружает signals, channels, tasks
- channels.py - все отправки через Celery задачи
- Все импорты models_new → models
Очистка от дублирующегося кода:
Удалены старые файлы:
❌ email_sender.py → заменен на senders/email.py
❌ telegram_sender.py → функционал Telegram удален
❌ signals_telegram.py → Telegram сигналы удалены
Обновлены:
✅ apps.py - убран импорт signals_telegram
✅ services.py - обновлены импорты, Telegram помечен deprecated
NotificationService (старый) продолжает работать для обратной
совместимости, но использует новые senders где возможно.
Telegram функционал отключен в старой системе с пометкой
'use new notification system'.
Результат:
- Меньше дублирования кода
- Чище структура проекта
- Все отправители теперь наследуются от BaseNotificationSender
- Готовы к полной миграции на новую архитектуру
Создана объектно-ориентированная архитектура для отправителей:
Новая структура:
- BaseNotificationSender - абстрактный базовый класс
- EmailNotificationSender(BaseNotificationSender)
- WebSocketNotificationSender(BaseNotificationSender)
- PushNotificationSender(BaseNotificationSender)
Преимущества:
✅ Единый интерфейс send() для всех каналов
✅ can_send() - проверка возможности отправки
✅ Унифицированное логирование (log_success, log_error, log_skip)
✅ Легко расширять новыми каналами
✅ Переиспользуемость кода
Изменения:
- notifications/senders/base.py - базовый класс
- notifications/senders/email.py - email отправитель (упрощен)
- notifications/senders/websocket.py - WebSocket отправитель
- notifications/senders/push.py - Web Push отправитель
- notifications/channels.py - обновлен для использования классов
Старые функции send_* сохранены для обратной совместимости (deprecated)
- Убрана поддержка Telegram из каналов доставки
- Удалено telegram_enabled из UserChannelPreferences
- Обновлена документация
- Сфокусировались на WebSocket, Email и Web Push
Фокус: веб-уведомления, email дайджесты и web push
- Упрощена архитектура: 2 модели вместо 6
- GenericForeignKey для универсальности
- Стандартный API notify.send() как в django-notifications-hq
- Совместимость с Django 5.2+
- Сохранен multi-channel функционал (WebSocket, Email, Telegram, Push)
- Создана полная документация
Файлы:
- models_new.py - Notification + UserChannelPreferences
- signals_new.py - notify.send() API
- channels.py - роутинг по каналам доставки
- admin_new.py - Django Admin интерфейс
- README.md - краткое описание для переиспользования
- docs/guides/NOTIFICATIONS_V2_USAGE.md - полное руководство
- docs/reports/NOTIFICATIONS_REFACTORING_REPORT.md - отчет о рефакторинге
Требуется тестирование перед внедрением.
- Фронтенд: добавлена обработка поля 'notifications' (бэкенд возвращает { notifications: [...] })
- Фронтенд: исправлены URL endpoints для отметки прочитанным (/read/ вместо /mark_read/)
- Бэкенд: добавлено поле 'short_message' в ответ API для корректного отображения превью
- Убран фильтр по календарю при поиске существующих событий
- События автоматически переносятся из personal-XX в общий календарь birthdays
- Удаляются дубликаты событий ДР для одного сотрудника
