Перед тем как выпустить всем, модуль прошел боевое крещение на нашем "
[spoiler]
За шесть месяцев разработки, мы сделали многое
Мы полностью отказались от предыдущего интерфейса и создали новый, основываясь на опыте популярных мессенджеров.
Окно диалога стало открываться в рамках страницы, в нем появились лица, появилось цветовое кодирование сообщений, появилась возможность легко вести разговор с несколькими людьми одновременно.
Мы добавили контакт-лист со списком ваших друзей ( списком коллег в рамках КП), что бы вы могли быстро перейти к ним в профиль, написать сообщение или прочитать предыдущую переписку.
Окно истории это отдельная тема, все давно хотели иметь поиск по истории, теперь он наконец у нас есть, планируем добавить туда еще и календарь для быстрой навигации.
Сделали центр уведомлений, с разными типами сообщений, предусмотрели возможность просмотреть историю их получения, а для разработчиков простое API для добавления и отзыва уведомлений.
И это все доступно на каждой странице вашего сайта !
К сожалению, реализовано далеко не все что планировалось
Первое, что мы не успели, это перевести сообщения на свои таблицы.
Такой переход позволил бы отказаться от модуля "социальная сеть", что дало бы большую свободу в выборе редакций, так же появилась бы возможность внедрить групповые чаты.
Второе, это реализация настоящей "мгновенной" связи. Сейчас в модуле используется обычный пулинг, раз в n-секунд опрос сервера, период опроса меняется в зависимости от активности общения.
Мы планируем написать отдельный сервис, который будет держать постоянные соединения и рассылать по мере надобности обновления данных (для мессенджера, для живой ленты и тд).
Третье, мы планируем немного изменить интерфейс, отказаться от раздельного контакт-листа и окна диалогов, объединить их в единое целое, что в перспективе позволит вынести мессенджер в мобильное приложение.
Документации пока нет и появится она не раньше осени, т.к. модуль активно развивается и мы хотим оставить возможность изменять API.
Тем не менее, я постараюсь публиковать примеры работы с той частью API над которой уже работы завершены и вы можете спокойно использовать их в своих модулях.
Работа с уведомлениями (актуально для IM начиная с версии 11.5.2)
Мы реализовали три типа уведомлений:
- персонализированное уведомление;
- уведомление от системы;
- уведомление требующее подтверждения (confirm);
П еред использованием API необходимо проверять установлен ли модуль в системе:
<? if (IsModuleInstalled("im") && CModule::IncludeModule("im")) { } ?> |
Персонализированное уведомление
<? $arMessageFields = array( // получатель "TO_USER_ID" => $USER->GetId(), // отправитель "FROM_USER_ID" => 2, // тип уведомления "NOTIFY_TYPE" => IM_NOTIFY_FROM, // модуль запросивший отправку уведомления "NOTIFY_MODULE" => "blog", // символьный тэг для группировки и массового удаления, если это не требуется - не задаем параметр "NOTIFY_TAG" => "BLOG|POST|123", // текст уведомления на сайте "NOTIFY_MESSAGE" => 'Прокомментировал ваше сообщение “<a href="http://test.ru/blog/post123">Пользовательские счетчики</a>”', // текст уведомления для отправки на почту (или XMPP), если различий нет - не задаем параметр "NOTIFY_MESSAGE_OUT" => 'Прокомментировал ваше сообщение "Пользовательские счетчики" ( http://test.ru/blog/post123 )' ); CIMNotify::Add($arMessageFields); ?> |
Уведомление от системы
<? $arMessageFields = array( // получатель "TO_USER_ID" => $USER->GetId(), // отправитель (может быть >0) "FROM_USER_ID" => 0, // тип уведомления "NOTIFY_TYPE" => IM_NOTIFY_SYSTEM, // модуль запросивший отправку уведомления "NOTIFY_MODULE" => "im", // символьный тэг для группировки (будет выведено только одно сообщение), если это не требуется - не задаем параметр "NOTIFY_TAG" => "IM_CONFIG_NOTICE", // текст уведомления на сайте (доступен html и бб-коды) "NOTIFY_MESSAGE" => '[b]Внимание:[/b] необходимо проверить и указать корректный путь до социальной сети в настройках модуля “Мгновенные сообщения и уведомления”', // текст уведомления для отправки на почту (или XMPP), если различий нет - не задаем параметр //"NOTIFY_MESSAGE_OUT" => '' ); CIMNotify::Add($arMessageFields); ?> |
Уведомление требующее подтверждения (confirm)
<? $arMessageFields = array( // получатель "TO_USER_ID" => $USER->GetId(), // отправитель "FROM_USER_ID" => 2, // тип уведомления "NOTIFY_TYPE" => IM_NOTIFY_CONFIRM, // модуль запросивший отправку уведомления "NOTIFY_MODULE" => "calendar", // символьный тэг для группировки (будет выведено только одно сообщение), если это не требуется - не задаем параметр "NOTIFY_TAG" => "CALENDAR|INVITE|123|".$USER->GetId(), // текст уведомления на сайте (доступен html и бб-коды) "NOTIFY_MESSAGE" => "Приглашаю вас принять участие во встрече “Мгновенные сообщения и уведомления” которая состоится 15.03.2012 в 14:00", // текст уведомления для отправки на почту (или XMPP), если различий нет - не задаем параметр "NOTIFY_MESSAGE_OUT" => "Пользователь Евгений Шеленков приглашает вас принять участие во встрече “Мгновенные сообщения и уведомления” #BR# которая состоится 15.03.2012 в 14:00.#BR# #BR# Принять: http://test.ru/calend.php?CONFIRM=Y&CID=123 #BR# Отказаться: http://test.ru/calend.php?CONFIRM=N&CID=123", // массив описывающий кнопки уведомления "NOTIFY_BUTTONS" => Array( // 1. название кнопки, 2. значение, 3. шаблон кнопки, 4. переход по адресу после нажатия (не обязательный параметр) Array('TITLE' => 'Принять', 'VALUE' => 'Y', 'TYPE' => 'accept' /*, 'URL' => 'http://test.ru/?confirm=Y' */), Array('TITLE' => 'Отказаться', 'VALUE' => 'N', 'TYPE' => 'cancel' /*, 'URL' => 'http://test.ru/?confirm=N' */), ), // символьный код шаблона отправки письма, если не задавать отправляется шаблоном уведомлений "NOTIFY_EMAIL_TEMPLATE" => "CALENDAR_INVITATION", ); CIMNotify::Add($arMessageFields); ?> |
Обслуживание
Есть два варианта, самый простой, переход по ссылке ( если задать 4 параметр в NOTIFY_BUTTONS ).
После перехода по ссылке, в вашем коде нужно вызвать следующий код:
<? // удаляем уведомление по тэгу (который вы задали при отправке, можно указать только часть к примеру CALENDAR|INVITE|123) CIMNotify::DeleteByTag("CALENDAR|INVITE|123|".$USER->GetId()); ?> |
При множественной рассылке необходимо это учитывать, что бы выполнение действия одним пользователем случайно не удалило уведомление всем (кроме мест где такая логика нужна).
Второй вариант, на событиях.
1. нужно зарегистрировать зависимость
<? RegisterModuleDependences("im", "OnBeforeConfirmNotify", "yourmodule", "CYourModuleEvents", "CYourModuleEventsIMCallback"); ?> |
2. в вашем модуле yourmodule в классе CYourModuleEvents в методе CYourModuleEventsIMCallback
пишем функцию обработку события
<? /* Module IM callback */ // 1. NOTIFY_MODULE, 2. NOTIFY_TAG, 3. значение нажатой кнопки VALUE из массива NOTIFY_BUTTONS, 4. все данные о нотификации function CYourModuleEventsIMCallback($module, $tag, $value, $arNotify) { // проверка нажата кнопка конфирма от твоего модуля или нет if ($module == "yourmodule") { // бьем тэг, что бы получить данные из тэга // к примеру у нас тэг был такой "CALENDAR|INVITE|123|".$USER->GetId() // 0. модуль, 1. тип события, 2. номер уведомления, 3. пользователь получатель $arTag = explode("|", $tag); if ($arTag[1] == "INVITE") { if ($value == 'Y') ConfirmRequest($arTag[2], $arTag[3]); else RejectRequest($arTag[2], $arTag[3]); return true; } } } ?> |
На этом пока все, жду ваших предложений в комментариях, удачных внедрений!
Если вы хотите попробовать API до выхода 11.5.2 в массив с параметрами необходимо дополнительно указывать "MESSAGE_TYPE" => IM_MESSAGE_SYSTEM, так же у уведомлений confirm не будет работать вариант с ссылкой в кнопках. Но лучше подождать, обновление 11.5.2 должно выйти 23 мая.
Фото:
Кейз: Вернулся из отпуска, у меня 200 уведомлений. Мне не интересно, что там написали в блогах и рабочих группах, а вот как происходили изменения в задачах - интересно. Вылавливать этот десяток уведомлений из 200 - уже не интересно. Если бы мог зайти и посмотреть только уведомления по задачам - интересно.
Ладно, задачи неудачный пример, они имеют и свои механизмы отображения наличия изменений и отчёты. Пусть это будут бизнес-процессы, в которых генерятся уведомления. Единственный нормальный способ держать пользователей в курсе происходящего в бизнес-процессе, магической зелёной иконки с количеством новых изменений в процессе и отчётов там нет. И вот я сижу и вылавливаю 10 уведомлений из бизнес-процессов из 200 других. А реально может быть и больше.
Продвинутый кейз: вернёмся к категориям-тегам, которые я озвучивал в идеях - мне может быть интересен просмотр уведомлений не в пределах модуля, а в пределах, например, конкретного бизнес-процесса только... Тут провал. С категориями - это был бы дополнительный фильтр, значения которого я мог бы задавать, как мне угодно.
Ну и просто поиск по уведомлениям, хочу я посмотреть, когда мне там прилетело какое-то конкретное уведомление и что в нём было, пару слов помню, остальное не помню.
Кстати, у уведомлений есть время жизни или они вечные?
Соглашусь, проблема с 200 уведомлениями за раз есть.
На данном этапе вашу идею сложно реализовать, т.к. не все модули еще используют новое API, а попадая через старое апи - они помечаются как сообщение от соц.сети.
После перехода на новое API мы займемся реализацией вашей идеи с поиском и фильтром.
Время жизни у уведомлений нет, после прочтения оно скроется и останется в истории (confirm удаляются сразу). Если оно совсем не нужно его можно закрыть.
Уже почти 2.5 года минуло, вроде бы всё поперетаскивали на мессенджер, когда будет возможность фильтрануть по модулям? Желательно ещё и с возможностью учитывать NOTIFY_EVENT =)
В перспективах только переработка истории, к уведомлениям даже не подходили.
Можно развернуть до нужных размеров или хочется кнопку "развернуть на весь экран" ?
Допустим, мне необходимо, чтобы пользователь получал системные уведомления, при этом сам не мог использовать модуль. Или же, допустим, находясь в какой-то группе мог использовать определенный функционал модуля?
Спасибо.
а при попытке отправить сообщение, получил системную ошибку:
настроек, кстати, тоже нет в админке.
обращение в техподдержку # 291892
если на странице присутствует этот компонент, то fatal error в публичке.
Принял такое решение, раз уж наступил в это все.
Установил модуль снова, окна с сообщениями прекрасно заработали, не работают попапы в социальной сети, не работает автоматическое появление новых сообщений, так как пришлось убрать из шаблона bitrix:socialnetwork.events_dyn
Большая просьба, взять у техподдержки админ доступ на Грек.ру и сделать так, чтобы новые сообщения хотя бы появлялись.
И, надеюсь, что таких модулей больше не будет в стабильных обновлениях, а то скоро и Битрикса не будет, если он такими модулями стабильными обрастет.
Евгений, чего делать-то с Вашим творчеством?
Меседжер социальной сети стал работать с 20го раза
тоесть жмакаешь - написать сообщение (пользователю)
Высплывает пустое окно
рефрешь его раз 20ть - иногда что то подхватывает и загружается
Просьба срочно исправить и выпустить Fix
Можно инструкцию по шаговую, ну или хотя бы вектор - куда рыть?!
Работать с сообщениями мессенджером удобней, чем было раньше, это да. А вот по уведомлениям есть неудобство - пришло пользователю за какой-то период 10 уведомлений, он один раз открыл диалог уведомлений - кликнул и перешёл по ссылке в одном из них, отрефрешил страницу, ещё что, а они уже все считаются прочитанными, какие из них новые и не обработанные, а какие уже старые - пользователь может понять, только если помнит их. Это не удобно. Как-нибудь придумать бы что-нибудь для этой ситуации, типа возможности для уведомлений включать крыжик "прочитано", как было у старых сообщений.
Выполнили конвертацию сообщений из соц.сети в новый формат, как было предложено системой.
После этого, без какого-либо предупреждения или уведомления начали рассылаться старые сообщения (от 2009 года, например) пользователям, с предложением просмотреть их.
Модуль не настроен, ссылки на сообщения не настроены, однако рассылка сразу запустилась. Хорошо, что мы вовремя заметили и удалили из b_event задания на отправку (более 20тыс)...
Как можно выпускать такой сырой модуль в продакшн?
Оказалось, что переписали метод и теперь стало обязательным элементом массива поле "AUTHOR_ID" (значение больше нуля).
Версия Битрикса: 12.0.10.
ибо
Мы планируем написать отдельный сервис, который будет держать постоянные соединения и рассылать по мере надобности обновления данных (для мессенджера, для живой ленты и тд).
Если группировка не нужна, уберите тег.
Если тег нужен для массового удаления - используйте другой ключ NOTIFY_SUB_TAG по нему не осуществляется группировка.
И для удаления используйте вместо
CIMNotify::DeleteByTag другой метод CIMNotify::DeleteBySubTag
Отсутствуют как просто уведомления, так и с упоминанием пользователя.
Зато присутствует уведомление о like сообщения пользователя.
ТП утверждает что их никогда не было, но на портале имеется 58 000 примеров данных уведомлений.