Workspace

Меню Family → Workspace

Суть

Робоча область — основний інтерфейс листування між TU та RU. (TODO: уточнити, чи це той самий концепт що workspace у stack-electron, чи спрощена web-версія.)

Use cases

Оператор працює з діалогами TU/RU, історією Chat і Mail, медіа та нотатками. У Chathouse коротка втрата мережі зберігає відкритий діалог і чернетки, щоб оператор міг продовжити роботу після відновлення з’єднання.

Доступно у

golden ✓ · prime/talkytimes ✓ · udate ✓ · chathouse ✓

Варіації по Family

Доступ і обсяг варіюються сильніше ніж зазвичай — окремий патерн на кожній Family:

Family	Хто бачить
udate	topManager, supervisor, operator
talkytimes	supervisor, operator
goldenbride	тільки supervisor
chathouse	supervisor, operator

Чому розкид: API партнерських сайтів різні. На GoldenBride Workspace історично частина electron-клієнта — web-версія вийшла ширшою за можливостями, тому й коло доступу вужче (тільки supervisor).

VIP-завдання Prime

Оператор може відкрити VIP-завдання зі списку активних завдань. Ручне видалення VIP-завдань недоступне; список оновлюється даними сервера.

Очікування відповіді сервера

Запити через спільну сокет-обгортку очікують підтвердження до 15 секунд за замовчуванням. Якщо відповіді немає, очікування завершується з ознакою невдачі; пізня відповідь не оновлює UI. Автоматичного повтору немає. Запит, який до завершення таймауту залишався в офлайн-черзі, видаляється з неї. Для вже відправленої операції відсутність відповіді не доводить, що операція не виконалася на сервері.

Відновлення Chathouse Operator

• Вікно очікування з’єднання з’являється після 2 секунд без з’єднання, щоб короткий reconnect не спричиняв блимання. Якщо з’єднання відновлюється раніше, вікно не показується; якщо воно вже відкрите — закривається одразу після connect, не очікуючи завершення фонового оновлення даних. Поки з’єднання немає, мережеві дії недоступні.
• Після тимчасового disconnect залишаються поточна пара TU/RU, вкладка Chat/Mail, обидві чернетки, мова, вкладення й робочі фільтри. Тимчасові вікна закриваються без підтвердження, збереження чи відправлення; незбережена нотатка доступна при повторному відкритті.
• У Chat вибір медіа діє лише у відкритій галереї. Закриття галереї, початок відправлення або її закриття при disconnect скидають позначки; повторне відкриття починається без вибраних файлів. Вибір вкладень Mail не переноситься до Chat.
• У Mail галерея відновлює вибір лише з вкладень поточного листа. Attach підтверджує зміни; закриття хрестиком скасовує непідтверджений вибір і залишає попередні вкладення. Щоб прибрати всі вкладення, потрібно зняти всі позначки та натиснути Attach (0). Підтверджені вкладення залишаються в чернетці при disconnect; успішне відправлення листа прибирає відправлені вкладення.
• При переході до іншого діалогу TU/RU тексти Chat і Mail та вкладення попереднього діалогу очищаються й не відновлюються після повернення. Перемикання Chat ↔ Mail у межах поточного діалогу зберігає окремі чернетки обох вкладок і підтверджені вкладення Mail.
• Reconnect автоматично оновлює першу сторінку історії активної вкладки, дозволи та ліміти. Для Mail додатково читається Chat, звідки надходять дозволи. Send заблокована до завершення перевірки цих актуальних даних. Стан медіа оновлюється незалежно: його timeout не відкидає успішну історію й не блокує готовий діалог. Це також стосується звичайного вибору діалогу та перемикання Chat/Mail.
• Стара історія замінюється першою свіжою сторінкою. Повідомлення, які надійшли під час запиту, узгоджуються за серверними ID. Курсори замінюються новими, показуються останні повідомлення; подальша пагінація старої історії працює звичайно. Після Chat recovery Mail завантажується заново при наступному відкритті.
• ACK і звичайні HTTP-операції очікують до 15 секунд; окремий upload — до 60 секунд. Cancellation припиняє наступні файли batch upload. Уже відправлений файл може завершитися на сервері; автоматичного повтору немає.
• Помилка звичайного відкриття діалогу або перемикання Chat/Mail завершує завантаження й показує штатне повідомлення; діалог можна вибрати повторно. Send недоступна без завантаженої історії активної вкладки та потрібних permissions.
• При помилці основних recovery history/permissions reads діалог і чернетки залишаються, Send заблокована. Інтерактивного recovery banner і Retry немає. Наступний reconnect запускає нову синхронізацію. Помилка окремого media status read не переводить готовий діалог у recovery_error.
• Втрачений ACK після відправлення означає unknown: доставка не підтверджена і не спростована. Чернетка зберігається, автоматичної повторної відправки немає; штатне повідомлення пропонує перевірити актуальну історію. До завершення цієї робочої сесії повторна відправка для відповідної пари заблокована. Додаткових кнопок немає. Close WS і повторний вхід починають нову сесію та очищають її чернетки; результат попередньої доставки це не доводить.
• Підтверджений сервером success відправлення не потребує ID повідомлення у відповіді. Якщо запис повідомлення відсутній, історія синхронізується без повторної відправки; підтверджений Mail success зменшує ліміт один раз.
• Close WS і серверне завершення сесії повністю очищають робочий контекст та інвалідують незавершені операції.

Межі підтвердження

Без серверного ідентифікатора операції результат втраченої mutation не можна достовірно визначити за текстом повідомлення. Якщо сервер не надає стабільний ID повідомлення, узгодження історії з realtime не гарантує відсутності дублювання. Фактичну повноту permissions у відповіді Chathouse потрібно перевірити перед релізом на тестовому backend.

Зв’язки

• Бек: (TODO)
• favorites · icebreakers · sender