06-favorites

06-favorites

Favorites

src/favorites/ — пари TU + RU з платними діями: агрегати зі статистики, ручні поля, календар New/Unique і глобальні favorites RU.

Дані: project_favorites, project_global_favorites · Swagger: тег Favorites · План: FavoriteService, GlobalFavoriteService

Що робить модуль

• Перераховує favorites проєкту з project_statistics після кожної денної вигрузки і перебудовує глобальні favorites зачеплених RU.
• Створює порожні favorites нових пар з оперативної вигрузки; агрегати оновлює лише денна вигрузка.
• Віддає favorites і календар TU з накладеною оперативною вигрузкою; накат у БД не пишеться.
• Зберігає ручні поля пари: тип, контакти, білий список, блок з боку TU.

Тимчасові дані ніколи не змінюють стабільні записи: project_statistics_temp використовується лише для створення нових пар і на читанні.

Логіка

Перерахунок

Тригер — project-golden після денної вигрузки і relations (Потік даних).

1. Усі TU проєкту чанками по 25; для чанка агрегуються пари TU + RU з рядків статистики за правилами favorites проєкту, через індекс project + tuId + ruId + at.
2. Кожна пара — з усієї історії: profit — сума без подарунків, gifts — кількість подарунків, firstPaidAt / lastPaidAt — перша й остання платна дія.
3. Upsert у project_favorites: автоматичні поля перезаписуються, ручні не змінюються, нова пара отримує тип new.
4. Глобальні favorites зачеплених RU перебудовуються чанками по 2000 RU групуванням favorites; senderIgnore зберігається, записи не видаляються.

Кожен запуск проходить весь проєкт: збій, перекачаний день або зміна правил виправляються наступним перерахунком. Вартість визначає історія найбільшої TU, а не розмір колекції.

Пари з оперативної вигрузки

Тригер — project-golden після оперативної вигрузки. Платформа читає project_statistics_temp, створює відсутні пари з profit і gifts 0 та датами першої й останньої дії зі знімка, наявні пари не змінює і перебудовує глобальні favorites нових RU.

Читання TU

Стабільні favorites TU плюс рядки project_statistics_temp цієї TU за правилами favorites: profit і gifts додаються, lastPaidAt зсувається вперед, пара лише зі знімка повертається віртуальною з id: null. Профіль і online RU — з профілів RU, ознака freeloader — з глобального favorite. Доступ визначає політика TU (Доступ): TU поза доступом повертає 404.

Календар

• unique — різні RU з рядками favorites за день, зі статистики і зі знімка.
• new — RU, у яких перша платна дія з цією TU припала на день: firstPaidAt у добі проєкту, для віртуальних пар — перший день у знімку.

Окремої колекції календаря немає: місяць TU читається з індексу project + tuId + day.

API для frontend

Роут	Що робить	Ролі
POST /v2/favorites/findByTU	favorites TU з накатом оперативної вигрузки	director, top manager, client manager, тімлід, operator
POST /v2/favorites/calendar	New і Unique RU по днях місяця	ті самі
POST /v2/favorites/update	тип, контакти, білий список, блок з боку TU	ті самі

Internal API

Роут	Хто викликає	Навіщо
POST /v2/internal/favorites/recalculate	project-golden після денної вигрузки; вручну для ремонту	повний перерахунок проєкту
POST /v2/internal/favorites/create-from-temp	project-golden після оперативної вигрузки	порожні favorites нових пар

Нюанси

• profit у форматі проєкту: сума витрат у Golden і Chathouse, кількість платних повідомлень у Prime і Udate.
• Активний favorite — остання платна дія не старша за 7 днів (ACTIVE_FAVORITE_DAYS у contracts); не зберігається, рахується на читанні.
• blockedByRU модуль не змінює: очікує синхронізації блок-листа проєкту.

Борг

• Electron читає favorites через stack-golden з legacy golden_favorites і працює з їхніми ID; адаптер stack-golden на project_favorites з накатом оперативної вигрузки ще не зроблений.
• Коли повний перерахунок перевищить хвилини, його треба винести у воркер платформи, а роут — лише ставити задачу.