Мое сказочное везение не подвело меня и на моем недавнем внедрении коробки Битрикс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 все же импортировалась в том виде, как должна была быть.
