• Архив

    «   Октябрь 2018   »
    Пн Вт Ср Чт Пт Сб Вс
    1 2 3 4 5 6 7
    8 9 10 11 12 13 14
    15 16 17 18 19 20 21
    22 23 24 25 26 27 28
    29 30 31        

История настройки одной телефонии в Битрикс24 (коробка)

Обратился к нам недавно один клиент и говорит: "Купили Битрикс24 почти год назад, и с тех пор никто не может настроить нам телефонию". Я подумала, что стоит разобраться с проблемой этого клиента - телефонию мы до этого в коробочной версии Битрикс24 настраивали неоднократно, и я думала, что меня вряд ли можно чем-то удивить по части ее настройки. Однако впереди нас ждали увлекательные открытия.

Зайдя в портал клиента на страницу Телефония - Балланс и статистика, я увидела 2 арендованных номера внутренней Битриксовской телефонии, но ни страница детализации звонков, ни страницы настроек этих телефонных номеров - не открывались. Я предположила, что модуль телефонии поврежден либо на уровне файлов, либо на уровне БД. Мониторинг качества показывал, что файлы модуля телефонии не были модифицированны. А вот в БД отсутствовала таблица b_voximplant_config. Я восстановила таблицы модуля телефонии из одного из старых бекапов портала клиента, к-е, к счастью, снимались у клиента автоматически.

Страницы детализации звонков и настройки телефонных номеров стали открываться, и в статистике даже были кое-какие записи звонков, из которых я заключила, что телефония у клиента уже была настроена, но потом почему-то отвалилась. Однако ни на входишие звонки, ни на исходящие - телефония не работала, а серверный тест Битрикс показывал кучу ошибок, относящихся к работе бизнес-функций портала, модуля Push and Pull

Мы перенесли клиента на Сервера без забот хостинга Русоникс, а так же настроили для портала клиента SSL сертификат и работу по протоколу https, после этого серверный тест Битрикс перестал выявлять проблемы, а исходящие и входящие звонки через телефонию Битрикс стали осуществляться нормально. Я сказала клиентам, что они могут тестировать телефонию, и я видела по журналу в детализации звонков, что они активно ею пользуются.

Однако ИТ отдел клиента начал жаловаться мне, что они "не знают тех людей, чьи записи звонков прослушивают в детализации". Сначала я подумала, что они просто не знают всех сотрудников своей компании, но когда начала сама прослушивать записи звонков в портале, я поняла, что в портал моего клиента сохраняются записи каких-то совершенно "левых" звонков (там в записях сотрудники почти всегда называли название другой компании, представляясь).

Я написала об этой проблеме в ТП Битрикс. Битриксоиды начали прорабатывать проблему по своим каналам, и выяснилось, что предыдущий подрядчик клиента (то ли самый первый, то ли промежуточный - клиент их сменил несколько) как-то умудрился по ошибке ввести лицензионный ключ от портала моего клиента в портале другого клиента, и после этого аккаунты телефоний этих двух клиентов "склеились", и нам падали записи звонков тех других клиентов, а они, в свою очередь, могли слушать у себя в портале записи наших тестовых звонков.

Битриксоиды заменили моему клиенту лицензионный ключ - но это не решило проблему - сами по себе аккаунты телефонии не расклеились. Я продолжала писать сообщения об этом в поддержку Битрикса, и в итоге они сменили моему клиенту и номер аккаунта на стороне информационного посредника voximplant, но, правда, все настройки модуля телефонии пришлось удалить и отвязать арендованные телефоны, ну и деньги на аккаунте клиента сгорели, конечно, но это уже были мелочи в масштабе всех проблем.

Арендовали клиенту новый номер в телефонии Битрикс24 - и на нем все работало как надо. Чужие телефонные звонки мы больше не слушали.

Эпопея на этом не закончилась. У клиента был еще арендован старый телефонный номер у Плюсофона https://plusofon.ru/, и, естественно, клиент не хотел терять этот номер, а хотел привязать его в Битрикс24 через SIP. Поддержка Плюсофона сообщила нам, что их телефоны еще ни разу не удалось подключить к Битрикс24, но я подумала, что SIP - он и в Африке SIP, и решила, что он заработает, если хорошо захотеть и проявить терпение и методичность, общаясь с обеими техподдержками.

Для начала я запросила логины/пароли SIP аккаунтов у Плюсофона, и не стала сразу пробовать подключить их в Битрикс24, а скачала себе на телефон популярный SIP клиент Зойпер, чтобы изолированно проверить, работает ли у них SIP вообще. Подключиться не удавалось. Расследование показало, что те логины/пароли SIP к-е видели админы моего клиента в личном кабинете Плюсофона - были неправильными. Плюсофоновцы уже пофиксили эту проблему.

Далее я ввела логин/пароль одного из SIP пользователей в подключение на стороне Битрикс24. Исходящий звонок не проходил - пользователь SIP светился в сети Плюсофона как оффлайн. Пообщавшись немного с техподдержкой Плюсофона, я натолкнула их на мысль, что у них на серверах IP-адреса, с которых проходит сигнал от Битрикс - в черных списках. Действительно, на Плюсофоне к SIP было разрешено подключаться только с Российских IP-адресов, а так как звонок из Битрикс идет через информационного посредника  voximplant, сигнал приходил на Плюсофон с IP-адресов, относящихся к территории США. Плюсофоновцы разрешили коннекты с этих адресов, и исходящие звонки через SIP стали проходить из портала клиента.

На этом история не закончилась. Я заметила, делая звонки через SIP из портала клиента, что запись звонков не происходит, хотя стоит соответствующая галка, а тестовые минуты для тестирования SIP не списываются (жаль, не провела исследование, сколько так реально можно бесплатно звонить). Написала снова в ТП Битрикс, они сказали мне включить на стороне сервера директиву proxy_ignore_client_abort on; - это решило проблему.

Далее я начала тестировать SIP на входящие звонки в портал. Звонки то проходили, то не проходили. По логам Плюсофона теперь уже сервера voximplant отклоняли их коннекты (не каждый раз). Долго я посылала эти логи в поддержку Битрикса. Они долго отказывались признавать эту проблему, потом я уже не выдержала и написала Рыжикову (спасибо ему, что вник). После этого Битриксоиды что-то подкрутили на стороне voximplant, и звонки через SIP, наконец то, стали проходить стабильно.

В следующем посте, я расскажу, как мы интегрировали с порталом Битрикс24 клиента программную АТС на базе Астриск.

Битрикс24 в локальной сети клиента - что делать, если не приходят письма с портала?

Я думаю, то, что я сейчас опишу в данном посте - это отнюдь не новость для unix-администраторов. Но я думаю, это может быть полезено внедренцам для того, чтобы дать администратору задание копать в нужном направлении.

Итак, что же делать, если письма из портала Битрикс24, расположенного в локальной сети предприятия не приходят адресату (порой даже не попадают в папку Спам)?

1) Нужно произвести диагностику. Для этого можно воспользоваться специальным сервисом, к примеру: https://www.mail-tester.com Смысл сервиса в том, что вам дается специальный емейл, на который нужно отправить письмо для диагностики. Отправляешь письмо - сервис пишет список проблем, которые не дают данному письму быть доставленным адресатом.

2) Большинство проблем, которые показывает сервис диагностики связаны с неправильной настройкой ДНС домена. Если почта хостится на гугле или на яндексе, или на мейле - эти почтовые службы обычно пишут, какие ДНС должны быть прописаны для домена, чтобы письма корректно отправлялись.

Например:

То есть, необходимо проверить, что в доменной зоне того домена, который привязан к порталу Битрикс24 правильно прописаны MX, SPF и TXT записи с подписью.

3) Если Битрикс24 расположен в локальной сети предприятия, для корректной отправки почты с него необходимо так же позвонить провайдеру (интернет-провайдеру, который предоставляет предприятию статичный IP адрес) и попросить его прописать "обратную зону" для данного IP адреса и привязанного к нему домену.

4) Ну и конечно, нужно убедиться, что правильно настроен Postfix. По этому вопросу естьподробная инструкция в учебных курсах по Битрикс.

Расширенная детализация звонков в Битрикс24

Недавно мы внедряли Битрикс24 в компании, которая оказывает своим клиентам техническую поддержку по телефону, используя телефонию Битрикс24. Для этой компании мы решили интересную задачу - формирование расширенной детализации телефонных звонков, произведенных через портал.

Стандартная станица детализации телефонных звонков в Битрикс24 довольно бедна и не предполагает возможности сорировки и поиска по различным полям данных.

Этот недостаток мы исправили в своем кастомном решении для статистики и детализации телефонных звонков в Битрикс 24.

Были реализованы следующие возможности:

1) Фильтр (поиск) таблицы телефонных звонков по различным параметрам: поиск по номеру телефона, фильтр по дате звонка, позволяющий выбрать любой период времени, фильтр по типу и статусу звонка, по наличии записи телефонного разговора, по сотруднику, принявшему вызов, а так же по компании/контакту, от которых поступил данный телефонный звонок:


2) Сортировка как отфильтрованной, так и неотфильтрованной выборки звонков по любой из колонок детализации:


3) Возможность создать контакт в CRM Битрикс24 с данным телефонным номером прямо из контекстного меню в детализации звонков:


4) Возможность сгруппировать детализацию звонков по компании (контакту) и отсортировать детализацию в режиме группировки. Это позволяет, к примеру, наглядно видеть, от какого клиента поступает больше всего звонков, что очень важно, если клиентам оказывается телефонная техническая поддержка:



Сгруппированную выборку так же возможно фильтровать по любому из вышеперечисленных полей.

Статусы продуктов (товаров/услуг) в составе сделки Битрикс24

В очередной раз реализовали наш старый кейс>> со статусами товаров для новых клиентов.
Был немного улучшен интерфейс установки статуса товара.



Как и прежде, на событие перехода товара/услуги в конкретный статус в составе сделки в Битрикс24 можно повесить запуск отдельного бизнес-процесса.

Кейс достаточно востребован - планируем обернуть его под Маркетплейс, хотя вряд ли будем публиковать решение в общем каталоге, потому что его внедрение каждый раз требует учета специфики работы конкретной организации - клиента.

Бизнес-процессы в Битрикс 24: сложности внедрения

Казалось бы, дизайнер бизнес-процессов в Битрикс 24 - мощнейший механизм, позволяющий автоматизировать все, что угодно. Никакого программирования - вытаскивай кубики-активити - и любой воркфлоу спроектирован за 2 часа.

Однако же потребности реальных пользователей, их ожидания, порой серьезно расходятся с реализованными в Битрикс 24 возможностями, и процесс внедрения Битрикс 24 либо превращается, как в том анекдоте про экскурсовода - в обучение пользователей обходиться без того, что они считают естественным, либо растягивается на месяцы работы.

Возьмем, к примеру, банальный бизнес-процесс оформления больничного листа, который не раз автоматизировал, наверное, каждый внедренец Битрикс 24. И в каждой новой компании - по-разному.

Дано: трехэтапное утверждение больничного листа:

Сначала Больничный лист утверждает начальник отдела Business Manager, потом ответственный из отдела кадров HR, а уже потом ответственный за начисление заработной платы Payroll.

Какие сложности могут возникнуть при проектировании такого простого бизнес-процесса?

Сложность №1: тестирование в условиях когда пользователи уже активно используют портал. Понятное дело: разработку БП приходится вести в девелоперской копии, перелогиниваясь для теста под различными участниками процесса. Перелогиниваться бывает достаточно муторно, а кроме того, должны быть протестированы и email-уведомления, к-е до поры - до времени не должны приходить реальным пользователям.

Для упрощения процесса тестирования мы заводим в каждом БП переменную для хранения пользователей, которым разрешена отладка - они могут протолкнуть процесс дальше в любом месте.

Естественно, для этого переменная, хранящая пользователей-тестеров, должна быть добавлена во все необходимые активити.

Сложность №2: когда пользователь должен что-то проаппрувить, у него появляется соответсвующее задание в бизнес-процессах (не путать с задачами). Клиенты хотят, чтобы пользователь получал емейл в тот момент, когда от него ожидается одобрение, емейл, содержащий ссылку не на весь раздел с заданиями БП, а на конкретную страничку задания.

Для решения этой проблемы шаблон БП для входа в состояние "Approve from HR" из нашего примера превращается вот в такую громоздкую конструкцию:

Прикол в том, что пока в активити аппрува не произошел этот самый аппрув, стандартными средствами БП мы не можем узнать ИД таска, поэтому его приходится доставать, используя php-код:

CModule::IncludeModule("bizproc");
$arSelectFields = array("ID", "WORKFLOW_ID", "ACTIVITY", "ACTIVITY_NAME", "MODIFIED", "OVERDUE_DATE", "NAME", "DESCRIPTION", "PARAMETERS", "STATUS","USER_STATUS");
$dbRecordsList = CBPTaskService::GetList(
  array("ID" => "DESC"),
  array('WORKFLOW_ID'=>'{=Workflow:ID}'),
  false,
  false,
  $arSelectFields
 );
$arRecord = $dbRecordsList->getNext();
$rootActivity = $this->GetRootActivity();
$rootActivity->SetVariable("TaskLink", 'http://адреспортала/company/personal/bizproc/'.$arRecord['ID'].'/'); 

Этот код выбирает все таски данного БП, в порядке от последнего, к первому, нам как раз нужен последний.

Сложность №3: электронного прогона по всем инстанциям недостаточно компании, где исторически использовался бумажный документооборот, и на этапе, когда больничный лист из примера попадает к Payroll (к бухгалтеру), бухгалтер должен помимо всего прочего иметь возможность распечатать себе бумажку "для отчетности". Поэтому наш бизнес-процесс должен еще формировать PDF-файл и сохранять ее в соответствующем разделе библиотеки документов.
Сформировать PDF файл для данного примера можно следующей php-вставкой (спасибо, что в Битрикс 24 есть класс CSalePdf для работы с PDF):
CModule::IncludeModule("sale");
use Bitrix\Main\Type\DateTime;
$date = new DateTime('{=Document:DATE_CREATE}');
$date=$date->format("d-m-Y");
if (!CSalePdf::isPdfAvailable()) die();
$ID={=Document:ID};
$IBLOCK_ID={=Document:IBLOCK_ID};
$PROPS=array();
$db_props = CIBlockElement::GetProperty($IBLOCK_ID, $ID);
while($ar_props = $db_props->Fetch())
{
$PROPS[$ar_props['ID']]=$ar_props;
}
$pdf = new CSalePdf('P', 'pt', 'A4');
$pageWidth  = $pdf->GetPageWidth();
$pageHeight = $pdf->GetPageHeight();
$pdf->AddFont('Font', '', 'pt_sans-regular.ttf', true);
$pdf->AddFont('Font', 'B', 'pt_sans-bold.ttf', true);
$fontFamily = 'Font';
$fontSize   = 10.5;
$margin = array(
 'top' => 15 * 72/25.4,
 'right' => 15 * 72/25.4,
 'bottom' => 15 * 72/25.4,
 'left' => 15 * 72/25.4
);
$width = $pageWidth - $margin['left'] - $margin['right'];
$pdf->SetDisplayMode(100, 'continuous');
$pdf->SetMargins($margin['left'], $margin['top'], $margin['right']);
$pdf->SetAutoPageBreak(true, $margin['bottom']);
$pdf->AddPage();
$pdf->SetFont($fontFamily, 'B', $fontSize*2);
$pdf->Cell(0, 30, $pdf->prepareToPdf('{=Document:NAME}`s personal leave '.$date), 0, 0, 'C');
$pdf->Ln();
$pdf->Ln();
$pdf->Ln();
$pdf->Ln();
$pdf->SetFont($fontFamily, '', $fontSize);
$pdf->Cell(0, 15, $pdf->prepareToPdf('Request content:'), 0, 0, 'L');
$pdf->Ln();
$pdf->Ln();
 $ROW1=150;
$Y=15;
$pdf->Cell($ROW1, $Y, $pdf->prepareToPdf('Employee Name:'), 0, 0, 'L');
$pdf->MultiCell(0, $Y, $pdf->prepareToPdf('{=Document:NAME}'), 0, 'L');
$pdf->Cell($ROW1, $Y, $pdf->prepareToPdf('First day of leave:'), 0, 0, 'L');
$pdf->MultiCell(0, $Y, $pdf->prepareToPdf('{=Document:PROPERTY_225}'), 0, 'L');
$pdf->Cell($ROW1, $Y, $pdf->prepareToPdf('Last day of leave:'), 0, 0, 'L');
$pdf->MultiCell(0, $Y, $pdf->prepareToPdf('{=Document:PROPERTY_226}'), 0, 'L');
$pdf->Cell($ROW1, $Y, $pdf->prepareToPdf('Type of leave:'), 0, 0, 'L');
$pdf->MultiCell(0, $Y, $pdf->prepareToPdf('{=Document:PROPERTY_227}'), 0, 'L');

$myfile='temp.pdf';
$pdf->Output($myfile, 'F');
if (!copy($myfile,$_SERVER['DOCUMENT_ROOT'].'/docs/appforms/forms/personal_leave_requests/request_'.$ID.'.pdf'))
{  }else{  unlink($myfile);  } 
Можно ли реализовать бизнес-процесс обработки больничного листа в облачной версии Битрикс24? Можно, но ущербно - отказавшись от перечисленных в пунктах 2 и 3 примочек, возможных, только в коробочной версии.

Битрикс 24 - опыт расширения функционала модуля "Техподдержка"

В сентябре у нас было несколько интересных внедрений коробочной версии Битрикс24. Об одном из них расскажу в данном посте. Клиент хотел расширить функционал модуля технической поддержки.

В стандартном модуле Битрикс24 нормативное время ответа на обращение в техподдержку зависит только от уровня поддержки (SLA). Критичность обращения и категория обращения не влияют на формирование крайнего срока реакции на обращение.

Нужно было сделать, чтобы подсчет времени для ответа на обращение вычислялся исходя из:

• уровня поддержки
• критичности обращения
• категории обращения

Кроме того, в стандартном функционале «1С-Битрикс24: Корпоративный портал» сущности «Обращения в техподдержку» и «Задачи» никак не связаны. Необходимо было в интерфейсе обработки обращения техподдержки (в административной части) добавить кнопку «Создать задачу», при нажатии на которую должна была автоматически создаваться задача на проведение работ на основании данного обращения с возможностью включения данной задачи в отчеты и возможностью учета времени по данной задаче.

Так как весь оставшийся функционал модуля технической поддержки должен был работать так же, как и раньше, а так же должна была оставаться возможность обновлять модуль и получать с обновлениями новый функционал модуля, кастомизировать поведение модуля было решено через перехват событий:

OnAfterTicketAdd - это событие возникает при добавлении нового обращения в ТП;
OnAfterTicketUpdate - это событие возникает при изменении обращения (в том числе при добавлении сообщения в обращение);

Апи модуля технической поддержки Битрикс 24 не отличается подробной документацией, поэтому исследовать то, как работает стандартный модуль ТП, вычисляя дедлайн для ответа на обращение было достаточно сложно. Анализируя то, как хранится обращение в БД модуля, я заметила, что дедлайн по обращению, к счастью, нигде не вычисляется динамически, а хранится в одной таблице с информацией о самом обращении и пересчитывается при апдейте обращения. Именно этот факт и позволили использовать обработчики событий OnAfterTicketAdd и OnAfterTicketUpdate для решения первой части задачи.

Для хранения расширенной таблицы настроек модуля технической поддержки мы завели в Битрикс 24 отдельный хайлоадблок, хранящий соответствия сочетания уровня/критичности/категории и времени реакции на обращение.




Благодаря тому, что в админке Битрикс24 реализован механизм фильтрации хайлоадблока по значениям полей, пользоваться данной настроечной таблицей - достаточно удобно.

Далее встал вопрос о том, как сделать, чтобы настройки времени реакции в составе настроек уровня техподдержки игнорировались. Оказалось - достаточно просто создавать в стандартном функционале уровни поддержки без ограничения времени реакции на обращение. Время реакции мы потом задаем кастомным механизмом, при этом если для обращения задан дедлайн - уведомления о том, что пора отвечать - отрабатывают как надо.

Соответсвенно, задача свелась к тому, чтобы в вышеуказанных обработчиках получать из хайлоадблока нормативное время на основании данных о критичности/уровне/категории по данным обращения, затем вычислять новый дедлайн ответа на обращение с учетом расписания работы технической поддержки, а затем записывать найденный дедлайн в обращение.

Не обошлось без небольших курьезов: оказалось, что в обработчик события OnAfterTicketAdd не передаются данные SLA_ID для обращения, при том, что на самом деле в этот момент обращение уже записано и SLA_ID - известен - пришлось доставать его дополнительно.

Со второй частью задачи не возникло особых проблем - мы кастомизировали в папке local админские страницы редактирования обращения в техподдержку и списка обращений в техподдержку и добавили функционал создания задачи на основании обращения:

Можно создать задачи сразу для нескольких обращений, а можно только для одного.

Задачи содержат ссылку на обращение непосредственно в своем описании:


Реализация данного кейса заняла около 20 человеко-часов, и это один из тех кейсов, который невозможен в облачной версии Битрикс24. Покупая коробочную версию Битрикс 24 - клиенты получают и более широкий функционал и возможность серьезно сэкономить на дальнейшем расширении функционала.  

Битрикс24 - опыт расширения функционала за счет бизнес-процессов (коробочная версия)

Битрикс24 - в коробке - это просто потрясающий продукт, от которого я в полном восторге. В восторге от того, как легко на базе этого продукта можно автоматизировать абсолютно любой документооборот, абсолютно любые бизнес-процессы компании, как легко расширять функционал и кастомизировать его.

В этом июне мне посчастливилось реализовать на базе Битрикс24 один очень интересный кейс, о котором я хочу рассказать в этом посте.

Я думаю, большинству читателей моего блога известно, что такое сделки в Битрикс24, что такое статусы сделок и как можно повесить выполнение определенного бизнес-процесса на переход сделки в определенный статус. Это достаточно тривиальная задача. Мои же клиенты захотели, чтобы каждый продукт в сделке так же обладал своим собственным статусом (состоянием готовности), чтобы набор возможных статусов настраивался отдельно для каждого продукта и чтобы на переход каждого продукта в каждый статус можно было настроить отдельный бизнес-процесс. Все это удалось реализовать за очень короткий срок, не отступая от "золотых правил" разработки под Битрикс.

Стандартными средствами Битрикс24 продукту было добавлено множественное свойство "Возможные статусы":



После этого я кастомизировала компонент формы редактирования продукта в каталоге, для того, чтобы каждому продукту можно было задавать свой набор статусов и ставить каждому статусу в соответсвие бизнес-процесс из раздела Сервисы - Бизнес-процессы:



Для хранения привязки бизнес-процесса к статусу товара использовано служебное поле Описания значения свойства инфоблока:



Далее был кастомизирован шаблон компонента отображения продуктов сделки - был добавлен вывод статуса для каждого продукта сделки в виде статус-бара.



С этой частью пришлось повозиться больше всего.

Для хранения привязки стейджа к продукту и владельцу (а владельцем может быть не только сделка) был заведен отдельный хайлоадблок:



При нажатии на любой стейдж (статус) в статус-баре продукт данной сделки во-первых переводится в соответствующий статус, во вторых запускается соответствующий статусу бизнесс-процесс. Для этого был написан скрипт, который запускается по аяксу по клику на стейдж, в-третьих между процессами передаются некоторые переменные. Не буду приводить его целиком - покажу только интересные моменты

Первым делом получаем список доступных стейджей для продукта (по ID продукта) и текущий стейдж в хайлоадблоке состояний продуктов, если стейдж уже и так последний - ничего не делаем//если стейдж не последний - находим тот, в который нам нужно перевести продукт. Сохранение стейджа продукта - это апдейт или добавление элемента в хайлоадблок состояний. Интересное начнается при запуске соответсвуюещего БП
CModule::IncludeModule('bizproc');

//В $UF_STAGE у нас порядковый номер текущего стейджа (порядковый в разрезе продукта)
$BP_ID = $arStagesProperty['DESCRIPTION'][$UF_STAGE]; 
$STAGE_NAME = $arStagesProperty['VALUE'][$UF_STAGE];
$STAGE_ID=$arStagesProperty['PROPERTY_VALUE_ID'][$UF_STAGE]; 
//В $arIB заранее собрана привязка информационных блоков БП и темплейтов БП (эти ID разные, и разработчики часто их путают)
$IB_ID=$arIB[$BP_ID];

//Далее мы собираем виртуальный документ, над которым будет запущен потом экземпляр БП
//Через свойства этого виртуального документа можно передать все, что нам понадобится на этапе выполнения БП
//эти свойства доступны в свойствах документа при настройке различных активити в дизайнере БП

$documentId = CBPVirtualDocument::CreateDocument(0,array( "IBLOCK_ID" => $IB_ID, "NAME" => "Create Notification", "CREATED_BY" => "user_1",  "PROPERTY_STAGE_ID"=>$STAGE_ID, "PROPERTY_STAGE_NAME"=>$STAGE_NAME, "PROPERTY_DEAL_ID"=>$UF_OWNER, "PROPERTY_PRODUCT_ID"=>$UF_PRODUCT, "PROPERTY_PRODUCT_NAME"=>$UF_PRODUCT_NAME, "PROPERTY_HEAD_TASK_ID"=>$HEAD_TASK_ID,      )     );

 $arErrorsTmp = array();
//Запаскаем нужный БП 
CBPDocument::StartWorkflow($BP_ID,   array("bizproc","CBPVirtualDocument",$documentId),  array(), $arErrorsTmp);
Естественно, для запуска данных БП описанным способом предварительно в админке необходимо добавлять соответсвующие свойства соответсвующему данному бизнес-процессу инфоблоку.




Далее возникла сложность с режимом редактирования списка товаров сделки. Нужно было, чтобы сразу после добавления товара в сделку отображался кликабельный стейдж-бар именно для этого товара. Для этого я написала еще один скрипт для вызова аяксом, который отрисовывает стейдж-бар для определенного продукта.


Некоторые статусы продуктов предполагают, что оператор переводит продукт в данный статус вручную, а в некоторые продукт переходит автоматически по завершении бизнес-процесса другого статуса. То есть по завершении предыдущего БП в таких случаях должен не только запуститься следующий, но и соответсвующий продукт в соответсвующей сделке должен сменить статус. Это было реализовано php-вставкой на уровне соответсвующего БП.



Тут закономерно возникает вопрос (который я задавала и заказчику на этапе внедрения): а почему бы не реализовать это одним большим и сложным БП, к-й переводит продукт от одного статуса к другому. С таким сложным БП ИТ-специалисту заказчика, к-й будет поддерживать проект было бы тяжело работать. А с выбранной реализацией для того, чтобы изменить поведение системы при переводе конкретного продукта в конкретный статус, ИТ-специалисту заказчика нужно сделать простые и понятные действия на уровне дизайнера бизнес-процессов в очень простых и маленьких БП.

php-вставка для перевода продукта из одного стейджа в другой и запуска соответсвующего БП выглядела примерно так же, как и скрипт перевода продукта из одного стейджа в другой, за исключением того, что переменные приходили не из POST-запроса, а из переменных БП и из свойств виртуального документа:
$product_id='{=Document:PROPERTY_PRODUCT_ID}';
$owner_id='{=Document:PROPERTY_DEAL_ID}';
$head_task_id='{=Variable:HEADTASKID_printable}';
Кстати реализация подобного кейса не возможна в облачной версии Битрикс24. Поэтому своим клиентам я рекомендую покупать именно коробочную версию. Ведь в коробке Битрикс24 можно реализовать любые хотелки, и облачная версия в контексте подобных задач - просто ущербна.

Интеграция корпортала Битрикс24 (коробка) с AD: о подводных камнях и о том, как я их обходила

С детства я очень везучий человек - это передо мной не открываются автоматические двери, это я всегда вытягиваю число 13 при любой жеребьевке и это я сажусь на единственный сломанный стул из множества. Поэтому, когда я внедряю какой-либо программный продукт, обстоятельства обязательно складываются так, что всплывают, если не все его "баги" и "фичи", то добрые 90%. Я уже привыкла к этому - и это делает мою жизнь похожей на фильм.

Мое сказочное везение не подвело меня и на моем недавнем внедрении коробки Битрикс24. Внедряла в строительной компании средней величины. Пользователей AD (Active Directory) около 400 человек, и 105 из них являются так же пользователями корпортала, остальным корпортал для работы не нужен.

Как известно, корпортал коробка лицензируется по количеству активных пользователей, поэтому импортировать в портал лишних пользователей было нельзя. Это обстоятельство в корпортативном портале Битрикс24, слава богу, предусмотрено - в настройках AD/LDAP интеграции можно исключить определенные группы пользователей AD из импорта. Исключили, пользователи синхронизировались отлично, однако структура компании построилась не правильно:




Присутствовали пустые департаменты, у пользователей - тесок - перемешались подчиненные, а один отдел был создан 2 раза.

Стала разбираться, вставлять отладочные скрипты, писать в техническую поддержку и даже Юрию Волошину (спасибо ему за оперативные ответы).

Оказалось, что с тесками - известный баг, а у меня - первый такой реальный случай в истории. (Хотя это странно. Полные тески на руководящих должностях - далеко не редкость, особенно, когда они - отец и сын. Когда я работала в одном из подразделений РЖД, у нас там чуть ли не у каждого крупного начальника был сын, названный в честь отца, работающий начальником помельче. Мы обычно называли их между собой "старший" и "младший", но ведь в документах так писать не будешь, поэтому программное обеспечение должно предусматривать такие случаи).

С тесками мы расправились, добавив пробел к имени одного из них на стороне AD.

Дальше - интереснее. Стала я отлаживать скрипт импорта пользователей из AD, и поняла, от куда появляются пустые департаменты. Это департаменты, в которых работают пользователи, которые входят в те группы AD, которые в настройках интеграции записаны в исключения.

Дело в том, что до импорта каждого пользователя под него создается раздел в структуре компании, и только потом, когда пользователь уже непосредственно импортируется происходит проверка на его вхождение в группы - исключения. Этот момент я кастомизировала.

Скопировала скрипт /bitrix/modules/main/admin/user_import.php, переименовала его в user_customimport.php, в скрипте /bitrix/admin/user_import.php подключила свой скрипт вместо стандартного. Глубоко переписывать алгоритм не стала - просто вставила после импорта всех пользователей удаление пустых департаментов:
$arUsersDeps=array();
$rsDepUsers = CUser::GetList(); 
  
while ($arDepUser = $rsDepUsers->Fetch()) 
 {
  $arUsersDeps[]=$arDepUser['WORK_DEPARTMENT'];     
 }
       
$arDepFilter = Array('IBLOCK_ID'=>$ib_id);
$db_Deplist = CIBlockSection::GetList(Array($by=>$order), $arDepFilter, true);
     
$id_section_fd=array();
while($arDepSection = $db_Deplist->Fetch())
 {  
 if (!in_array($arDepSection['NAME'],$arUsersDeps) && $arDepSection['ID']!=773){ 
 $id_section_fd[]=$arDepSection['ID']; 
 }
   
}
    
foreach($id_section_fd as $dep_id){ 
     
 $DB->StartTransaction();
 if(!CIBlockSection::Delete($dep_id))
 {
  $strWarning .= 'Error.';
  $DB->Rollback();
 }
 else
 $DB->Commit();
}
 
Вместо одного отдела ITC упорно создавались 2, сколько мы ни перепроверяли на стороне AD заполненность менеджеров и департаментов для каждого пользователя по всей иерархии. Да. на каком-то этапе мы с админом нашли множество ошибок на стороне AD, но их исправление так и не повлияло на импорт структуры.

Тогда в своем скрипте импорта пользователей я завела класс-наследник

class CLDAPCustom extends CLDAP     {...}
И переопределила функцию GetDepartmentIdForADUser
функция бешеная - нечитабельная, а кроме того - рекурсивная, легче умереть, чем ее отладить, поэтому я просто изменила механизм проверки перед вставкой нового департамента. В оригинале поиск совпадения департамента велся только в определенном поддереве (а искало, как показала отладка, не в том поддереве, почему - так и осталось не ясно). Так как в моей компании все подразделения названы уникальными именами, сделала, чтобы искало совпадение по всей структуре.

В итоге структура департаментов из AD все же импортировалась в том виде, как должна была быть.




На самом деле получилось все равно не так, как было задумано. В компании есть департаменты, в которых нет начальника, а все сотрудники - равноправны и подчиняются напрямую сотруднику другого отдела. Система же в таких случаях "назначает" департаменту случайного руководителя. С этим решили смириться, техподдержка Битрикс пообещала учесть это как пожелание при будущих обновлениях продукта.