AdminService
Спільний модуль family-application-api для керування FamilyAdmin.
UI: не описано.
Swagger: /v2/docs у family-application-api.
Задача
Тримає frontend API для отримання, додавання й оновлення адмінок. Login після створення не змінюється.
Під час додавання або зміни password спочатку викликає Family Admin API відповідної Family. Дані зберігаються тільки після успішної перевірки на партнері.
API
Фактично реалізовані операції:
| № | Операція | Endpoint | Доступ |
|---|---|---|---|
| 1 | Список адмінок за Family | GET /v2/admins?family={family} | director, HR |
| 2 | Логіни адмінок за списком canonical ID | POST /v2/admins/resolve | director, HR, top manager, supervisor, KM |
| 3 | Створення адмінки | POST /v2/admins | director |
| 4 | Зміна password, settings або status | PATCH /v2/admins/{adminId} | director |
Список повертає counts: { supervisors, operators, tu }. Поточна Golden-реалізація вже рахує supervisor/operator зі Stack users; підрахунок TU із family_tus ще потрібно підключити перед frontend cutover.
Flow
Створення
- AdminService передає введені credentials у Family Admin API відповідної Family для перевірки.
- Якщо партнер повернув помилку, AdminService повертає її frontend і нічого не зберігає.
- Якщо credentials валідні, AdminService шифрує password і створює активний
FamilyAdminзdirectorIdіз access token.
Зміна password
- Новий password разом із незмінним login перевіряється через Family Admin API.
- При помилці старий password залишається без змін.
- Після успішної перевірки AdminService шифрує і зберігає новий password.
Блокування
Блокування та розблокування змінюють тільки status між active і blocked.
Межа з legacy
Після Golden cutover лише family-application-api створює та змінює адмінки. stack-golden не пише у golden_admins: його ще не перенесені модулі читають family_admins через типізований compatibility repository і отримують legacy-проєкцію з розшифрованим password.