В сентябре у нас было несколько интересных внедрений коробочной версии Битрикс24. Об одном из них расскажу в данном посте. Клиент хотел расширить функционал модуля технической поддержки.
В стандартном модуле Битрикс24 нормативное время ответа на обращение в техподдержку зависит только от уровня поддержки (SLA). Критичность обращения и категория обращения не влияют на формирование крайнего срока реакции на обращение.
Нужно было сделать, чтобы подсчет времени для ответа на обращение вычислялся исходя из:
• уровня поддержки
• критичности обращения
• категории обращения
Кроме того, в стандартном функционале «1С-Битрикс24: Корпоративный портал» сущности «Обращения в техподдержку» и «Задачи» никак не связаны. Необходимо было в интерфейсе обработки обращения техподдержки (в административной части) добавить кнопку «Создать задачу», при нажатии на которую должна была автоматически создаваться задача на проведение работ на основании данного обращения с возможностью включения данной задачи в отчеты и возможностью учета времени по данной задаче.
Так как весь оставшийся функционал модуля технической поддержки должен был работать так же, как и раньше, а так же должна была оставаться возможность обновлять модуль и получать с обновлениями новый функционал модуля, кастомизировать поведение модуля было решено через перехват событий:
OnAfterTicketAdd — это событие возникает при добавлении нового обращения в ТП;
OnAfterTicketUpdate — это событие возникает при изменении обращения (в том числе при добавлении сообщения в обращение);
Апи модуля технической поддержки Битрикс 24 не отличается подробной документацией, поэтому исследовать то, как работает стандартный модуль ТП, вычисляя дедлайн для ответа на обращение было достаточно сложно. Анализируя то, как хранится обращение в БД модуля, я заметила, что дедлайн по обращению, к счастью, нигде не вычисляется динамически, а хранится в одной таблице с информацией о самом обращении и пересчитывается при апдейте обращения. Именно этот факт и позволили использовать обработчики событий OnAfterTicketAdd и OnAfterTicketUpdate для решения первой части задачи.
Для хранения расширенной таблицы настроек модуля технической поддержки мы завели в Битрикс 24 отдельный хайлоадблок, хранящий соответствия сочетания уровня/критичности/категории и времени реакции на обращение.
Благодаря тому, что в админке Битрикс24 реализован механизм фильтрации хайлоадблока по значениям полей, пользоваться данной настроечной таблицей — достаточно удобно.
Далее встал вопрос о том, как сделать, чтобы настройки времени реакции в составе настроек уровня техподдержки игнорировались. Оказалось — достаточно просто создавать в стандартном функционале уровни поддержки без ограничения времени реакции на обращение. Время реакции мы потом задаем кастомным механизмом, при этом если для обращения задан дедлайн — уведомления о том, что пора отвечать — отрабатывают как надо.
Соответсвенно, задача свелась к тому, чтобы в вышеуказанных обработчиках получать из хайлоадблока нормативное время на основании данных о критичности/уровне/категории по данным обращения, затем вычислять новый дедлайн ответа на обращение с учетом расписания работы технической поддержки, а затем записывать найденный дедлайн в обращение.
Не обошлось без небольших курьезов: оказалось, что в обработчик события OnAfterTicketAdd не передаются данные SLA_ID для обращения, при том, что на самом деле в этот момент обращение уже записано и SLA_ID — известен — пришлось доставать его дополнительно.
Со второй частью задачи не возникло особых проблем — мы кастомизировали в папке local админские страницы редактирования обращения в техподдержку и списка обращений в техподдержку и добавили функционал создания задачи на основании обращения:
Можно создать задачи сразу для нескольких обращений, а можно только для одного.
Задачи содержат ссылку на обращение непосредственно в своем описании:
Реализация данного кейса заняла около 20 человеко-часов, и это было бы невозможно сделать с такими же трудозатратами в облачной версии Битрикс 24. Покупая коробочную версию Битрикс 24 — клиенты могут серьезно сэкономить на дальнейшем расширении функционала.