1 подписчик

Bitrix24 - разбираемся с привязкой почты

25 ноября 202225 ноя 2022

112

2 мин

Оглавление

Что удалось получить в итоге
Особенности
Логика работы

В принципе организация взаимодействия с клиентом с помощью Bitrix24 устраивает практически полностью. В части визуализации вопросов нет совсем: все достаточно удобно и на своих местах.

Не нравится реализация привязки писем к сущностям CRM (контакты, компании, сделки) - то письмо не привязалось, то оно привязалось куда-то в другое место.

Ознакомившись с имеющимися в интернете вариантами решения схожих проблем
- https://blog.bedrosova.ru/2016/03/03/битрикс24-входящая-почта-без-единого-по/
- https://www.infospice.ru/blog/bitrix_inside/bitriks24-kp-crm-kak-sdelat-svoye-pravilo-dlya-obrabotki-pisem/
было принято решение написать свой обработчик, т.к. оказалось, что штатную логику привязки (функция CCrmEMail::EmailMessageAdd) изменить практически не возможно.

Кратко опишем затрагиваемые таблиц в БД для общего понимания процесса, ну и чтобы не забыть:

b_mail_message - все письма сохраняются в эту таблицу, после получения из через IMAP.
b_mail_mailbox - список почтовых ящиков.
b_crm_act_comm - для каждого события прописываются параметры.
b_mail_msg_attachment - вложения
b_file - файлы (из вложений)

Что удалось получить в итоге

Если находим контакт(ы) с нужным почтовым адресом - крепим письмо туда.
Находим компанию у контакта - крепим письмо туда (дополнительно контролируем, чтобы ничего не задублировалось).
Если в теме письма указан номер сделки в фигурных скобках [4384] - туда тоже крепим письмо.
Если на момент получения \ написания письма контакта нет в CRM - не беда, обработаем, когда пользователь создаст контакт. Скрипт добавлен в CRON и обрабатывает последние 1000 писем.
Что очень важно - мы не меняем исходный код продукта, что всегда позитивно сказывается как на обновлениях, так и на безболезненном отказе от использования текущей схемы.

Особенности

Почему-то не сохраняются вложения, если нет правила обработки ящика. Даже пустого. Пришлось насоздавать для каждого ящика пустое правило обработки.
Не у всех вложений корректно переносятся наименования, также по какой-то неведомой логике вложение имеет наименование в виде хэша без расширения файла, хотя в таблице b_mail_msg_attachment корректное наименование присутствует - пришлось добавить функцию принудительного переименования файла как в БД, так и в файловой системе.
У нас в компании практически у всех почт существуют алиасы, например, petrov.a@ будет еще иметь короткий адрес pa@ - эту информацию решил записывать в описание почтового ящика, столбец DESCRIPTION (нужна для определения направления письма).
Если в БД у почтового ящика USER_ID поставить 0, то ящик будет считаться системным. Решил, что ящики должны быть системными и ID пользователя перенес в столбец LINK.

Логика работы

Проверяем есть ли необработанные письма.
Определяем направление коммуникации.
Ищем контакты \ компании с совпадающим адресом электронной почты.
Добавляем во все контакты и связанные компании событие с письмом.
Обновляем EXTERNAL_ID у письма, чтобы больше его не обрабатывать (записываем туда ID события, больше нужно для отладки).