BREAKING CHANGE: notifications теперь опциональная зависимость.
Проблема:
- communications имел жесткую зависимость от notifications модуля
- from notifications.signals import notify - обязательный импорт
- Нарушало независимость модуля
Решение:
- Импорт notifications обернут в try/except ImportError
- Создана функция _send_notification() - обертка над notify.send()
- Если notifications не установлен - уведомления тихо игнорируются
- Модуль работает БЕЗ notifications (graceful degradation)
Изменения:
- notifications/handlers.py:
* Опциональный импорт: try/except ImportError
* Флаг NOTIFICATIONS_AVAILABLE для проверки доступности
* Функция _send_notification() вместо прямых вызовов
* 4 вызова notify.send() → _send_notification()
Результат:
✅ communications работает БЕЗ notifications модуля
✅ Если notifications установлен - все работает как раньше
✅ Полная независимость для standalone использования
✅ System check: 0 errors
Теперь можно использовать communications как:
1. С notifications - полная функциональность
2. Без notifications - только чаты без уведомлений
3. С собственной системой уведомлений - переопределить _send_notification()
BREAKING CHANGE: Тип чата 'department' полностью удален из модуля.
Для миграции существующих department чатов используйте:
- type='group' вместо type='department'
- context_object (GenericFK) для привязки к объектам
- flags={'is_department': True} для пометки
- COMMUNICATIONS_PARTICIPANT_RESOLVER callback для логики участников
Удалено из:
- models.py: тип 'department' из CHAT_TYPE_CHOICES
- models.py: упоминания Department из комментариев
- api/viewsets.py: логика фильтрации по department (30 строк)
- consumers.py: WebSocket логика для department (19 строк)
- utils.py: проверки доступа для department
- rules.py: is_department_chat → deprecated_is_department_chat (disabled)
- notifications/: обработка department в handlers и config
- signals.py: комментарии обновлены на универсальные
Добавлено:
- migrations/0037: удаление department из choices
- Обновлен help_text для context_content_type (без Department)
- Поддержка type='comments' в utils.py и consumers.py
Результат:
✅ 100% независимость от проекта EUSRR
✅ Нет импортов из employees
✅ Нет упоминаний department (кроме deprecated функции)
✅ Универсальный модуль готов для PyPI
Статистика: 9 файлов, -85/+44 строк
BREAKING CHANGE: Тип 'department' помечен как deprecated.
Изменения:
- Добавлен новый тип чата 'comments' для систем комментариев
- Тип 'department' перемещен в конец списка и помечен как [Legacy]
- Обновлен help_text: рекомендуется использовать 'group' + context_object
- Обновлен __str__() для обработки типа 'comments'
- Создана миграция 0036_add_comments_type_deprecate_department
Универсальность:
- 'comments' + context_object работает с любыми моделями
- Треды, реакции, вложения доступны из коробки
- Real-time обновления через WebSocket
- Автоматические уведомления при упоминаниях и ответах
Рекомендации:
- Для проектно-специфичных чатов используй type='group' + context_object
- Department: type='group' + context_object=department + flags={'is_department': True}
- Comments: type='comments' + context_object=any_model
Документация:
- Создан docs/guides/COMMENTS_USAGE.md с примерами
- Описаны все возможности системы комментариев
- Примеры API, WebSocket, миграции с legacy типов
- Убрано поле 'department' из списка полей в ChatListSerializer
- Убрано поле 'department' из списка полей в ChatDetailSerializer
- Исправлена ошибка ImproperlyConfigured при запросе списка чатов
- Поле было удалено из модели, но осталось в сериализаторах
- Заменено Employee на User во всех файлах модуля communications
- Использование нейтрального названия вместо проектно-специфичного
- Изменено 6 файлов: models.py, viewsets.py, serializers.py, handlers.py, signals.py, utils.py
- Улучшена переиспользуемость модуля communications
BREAKING CHANGE: Полная независимость communications модуля
Удалено:
- Поле Chat.department (FK на employees.Department)
- Импорты Department из всех файлов communications
- Q(department=...) фильтры в API/WebSocket/rules
Перемещено:
- Сигнал create_main_department_chat → employees/signals.py (проектоспецифичная логика)
Обновлено:
- models.py: удалено поле department, constraint, index
- api/viewsets.py: использует GenericFK через ContentType.objects.get()
- consumers.py: использует GenericFK через ContentType.objects.get()
- rules.py: is_department_chat теперь использует get_participants()
- admin.py: удален department из list_display/search_fields
Миграция:
- 0035_remove_department_field.py: удаляет поле, constraint, index
Результат:
✅ communications НЕ зависит от employees
✅ System check: 0 errors
✅ Использует только GenericFK (context_object)
✅ Полностью переиспользуемый модуль
Для EUSRR-специфичной логики department чатов:
- Настроить COMMUNICATIONS_PARTICIPANT_RESOLVER в settings.py
- Сигнал автосоздания чатов теперь в employees/signals.py
- signals.py: chat.get_participants → chat.get_participants()
- notifications/handlers.py: chat.get_participants → chat.get_participants()
Ошибка: AttributeError: 'function' object has no attribute 'exclude'
Причина: Метод не вызывался, пытались вызвать метод на самом объекте функции
Исправлено: Добавлены () для вызова метода и получения QuerySet
- Удалены классические Django CBV views (ChatListView, ChatDetailView, ~400 строк)
- Удален MessageForm для HTML форм
- Удалены 6 HTML templates (chat_list.html, chat_detail.html, messengers/*)
- Утилиты _coerce_ts и user_can_access_chat перенесены в utils.py
- Обновлены импорты в communications/api/viewsets.py
Причина: Проект использует Next.js frontend + REST API + WebSocket.
Классические server-side rendered views больше не используются.
Результат:
- System check: 0 errors
- Код стал чище и проще для поддержки
- Нет зависимости от Django templates
- API и WebSocket остались полностью функциональны
- Перенос REST API в communications/api/ для standalone использования
* Создан communications/api/ с serializers.py, viewsets.py, urls.py
* Перенесено 1668 строк (442 serializers + 1226 viewsets)
* Удалена директория api/v1/communications/
* Обновлены импорты в api/v1/urls.py и api/v2/communications/views.py
- Извлечение WebSocket логики в ChatConsumerMixin
* Создан communications/consumers.py (709 строк, 32 метода)
* Перенесены chat event handlers, action handlers, helper methods
* realtime/consumers.py сокращен с 862 до 211 строк (-75%)
* Сохранено одно WebSocket соединение через наследование миксина
- Архитектура:
* communications теперь полностью автономно (REST API + WebSocket)
* realtime/UserConsumer наследуется от ChatConsumerMixin
* 0 breaking changes, обратная совместимость 100%
* Одно WebSocket соединение для всех real-time событий
- Созданы тесты и документация:
* test_phase3.py - проверка API serializers, filters, WebSocket
* docs/completed/API_REFACTORING_STANDALONE.md
* docs/completed/WEBSOCKET_REFACTORING_MIXIN.md
* docs/completed/CHAT_REFACTORING_PHASE3_COMPLETE.md
Результат:
✅ System check: 0 ошибок
✅ Phase 3 tests: все прошли
✅ Готово к standalone использованию (pip install django-communications)
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
- Add detailed comparison of current vs refactored Chat model
- Add step-by-step migration plan with zero data loss guarantee
- Document GenericForeignKey approach for universal chat contexts
- Include rollback procedures and verification commands
Изменено: 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
- Синхронизация работает между всеми вкладками браузера
Модуль уведомлений остался переиспользуемым - категории управляются на фронте
Frontend изменения:
- Оптимизирована загрузка уведомлений: только 50 unread для badges
- Упрощены проверки is_read в AppShell и NotificationCenter
- Разделены useNotifications (для badges) и notifications page (для списка)
- Добавлены визуальные индикаторы в список чатов (badges, pin, notifications)
- Улучшена сортировка: закрепленные чаты показываются первыми
Связано с backend оптимизацией denormalized unread_count
- Добавлено поле 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 не удаляет пустые директории автоматически.
Объединяет изменения из feature/optimize-notifications-usage:
- requests_app: модульная структура notifications
- procurement: удален дублирующий WebSocket модуль
- feed: добавлены уведомления о лайках
- communications: оптимизация для упоминаний и ответов
- documents: поддержка bulk режима для массовых рассылок
- calendar_app: отслеживание изменений событий
Все приложения теперь используют единую архитектуру notifications.
Проблема:
- Монолитный 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.
