TU
src/tus/ · src/team/ · src/tu-refresh/ · src/workers/tu-refresh.worker.ts — анкети проєкту: хто які TU бачить, синхронізація з партнером, паролі й налаштування TU.
Дані: project_tus · Swagger: теги TUs і Team у /v2/docs · План: TUService, TU Sync Worker
Що робить модуль
- Тримає canonical TU всіх адмін панелей проєкту і щодня синхронізує їх з партнером.
- Визначає доступ ролі до TU: видимість і дозволені дії. Політика спільна для всіх модулів, що працюють з TU.
- Змінює паролі TU на партнері і налаштування TU, що передаються в Electron.
Призначення в змінах — 03-tu-assignments; історія призначень у часі — 04-tu-links.
Логіка
Доступ
Які TU бачить роль:
| Роль | Які TU |
|---|---|
| director | усі TU проєкту у своєму scope |
| top manager | TU, у зміні яких стоїть тімлід його структури |
| client manager | свої TU, а також TU без client manager на адмін панелях, які йому доступні |
| тімлід | TU, у зміні яких стоїть він |
| operator | TU, у зміні яких стоїть він |
| hr, recruiter, technical department | нічого |
Що роль отримує у видимих TU:
| Роль | Адмін панель | Client manager | Зміни | Може діяти |
|---|---|---|---|---|
| director | ✓ | з ID | усі | всюди |
| top manager | ✓ | з ID | усі | у вільній зміні або зміні свого тімліда |
| client manager | ✓ | з ID | усі | на своїх TU |
| тімлід | — | лише ім’я | тільки свої | у своїй зміні |
| operator | — | приховано | тільки свої | ніде |
Форма відповіді однакова для всіх ролей: у TU завжди три зміни, зміна поза доступом позначена як невидима. Project ID і User ID віддаються лише для призначень, якими роль може керувати; в інших — лише ім’я. TU зі зв’язком зі Stack доповнюється карткою: рівень, статус client email, кому відкритий email.
TU поза доступом повертає 404, а не 403: відповідь не розкриває факт існування TU.
Preview
Ім’я, аватар і партнерські ID TU з тією ж політикою доступу і фільтрами по тімліду та оператору. Golden читається з project_tus, інші проєкти — з legacy до міграції їхніх TU.
Структура команди
Окремий запит без TU: frontend групує TU за оператором зміни, тож серіалізація TU і правила доступу лишаються в одному місці.
| Роль | Що отримує |
|---|---|
| top manager | по групі на кожного тімліда своєї структури, у порядку структури; заблоковані та видалені тімліди пропускаються |
| тімлід | одну групу: себе і своїх активних операторів |
| operator | одну групу без тімліда і лише свій запис, без ID |
| інші ролі | порожній список |
Оператори тімліда сортуються за ім’ям. Online і sleep-режим операторів у відповідь не входять, див. tech-debt.
Налаштування TU (projectData)
Зміна полів projectData однієї TU. Поле приймається, лише якщо його підтримує проєкт TU і має право змінювати роль: невідоме поле — 400, недозволене ролі — 403. Зараз це лише findNew у Golden (chat-sender по онлайну), для director і top manager. Після запису зміна з операторами всіх змін TU надсилається в Electron Gateway. Поля, які пише синхронізація, через API не змінюються.
Паролі
Для кожної TU генерується пароль з 10 символів; сервіс проєкту змінює його на партнері через адмін панель TU, після підтвердження пароль зберігається зашифрованим. Видалена TU або TU без активної адмін панелі повертається в failed з причиною, обробка решти триває. Пароль у відповідь не повертається.
Refresh з партнера
Синхронізує canonical TU зі списками TU активних адмін панелей на партнері. Тригери: щоденний воркер, ручний запуск директора, project-golden при невідомій TU у вигрузці статистики.
- Беруться директори з активними адмін панелями; без жодного запуск пропускається.
- Для кожного scope сервіс проєкту повертає snapshot: усі TU всіх активних адмін панелей. Очікування до 20 хвилин.
- Snapshot порівнюється з canonical: створена, відновлена, переїхала до іншої адмін панелі, активована, деактивована, видалена, змінились профіль, партнерські ID або можливості. Одна TU може мати кілька подій одразу.
- У TU, що переїхали або видалені, знімаються тімлід і оператор у всіх змінах (03-tu-assignments). Помилка тут зупиняє refresh.
- Зміни записуються одним пакетом; нова TU отримує три порожні зміни. Події створення, активації, деактивації і видалення пишуться в
tu_logs(відновлена логується як створена) і одразу потрапляють у зв’язки TU. - Активні TU без пароля або без синхронізованої історії передаються в init у фоні; refresh повертає їх кількість, не чекаючи завершення.
Помилка одного scope не зупиняє інші, але запуск позначається невдалим.
Init нової TU
Виконується у фоні після refresh для активних TU без пароля або без синхронізованої історії, по одній TU, під локом на scope (1 година):
- Пароль на партнері — той самий шлях, що й ручна зміна паролів.
- Сервіс проєкту завантажує історію TU до появи в агенції за credentials самої TU; рядки пишуться в статистику як зовнішні (05-project-statistics). Після успіху TU позначається синхронізованою.
- Перераховуються favorites цих TU (03-project-favorites).
Помилка однієї TU логується і не зупиняє решту; TU повертається в init на наступному refresh. Udate (без паролів TU) init не проходить.
Розклад
| Проєкт | Коли | Повтори |
|---|---|---|
| Golden | щодня о 00:01 за Києвом | 3 спроби з паузою 30 хвилин |
Розклад задано в backend-common (легасі-назва воркера CheckProfiles для Stack Monitoring); автоматичні запуски увімкнені лише в production, кожен запуск виконує одна репліка.
API для frontend
| Роут | Що робить | Ролі |
|---|---|---|
POST /v2/tus/find | повний список TU у scope ролі | director, top manager, client manager, тімлід, operator |
POST /v2/tus/preview | легкий список TU з фільтрами | ті самі |
POST /v2/team/find | структура команди для групування TU | top manager, тімлід, operator |
POST /v2/tus/updateProjectData | налаштування однієї TU | залежно від поля |
POST /v2/tus/changePasswords | нові паролі вибраних TU | director, top manager, тімлід, client manager |
POST /v2/tus/refresh | refresh з партнера зараз | director |
Internal API
| Роут | Хто викликає | Навіщо |
|---|---|---|
POST /v2/internal/tus/refresh | project-golden | refresh при невідомій TU у вигрузці статистики |
POST /v2/internal/tus/detach | Stack | зняття TU з тімліда чи оператора при блокуванні, видаленні або переведенні — 03-tu-assignments |
Нюанси
- Один refresh на scope одночасно: лок на 5 хвилин, спільний для воркера, ручного запуску й internal-виклику.
- Дублікат TU на платформі або TU у двох адмін панелях зупиняють порівняння помилкою: результат у такому стані недостовірний.
- Scope директора обов’язковий для всіх змін; читання без нього дозволене ролям, у токені яких директора немає.
- Legacy після синхронізації докачував історію нових TU і створював favorites; тут це робить init у фоні, окрім Udate.
- Скидання пароля TU з mail-extension поки лишається в legacy, див. tech-debt.