Обзор модуля

Данные

С точки зрения данных, rpa - это те же универсальные списки, только с пользовательскими полями ядра в качестве свойств.

Механизм хранения значений пользовательских свойств похож на такой же в highloadblock (таблицы элементов).

В модуле можно создавать процессы и элементы этих процессов. Каждый процесс имеет набор связанных с ним пользовательских полей, а также набор стадий.

Почти всё взаимодействие с данными в модуле идёт через orm-объекты:

• Bitrix\Rpa\Model\Type
• Bitrix\Rpa\Model\Stage
• Bitrix\Rpa\Model\Item
• Bitrix\Rpa\Model\ItemHistory
• Bitrix\Rpa\Model\Timeline

Интерфейс

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

Т.к. код из crm включать в rpa было нельзя, то некоторые элементы интерфейса были перенесены из crm, переработаны и переписаны на ES6. После этого часть из них переехала в ui (ui.stageflow, ui.timeline, ui.userfieldfactory, ui.userfield).

Подробнее про интерфейс rpa можно почитать тут.

Бизнес-логика

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

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

Всё остальное настраивается через роботы и бизнес-процессы.

Права доступа

Механика ограничения прав доступа на момент написания этой статьи до конца не была проработана. Код написан, права проверяются, но пока что нет гибких настроек.

Если пользователь является администратором, то он может делать все операции, независимо от настроек.

На данный момент есть следующие виды действий:

• создание процессов (могут все). При создании процесса по умолчанию все имеют к нему полный доступ;
• изменение процесса (изменить поля процесса, изменить пользовательские поля элементов процесса, изменение стадий процесса) - настраивается в форме настроек процесса;
• удаление процесса. Совпадает с настройками на изменение процесса;
• просмотр процесса (могут все).

• все действия над стадиями привязаны к действию изменения процесса.

• создание элементов - настраивается в форме редактирования процесса;
• изменение элементов - все, кто может добавлять элементы, могут изменять любые элементы;
• удаление элементов - аналогично изменению.

• все, кто имеют право на просмотр элемента, могут добавлять комментарии в ленту
• изменить или удалить комментарий может только его автор

Подробнее можно почитать в описании класса Bitrix\Rpa\UserPermissions.

Роутинг

В rpa есть только одна публичная страница, весь дальнейший роутинг осуществляется внутри модуля.

Схема похожа на работу со ссылками в Symfony. Есть массив с шаблонами ссылок, где ключ - это имя компонента.

Класс Bitrix\Rpa\UrlManager преобразует адреса в имена компонентов и наоборот. Само подключение компонентов происходит в компоненте-обертке rpa.router.

Шаблоны ссылок передаются в rpa.manager, у которого есть набор именованных методов для получения ссылок на ту или иную страницу.

Пуши

Модуль рассылает достаточно много пушей о происходящих действиях.

Некоторые пуши объединены в группы. Например, пуш изменения элемента уходит по его тегу, также по тегу канбана процесса этого элемента

Каждое действие рассылает пуши всем пользователям. Таким образом, даже тот, кто произвел действие, получит пуш об этом.

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

Чтобы этого избежать, к каждому действию пользователя на странице (которое было отрисовано), добавляется его уникальный идентификатор.

После получения пуша производится проверка - знает ли страница идентификатор этого пуша. И если знает, то этот пуш игнорируется.

Некоторые действия (например, обновление настроек заданий) не отрисовываются на клиенте - в этом случае в пуш не добавляется идентификатор и изменения будут отрисованы после получения пуша.

Подробнее можно посмотреть тут.