Линии многострадальные...

1) Не работает нормально связка сессий клиентом для telegram, если у клиента не задан никнейм в телеге (@чтототам).
То есть при приходе нового сообщения создаётся сессия, там отображается связанный контакт и даже показывает историю общения

но вот если зайти в контакт, то там в истории общения пусто.

Надо как то исправлять...


2) Если сессия от клиента была закрыта без ответа оператора в неё, то глядя в историю общения которая подтягивается в сессиях или в архиве невозможно понять кем же она была закрыта

Вообще было бы логично, если бы при таких действиях как "Взятие в работу", "Переназначение оператора", Закрытие сессии", "Открытие новой сессии оператором/супервизором" и даже ассоциация с контактом, в сессию записывалось системное сообщение в стиле "Оператор/супервизор такой-то сделал то-то в такой то datetime"

3) После переназначении оператора сессии совершенно невозможно определить, каким же пользователем было совершено это действие.

Ну собственно то же самое, что в предыдущем пункте.


4) При написании в whatsapp, связываем с клиентом, связка проходит по номеру телефона без плюса, например "79998887766".
Но новую сессию со стороны bpm можно открыть только по номеру с плюсом... Нелогично, надо бы доработать в потрохах bpm дабы оно где надо добавляло или удаляло +.

5) При написании ответа в канал inbox успешно убивается всё форматирование, включая переносы строк.
Там правда работает html разметка, но учить операторов html разметке, да ещё в зависимости от используемого канала... В общем не хочу нецензурно выражаться, поэтому промолчу.

6) Некорректная работа линий при перезапуске сервера, докера и тд.
При перезапуске докера bpm считает, что каналы whatsapp и telegram вполне себе живые, хотя по факту они отвалились. Минимум сутки ждал пока bpm осознает, что каналы давно оффлайн - не осознала... Тоже нехорошо, хоть и не особо критично.

7) Невозможно прицепить несколько файлов для отправки.
Если для whatsapp и telegram это в общем некритично, то вот для почты - ну прям дико неудобно. Надо отправить клиенту 5 файлов - ему приходит 5 разных писем. Надо как-то исправлять.

8) При попытке отправить большой аттач через канал inbox, который не пролазит через используемый почтовый сервис, или в whatsapp, ничего не происходит.
Надо бы выдавать какой то алерт в стиле "Файл не может быть отправлен, превышен допустимый размер"

9) Очень хотелось бы иметь возможность:

1. объединения нескольких сессий с одного канала inbox. Например есть клиенты, которые любят кинуть 4 письма подряд с разницей в 20 секунд по одному и тому же вопросу, было бы логично иметь возможность объединить их в одну сессию.
2. открытия уже закрытых сессий. Например пообщались в телеграмме, оператор закрыл сессию и внезапно понял что надо ещё кой-какую информацию дослать.
3. Разделить имя сессии и тему письма для каналов inbox в две разные сущности. Крайне неудобно, что нельзя трогать имя сессии для каналов inbox, так как ответы клиентам приходят с темой совпадающей с этим самым именем

Всё выловлено в версии on-premises 2023.6.13

upd.
1) Не вполне корректная работа с форварднутыми письмами
Если письмо приходит в линию форвардом, то, иногда (не всегда, но закономерность не вычислял),всё, что было в исходном сообщении, которое форвардят, никак не отображается
2) Не вполне корректная работа с алиасами и пересылками/сборщиками почты
Есть, например, адрес 111@aaa.com, живущий на яндексе. Цепляем его в линии. Приделываем к нему на яндексе алиас 222@aaa.com. Пишем письмо на 222@aaa.com с адреса 333@aaa.com. Получаем:

• В сессиях отображает двух клиентов - 333@aaa.com и 222@aaa.com
• Ответ оператора в сессии уйдёт также на два адреса, на 333@aaa.com (что верно) и на адрес 222@aaa.com, откуда тут же свалится снова на 111@aaa.com, ибо 222@ это алиас для 111@...

Та же самая ситуация если будет 2 ящика (а не алиас), и будет настроена либо пересылка с 222@ на 111@, или сборка почты на 111@ с ящика 222@

3) Некорректная работа с html разметкой в письмах
Если в письме было какое-то заковыристое html оформление например что-то типа этого:

То в сессиях вы увидите пустое письмо...

Спасибо за предоставленную информацию. Обработаем и проверим каждый кейс, после чего создадим тикеты в случае выявления ошибочного поведение и предоставим информацию о исправлении.

Добрый день! Ниже ответы по пунктам замечаний (воспроизводили на версии 2024.11):

1) Судя по скриншоту на форме просмотра элемента приложения Контакты для отражения истории переписки был использован виджет “Переписка в Линиях”. Непонятно, какие были настройки виджета. Для отражения истории необходимо выбрать Показать историю - По учетной записи и выбрать поле учетной записи, по которому будет собрана история.
2) Функционал реализован.
3) Функционал реализован.
4) Функционал реализован. Подключение канала WhatsApp сейчас осуществляется с помощью qr. Сессию с контактом WhatsApp можно начать, если номер телефона записан в формате +79121234567 или 79121234567.
5) Протестировала, форматирование сохраняется корректно. В планах на 2025 год переработать функционал работы с каналом Inbox, добавить возможности, которые присутствуют в типовых почтовых клиентах. Обратим внимание на форматирование, перепроверим.
6) Уточню, не воспроизводила.
7) Функционал реализован.
8) По описанной проблеме есть тикет: TEAM-25959 Системное уведомление в сессию при неуспешной доставке сообщения (канал inbox). Планируется его решить в 2025 году.
9) По предложениям:

• Заведен тикет: TEAM-25525 Объединение нескольких сессий в одну (Канал Inbox). Будет учтен при переработке функционала работы с Inbox в 2025 году.
  
• открытие уже закрытых сессий - пока не совсем понятна бизнес-ценность этого кейса. Почему критично досылать сообщения в той же сессии, а не в новой? При создании новой сессии вся история переписки доступна оператору.
  
• будет реализовано при переработке функционала работы с Inbox в 2025 году.

10) По поинтам во втором сообщении upd - будет учтено при переработке функционала работы с Inbox в 2025 году.​