teamleads

Teamleads

(Меню Family → Teamleads) — family-залежний список supervisor та закріплених за ними операторів.

Суть

Teamleads — це family-залежний розділ керування тімлідами (supervisor) та закріпленими за ними операторами. Розділ показує ієрархію «тімлід → оператори», дозволяє шукати користувачів, фільтрувати їх за статусом і, залежно від ролі поточного користувача, створювати та редагувати тімлідів, керувати статусами, HR-призначеннями й паролями.

Розділ має окремі реалізації для CEO, HR manager і top manager, а також для кожної Family. Візуально й функціонально вони подібні, але права, API-джерела та доступні дії відрізняються.

Доступні Family

Назва в UI	Family у frontend/API	Розділ доступний
Udate	udate	Так
TalkyTimes	prime	Так
Golden	golden	Так
Chathouse	chathouse	Так

TalkyTimes є назвою Family в UI, але на API-рівні та в частині внутрішніх ідентифікаторів використовується значення prime.

Доступ за ролями

Можливість	CEO	HR manager	Top manager
Перегляд тімлідів та операторів	Так, у вибраній Family	Так, у межах HR-вибірки	Так, у межах top manager-вибірки
Створення тімліда	Так	Так	Ні
Відкриття картки тімліда	Так	Лише якщо тімлід закріплений за HR у звичайному списку	Так
Редагування основних даних тімліда	Так	Так для доступного тімліда	Ні
Зміна статусу тімліда	Так	Так для закріпленого тімліда	Так
Зміна статусу оператора	Так	Так	Так
Призначення або зняття HR	Так	Ні	Ні, значення лише відображається
Масовий reset password	Так	Ні	Так
Зміна Golden Workspace access оператора	Так, лише Golden	Ні	Ні

Маршрути

Списки

• CEO: /ceo/{family}/teamleads.
• HR manager: /hr/{family}/teamleads.
• Top manager: /top_manager/{family}/teamleads.

У маршруті списку {family} відповідає URL-сегменту Family: udate, talkytimes, golden або chathouse.

Картка тімліда

• Редагування для CEO: /ceo/teamlead_card/:id.
• Редагування для HR manager: /hr/teamlead_card/:id.
• Редагування для top manager: /top_manager/teamlead_card/:id.
• Створення для CEO: /ceo/teamlead_card/create/:family.
• Створення для HR manager: /hr/teamlead_card/create/:family.

У create-route параметр :family є обов’язковим контекстом створення. Картка ще не має ID тімліда, тому Family не можна визначити з профілю або з :id. Значення з URL передається в create-запит як currentFamily.

Для TalkyTimes create-route передає prime, а не talkytimes, оскільки саме prime є значенням API-контракту.

Поля, рольові обмеження, валідація та збереження картки не дублюються в цьому документі: див. Team Lead Card.

Use cases

Перегляд структури команди

1. Користувач відкриває Teamleads у потрібній Family.
2. Frontend завантажує список тімлідів разом із закріпленими операторами.
3. Основний рядок показує тімліда, кількість операторів і кількість закріплених TU.
4. Натискання на команду розгортає або згортає вкладену таблицю операторів.

Пошук користувача

1. Користувач вводить ім’я, nickname або email у поле пошуку.
2. Непорожній запит перемикає таблицю з ієрархічного режиму у плоский список результатів.
3. У результатах можуть одночасно бути тімліди й оператори; роль визначає доступні дії та маршрут картки.
4. Очищення пошуку повторно завантажує звичайну ієрархію тімлідів.

Створення тімліда

1. CEO або HR manager натискає Add Teamlead у розділі конкретної Family.
2. Frontend відкриває create-route з Family у URL.
3. Користувач заповнює загальні дані, login details, work hours, DeepL і Cooperation.
4. Для кожної увімкненої Family потрібно вибрати admin panel.
5. Create-запит не містить ID тімліда, але містить currentFamily та роль supervisor.

Редагування тімліда

1. Користувач відкриває картку за stackId тімліда.
2. Frontend завантажує профіль та списки admin panels усіх Family.
3. Дані профілю нормалізуються у стан картки, включно з поточними Family-доступами.
4. Доступні поля залежать від ролі поточного користувача.
5. Update-запит містить ID наявного тімліда й не потребує currentFamily.

Структура таблиці

Основний ієрархічний режим

Кожен верхньорівневий рядок представляє тімліда. Вкладені рядки представляють його операторів. Ширини колонок вкладеної таблиці обчислюються на основі основної таблиці та оновлюються після resize, зміни фільтрів або розгортання команди.

У рядку тімліда використовуються такі дані:

• ім’я та nickname;
• кількість операторів;
• кількість закріплених TU;
• login details;
• робочі години;
• статус Active або Blocked;
• HR manager, якщо ця колонка доступна ролі;
• перехід до картки.

Вкладені оператори відображаються зі своїми login details, статусом, HR і переходом до operator card. У поточній реалізації робочі години вкладеної команди беруться з тімліда та повторюються для операторів у цій команді.

Група FREE

У CEO та HR manager API-вибірках може бути службовий верхньорівневий рядок FREE. Він представляє користувачів, які не входять до звичайної команди тімліда. Для такого рядка відображаються лічильники та вкладені користувачі, але персональні дії самого рядка залишаються порожніми.

Плоский режим пошуку

Результати пошуку не групуються за тімлідом. Роль кожного результату визначається полем role:

• supervisor використовує дії й маршрут картки тімліда;
• operator використовує дії й маршрут картки оператора.

Для візуального розрізнення рядок оператора має інший фон. Локальні status/HR-фільтри до результатів пошуку не застосовуються: пошукову вибірку формує відповідний API.

Колонки та Family-відмінності

Family	Базові колонки	Додаткова поведінка
Udate	Teams, Login details, Work Hours, Status, Edit; для CEO/top manager також selection і HR	Стандартна Teamleads-поведінка
TalkyTimes	Такі самі, як Udate	У запитах Family має значення prime
Golden	Такі самі, як Udate	CEO може змінювати WS доступ операторів
Chathouse	Базові колонки плюс Auth code	Auth code доступний для операторів і може копіюватися

У Chathouse тімлід не має операторського auth code, тому відповідна клітинка верхньорівневого рядка порожня. Натискання на auth code оператора копіює його в clipboard; стан Copied показується тимчасово.

Пошук і фільтри

Пошук

Поле пошуку підказує три підтримувані типи значень: Name, Nickname та Email.

• CEO і top manager використовують загальний пошук користувачів у вибраній Family.
• HR manager використовує HR-пошук, який враховує доступну HR-вибірку.
• Після зміни статусу, HR або іншої дії frontend оновлює поточний пошук, якщо користувач перебуває в search-view.
• Якщо пошуковий рядок порожній, frontend повертається до звичайного списку.

Фільтр Status

Доступні два значення: Active і Blocked. Початкове значення — Active.

• Active виключає заблокованих тімлідів і прибирає заблокованих операторів із активних команд.
• Blocked включає заблокованого тімліда або активного тімліда, у якого є заблоковані оператори.
• У Blocked для вкладеного списку залишаються лише заблоковані оператори.
• Заблоковані тімліди сортуються перед активними тімлідами, які потрапили у вибірку лише через заблокованих операторів.

Фільтр HR manager

Фільтр доступний CEO і top manager. Список варіантів завантажується під час відкриття selector та містить:

• All HR-managers;
• усіх активних HR managers;
• No HR-manager.

Для конкретного HR у вибірку потрапляє тімлід, якщо цей HR призначений самому тімліду або хоча б одному його оператору. У вкладеній таблиці залишаються лише оператори відповідного HR. Якщо збіг є лише серед операторів, а сам тімлід закріплений за іншим HR, біля тімліда показується позначка (not assigned).

Фільтр No HR-manager залишає тімлідів без HR-призначення. HR-фільтр не перебудовує search-view локально.

Вибір користувачів і reset password

CEO і top manager мають checkbox-вибір користувачів.

• Checkbox тімліда вибирає лише його stackId.
• Checkbox оператора вибирає stackId оператора.
• Checkbox у заголовку в ієрархічному режимі вибирає всіх тімлідів та всіх вкладених операторів поточної вибірки.
• У search-view checkbox заголовка вибирає всі плоскі результати.
• Повторне натискання знімає відповідний вибір.

Reset Password генерує нові Stack-паролі для вибраних користувачів, оновлює поточний список або пошук і показує сумарний результат. Часткові помилки окремих користувачів також можуть бути включені у повідомлення.

У CEO кнопка недоступна без вибраних користувачів. У top manager кнопка в поточній реалізації не має такого disabled-стану й може відправити порожній список.

Дії CEO

CEO має найширші права в Teamleads:

• створює тімліда у поточній Family;
• відкриває й редагує Team Lead Card;
• відкриває operator card;
• блокує та розблоковує тімлідів і операторів;
• призначає, змінює або знімає HR окремо для тімліда й оператора;
• вибирає користувачів і генерує нові паролі;
• у Golden змінює Workspace access операторів;
• у картці наявного тімліда змінює server access між Production і Development.

Перед блокуванням показується confirmation modal. Розблокування виконується без додаткового підтвердження.

HR-призначення

Для тімліда список доступних HR завантажується з урахуванням поточного supervisor. Для оператора використовується список активних HR. Поточний HR виключається з варіантів; якщо HR уже призначений, selector додає Free, яке знімає призначення.

Призначення тімліда й оператора є незалежними операціями. Зміна HR тімліда автоматично не означає зміну HR усіх його операторів.

Golden Workspace access

У Golden для операторських рядків CEO бачить checkbox WS. Зміна checkbox оновлює workspace access конкретного оператора та після успіху перезавантажує поточну таблицю або пошук. Для тімлідів, інших Family та інших ролей цієї дії немає.

Дії HR manager

HR manager:

• створює нового тімліда у вибраній Family;
• працює зі списком, отриманим через HR-specific API;
• може змінювати статус, копіювати login details і відкривати картку закріпленого за ним тімліда;
• може змінювати статус, копіювати login details і відкривати картки операторів;
• не бачить HR-колонку та не керує HR-призначеннями;
• не має масового вибору й reset password у заголовку.

У звичайному ієрархічному списку тімлід без HR вважається недоступним для HR manager:

• login details не можна скопіювати;
• status selector заблокований;
• edit action не відкриває картку.

Це обмеження визначається на рівні рядка тімліда. Операторські рядки мають власні дії та не успадковують автоматично блокування верхньорівневого тімліда.

Дії top manager

Top manager:

• переглядає доступну йому ієрархію тімлідів та операторів;
• використовує status і HR-фільтри;
• бачить поточного HR у read-only selector-вигляді;
• блокує та розблоковує тімлідів і операторів;
• вибирає користувачів і виконує reset password;
• відкриває Team Lead Card та Operator Card;
• не створює тімлідів;
• не призначає HR;
• не редагує основні поля, work hours або Cooperation у Team Lead Card.

Team Lead Card

Список відкриває один shared feature у create або edit mode. Канонічний опис завантаження, секцій, Cooperation, admin-panel ID, валідації, payload, незбережених змін і personal mode міститься в Team Lead Card.

Копіювання login details у списку

Дія в рядку таблиці копіює email і пароль одним рядком у форматі email password. Після успіху текст дії тимчасово змінюється на Copied. Спочатку використовується Clipboard API, а для несумісного середовища передбачений textarea fallback.

Chathouse auth code має окремий стан копіювання й не замінює копіювання звичайних login details.

Loading, empty та error states

• Початкове завантаження списку використовує global loader.
• Таблиця рендериться після завершення першого запиту, незалежно від його результату.
• Мутації статусу, HR, password і Golden Workspace access також використовують global loader та global notification.
• Якщо API повертає success: false, frontend показує backend message; якщо повідомлення відсутнє, використовується локальний fallback.
• Для порожньої успішної вибірки немає окремого текстового empty state: таблиця залишається без рядків.
• Помилка оновлення не повинна локально підміняти дані; після успішної мутації список або активний search-view завантажується повторно.

Відомі нюанси поточної реалізації

Цей розділ описує фактичну поведінку, яку важливо враховувати під час змін і тестування.

1. У HR manager звичайний рядок тімліда без HR блокує login details, status та edit. У search-view ці обмеження застосовані не повністю: edit-link і копіювання login details можуть залишатися доступними. Це розбіжність двох представлень, а не окреме бізнес-правило.
2. Status і HR-фільтри працюють над ієрархічним списком, але не фільтрують плоскі результати пошуку локально.
3. Top manager Reset Password не має disabled-стану для порожнього selection, на відміну від CEO.
4. Робочі години у вкладених операторських рядках беруться з тімліда команди.
5. У Chathouse auth code є лише в операторських даних; supervisor-клітинка порожня.
6. Family у URL списку TalkyTimes і Family у create/API-контракті мають різні назви: talkytimes проти prime.

API-взаємодії

Frontend використовує окремі role-specific операції для отримання списків:

• CEO — supervisors with operators by Family;
• HR manager — HR supervisors with operators by Family;
• top manager — top manager supervisors with operators by Family;
• CEO/top manager search — загальний users search;
• HR manager search — HR search.

List-level дії статусу, reset password, HR assignment і Golden Workspace access виконуються окремими API-операціями.

Повні request/response контракти потрібно звіряти у Swagger відповідного сервісу, а не дублювати в цьому UI-документі.

Зв’язки

• operators
• Team Lead Card — єдине джерело логіки shared-картки supervisor.
• Operator Card — картка оператора, яка відкривається зі структури команди.
• swagger
• Shared Team Lead Card: src/features/teamlead_card/
• CEO Teamleads: src/components/director/{family}/body/teamleads_group/
• HR manager Teamleads: src/components/hr_manager/{family}/teamleads_group/
• Top manager Teamleads: src/components/top_manager/{family}/teamleads_group/
• TODO: додати перевірені Swagger operation deeplink-и для role-scoped списків, пошуку, status/password/HR mutations і Golden Workspace access.