Разграничение прав доступа на дела в Битрикс24.

ООО "КОМЕК МАШИНЕРИ" - официальный дистрибьютор надежного и качественного оборудования для горнодобывающей, строительной, нефтегазовой, лесной, дорожной и коммунальной отраслей. Компания КОМЕК 20 лет оказывает клиентам всестороннюю поддержку, предоставляет сервис по высоким стандартам премиальных брендов и решает большинство технических задач клиентов. Создана обширная сеть филиалов, представительств и дилеров более чем в 20 городах России. В штате компании 400 высококвалифицированных специалистов.

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

Доработали систему прав доступа, создав отдельный модуль. После его установки появляется возможность назначать права на сущность "Дело" в ролях CRM. Это не разработка собственной системы прав доступа, а именно подключение дел к существующей в Битрикс24 системе прав.

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

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

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

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

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

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

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

• →Через REST API Б24, включая возможность создавать собственные REST-приложения;
• →Через обработчики событий Битрикс24;
• →С помощью собственных модулей, которые добавят на сайт новые сущности, связанные со стандартными;
• →Посредством добавления своего контента в уже существующие (системные) области интерфейса (через AddViewContent);
• →Путём создания собственных типов пользовательских полей (а сами поля новых типов будут выводиться в публичной части стандартным образом);
• →С помощью подключения к публичной части своего кода JavaScript, который нужным образом повлияет на интерфейсы.
• →Должна быть возможность модифицировать то или иное поведение ядра системы;
• →Вносимые нами правки должны поддерживать совместимость с системой обновления Битрикс. То есть обновления не должны перетирать наш код. И вообще вероятность того, что после обновлений что-то поломается в нашей части, должна быть минимальной (хотя исключить её на 100% никогда нельзя).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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