Доработка системы прав доступа на дела Битрикс24

8 Окт 2018   |   Кейсы

Вступление

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

Среди них есть, например, следующие:

  1. Через REST API Б24, включая возможность создавать собственные REST-приложения;
  2. Через обработчики событий Битрикс24;
  3. С помощью собственных модулей, которые добавят на сайт новые сущности, связанные со стандартными;
  4. Посредством добавления своего контента в уже существующие (системные) области интерфейса (через AddViewContent);
  5. Путём создания собственных типов пользовательских полей (а сами поля новых типов будут выводиться в публичной части стандартным образом);
  6. С помощью подключения к публичной части своего кода JavaScript, который нужным образом повлияет на интерфейсы.

Все эти способы уже являются, можно сказать, стандартными для разработчиков и подробно рассматриваются в вебинарах 1С-Битрикс. Несмотря на то, что они покрывают достаточно большую часть потребностей наших заказчиков, встречаются и задачи, для которых они не подходят (если речь идёт о необходимости более глубокого изменения функций ядра). В нашем случае такой задачей стала необходимость доработать систему битриксовских прав CRM на дела (события: звонки, встречи, визиты, задачи, письма, sms).

Проблема в том, что на момент написания данной статьи никаких отдельных прав на дела в CRM нет. Но реальные бизнес-процессы против такого положения вещей. Сотрудники различных департаментов могут работать с одной и той же компанией, поэтому должны иметь к ней доступ. Но им незачем знать, какие звонки и встречи запланированы у другого отдела. Во-первых, это мешает и отвлекает. А, во-вторых, запланированные дела могут являться конфиденциальной информацией в рамках подразделения (например, если отделы конкурируют между собой). Более того, обычный менеджер должен видеть только те дела, в которых он является ответственным (и, по сути, которые сам и создал)  –  и никакие больше. Всё это подвело нас к осознанию того, что имеющуюся систему прав доступа на дела в Битрикс24 нужно дорабатывать под требования заказчика.

Выбор метода изменений

Хорошо, с задачей мы определились. Но сразу встал вопрос: каким образом мы будем это делать? Из описанных выше способов отчасти подходил лишь вариант с созданием своей собственной сущности (новое дело), повторяющей функционал старой плюс реализующей все необходимые права доступа. Но при том обилии связей, которые есть с делами в CRM, работы в этом случае непочатый край. И это при том, что за проверку прав доступа ответствен вполне определённый метод в классе дел ядра продукта. Нам бы его только переопределить  –  и всё (думали мы).

Но в Битриксе нет штатной возможности унаследовать какой-либо класс ядра, чтобы переопределить в нём то или иное поведение. Ну, то есть унаследовать-то можно, но весь код продукта продолжит работать со старым классом.

Таким образом, к способу, который нам предстояло выбрать, мы выдвигали следующие требования:

  1. Должна быть возможность модифицировать то или иное поведение ядра системы;
  2. Вносимые нами правки должны поддерживать совместимость с системой обновления Битрикс. То есть обновления не должны перетирать наш код. И вообще вероятность того, что после обновлений что-то поломается в нашей части, должна быть минимальной (хотя исключить её на 100% никогда нельзя).

Другими словами, мы хотим поправить/доработать код ядра. Но мы не хотим изменять файлы ядра. Возможно ли это?

Автозагрузка спешит на помощь

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

Один и тот же класс нельзя подключать повторно, так как это приведёт к фатальной ошибке и остановит выполнение кода. Но автозагрузка так и не делает. Поэтому если мы подключаем наш собственный класс, который называется так же, как класс ядра, до того, как происходит первое обращение к нему, то мы подменяем классы на наши, продукт начинает их использовать. И всё бы хорошо, но и тут есть сложность: нам нужно унаследовать класс ядра. А он называется так же, как наш собственный  –  парадокс. И пространства имён не подходят в этом случае.

Подмена кода

К файлам ядра, код в которых мы хотим несколько поправить (как минимум изменив имя класса), можно относиться как к обычному тексту. А это значит, что его можно считывать в переменную, исправлять и исполнять прямо во время выполнения скрипта. И это позволяет нам сделать именно то, что нужно: “исправить” ядро под наши потребности, оставляя его открытым для будущих обновлений. По сути, отделить наш код от кода ядра, при том, что изменения осуществляются.

Весь функционал по подмене кода удалось разместить в отдельном модуле. Другие модули-клиенты лишь сообщают ему, что требуется поменять или расширить, а он выполняет всю “грязную” работу.

Основа наших изменений

Теперь, когда все необходимые инструменты были в нашем арсенале, можно было решать основную задачу  –  доработку прав. В коде старого ядра Битрикс есть класс “\CAllCrmActivity  –  именно в нём осуществляется вся необходимая проверка, которую мы и доработали.

Также в настройках модуля CRM есть управление правами доступа:

При переходе в редактирование прав для конкретной роли CRM мы хотим увидеть примерно следующее:

То есть нам нужно вмешаться как минимум в шаблон компонента, выводящего этот интерфейс. Этого легко можно добиться с подменой $arResult, передающегося в шаблон, по уже описанному нами пути (подмена кода). Файлы ядра при этом, опять же, останутся неизменны. Так мы и поступили.

Как результат  –  администратор CRM получается возможность настраивать права на дела для всех ролей CRM по штатному механизму.

Подводные камни

Когда мы считаем, что задача готова в черновом варианте, мы подвергаем её первому тщательному внутреннему тестированию. И всегда выясняется, что что-то не так, поскольку при изменении функционирования самого низкого уровня работы системы всегда есть место для эффекта бабочки. И нас ждали следующие “сюрпризы”:

  1. Рассылка изменений по делам модулем push&pull осуществляется до проверки прав. Это значит, что если два пользователя открывают одну и ту же карточку компании, каждый из них видит только свои дела. Но как только кто-то изменит дело  –  оно “улетает” в карточку другого пользователя (а видеть его он не должен). И это как минимум странно;
  2. Для кастомизации классов стандартных компонентов (в отличие от классов модулей) требуются дополнительные механизмы, потому что их загрузка осуществляется по иным алгоритмам в ядре. Поэтому дорабатывать компоненты сложнее, чем модули как таковые;
  3. Для того, чтобы права доступа на дела работали, нужно заполнить таблицу “b_crm_entity_perms” для всех имеющихся в базе данных дел, а также поддерживать её в актуальном состоянии. Это можно сделать с помощью API ядра плюс обработчиков событий. А для инициализации прав доступа  –  писать свой скрипт;
  4. При создании нового дела сначала отрабатывает рассылка модуля push&pull, а только потом все обработчики событий (инициализирующие права на дело). Это значит, что факт создания дела могут увидеть те глаза, для которых оно не предназначено;
  5. Может потребоваться не только “сужение” битриксовских прав доступа, но и “расширение” их. Например, вы не можете создавать дела к контактам, компаниям и сделкам, если у вас нет права на их изменение (то есть контактов, компаний и сделок). Но права на дела и права на родительские по отношению к ним объекты, как мы поняли, это разное. Поэтому может потребоваться предоставить пользователю доступ на добавление дел к компаниям, которые он не должен редактировать;
  6. В целях оптимизации производительности Битрикс сохраняет в отдельную таблицу ближайшее дело по компании/контакту/сделке/лиду в отдельную таблицу, чтобы потом показывать его в списке соответствующих элементов. При введении прав доступа на дела ближайшее дело у всех пользователей будет разное (так как каждый видит только то, что ему можно). Соответственно, механизм определения ближайших встреч/звонков требует доработки.
  7. “Свои” дела (с точки зрения прав доступа)  –  это не только те, в которых я ответственный. Но и те, в которых я постановщик, наблюдатель или соисполнитель (в случае задач). Аналогично и с правами “своего отдела”.

Каждая из этих особенностей потребовала дополнительного внимания с нашей стороны. И в результате все из них удалось “победить”.

Агрегация дел в компаниях

Пользователи Битрикс24 могут привязывать свои дела не только к компаниям CRM, но и к контактным лицам. Те же, в свою очередь, тоже привязываются к компаниям. И если, допустим, к компании привязано два контакта, то дела могут быть представлены в трёх местах: в компании, в первом контакте, во втором контакте. И это неудобно, так как хотелось бы, чтобы все дела, относящиеся к компании, были в одном месте  –  её ленте событий.

Поэтому возникла также задача агрегировать, как будто собирать дела по всем контактам одной компании и показывать их в ленте компании (в её карточке):

Конечно, при этом тоже должны учитываться права доступа. Если два сотрудника имеют доступ к двум контактам (каждый к своему), относящимся к единой компании, то в её карточке они должны увидеть только свои дела.

Итоги

Нам удалось доработать систему прав доступа, чтобы разделять права на дела CRM между различными пользователями Битрикс24. Весь функционал обёрнут в отдельный модуль, который работает по принципу “установил и забыл”. Как только он установлен, тут же появляется возможность назначать права на сущность “Дело” в ролях CRM. Это не разработка собственной системы прав доступа, а именно подключение дел к уже существующей в Битриксе системе.

Руководители подразделений получили возможность видеть всю активность по своим подчинённым. А рядовые сотрудники  –  только свои события (встречи, звонки, письма, задачи и пр.). Для удобства всех пользователей, в ленте событий компании стали показываться дела по её контактам.

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

Вернуться к списку
Отправить сообщение