TUService
Спільний модуль family-application-api для роботи з FamilyTU.
Задача
- Тримати єдине frontend API для списків і partner-профілів TU.
- Фільтрувати TU за роллю та доступами користувача.
- Призначати й знімати KM, supervisor та operator для однієї або кількох TU.
- Тримати спільні правила призначень один раз для всіх Family.
- Викликати Family API для partner-операцій і окремі post-effects для ще не перенесених legacy-логік.
API
Поточний API family-application-api:
| № | Операція | Endpoint | Стан |
|---|---|---|---|
| 1 | Запустити refresh TU з partner API | POST /v2/tus/refresh?family={family} | ✅ |
| 2 | Змінити паролі TU | PATCH /v2/tus/password | ✅ |
| 3 | Призначити або зняти supervisor у зміні | PATCH /v2/tus/shifts/{shift}/supervisor | ✅ |
| 4 | Призначити або зняти operator у зміні | PATCH /v2/tus/shifts/{shift}/operator | ✅ |
| 5 | Список TU за Family і доступами користувача | GET /v2/tus?family={family} | ⬜ |
| 6 | Одна TU | GET /v2/tus/{tuId} | ⬜ |
Password request приймає tuIds[]. Assignment request приймає changes[] із tuId, current і candidate, щоб застарілий frontend не перезаписав нове призначення іншого користувача. Batch продовжує обробку після помилки окремої TU та повертає succeeded[]/failed[].
Публічного endpoint для KM немає. Сервісний метод синхронізує clientManagerFamilyId зі Stack TU Card. Системний detach під час refresh знімає лише supervisor/operator і не змінює KM.
POST /v2/tus/refresh отримує типізований Family response, нормалізує його через adapter у family-application-api, порівнює snapshot із family_tus і записує лише фактичні зміни. Зміна пароля викликає Family Admin API.
Stack TU Card
TU Card залишається сутністю Stack і не входить у FamilyTU.profile. FamilyTU.profile містить partner-профіль конкретної TU, а Stack Card — нашу внутрішню картку людини, яка може бути пов’язана з TU різних Family.
Сторінка TU Card отримує пов’язані TU через API TUService. Дані й логіка самої картки залишаються у Stack.
Додаткові операції TU
Поки не виносимо їх в окремі модулі:
| Операція | Де | Власник логіки |
|---|---|---|
Find New — дозвіл TU працювати із sender online | Golden | Family TU-операція |
MAX profiles per Auth Code і ліміт TU на operator | Chathouse | Family settings і перевірка призначення |
| Доступ operator/teamlead до Client E-mail TU | Golden | Stack API |
Доступ до TU
| Роль | Які TU бачить |
|---|---|
| Director | Усі доступні TU Family |
| KM | Призначені цьому KM та вільні TU в його адмінках |
| Top manager | TU supervisor/operator зі своєї структури |
| Supervisor | TU, де його supervisorFamilyId стоїть у будь-якій зміні |
| Operator | TU, де його operatorFamilyId стоїть у будь-якій зміні |
Вільна TU у списку KM ще не належить цьому KM. Перед призначенням supervisor KM спочатку має призначити TU собі.
Правила призначень
- Supervisor можна призначити лише у вільну або явно передану поточну зміну.
- TU має
3зміни у всіх Family. - Supervisor і TU повинні належати до однієї доступної адмінки.
- KM може змінювати supervisor лише коли
assignments.clientManagerFamilyIdдорівнює Family ID цього KM. - Top manager може призначати лише supervisor зі своєї структури.
- Operator призначається в конкретну зміну і повинен належати supervisor цієї зміни.
- При знятті supervisor
operatorFamilyIdу цій самій зміні також очищається. - Зміна перевіряє передані поточні значення і записується атомарно. Застарілий frontend state повертає conflict, а не перезаписує нове призначення.
- Після зміни пишеться assignment log. Canonical log collections і поля ще узгоджуються.
- Tasks, Electron
SET_LADY/DROP_LADYта інші post-effects повинні мати одного owner. До їх перенесення V2 делегує їх legacy Golden через versioned command; після перенесення command вимикається.
Порядок реалізації TU
- Family-сервіс отримує типізований partner response для активних адмінок і повертає його без canonical-конвертації.
- Family adapter у
family-application-apiнормалізує response у snapshot. TUSyncServiceпорівнює snapshot ізfamily_tus; repository записує лише створення та фактичні зміни status/admin/profile.- TUService віддає canonical список нашому frontend після реалізації read endpoint.
- Stack синхронізує KM під час зміни зв’язку TU Card.
- Director або KM призначає supervisor у конкретну зміну.
- Supervisor призначає operator у ту саму зміну.
- Frontend та Electron отримують лише TU, доступні поточному користувачу.