From the aspect of data,
rpa has the same universal lists, only with user fields as kernel properties.
Storage mechanism for user field values is similar to the
highloadblock module (elements table).
Almost all interaction with module data is performed via ORM objects:
Large portion of interface elements is sourced partially or fully from kernel/ui.
External appearance was developed with compatibility to
crm, with a few module specifics taken into account.
crm code cannot be included into
rpa, some interface elements were moved from crm, redesigned and rewritten with ES6.
After that, portion of them moved to UI (
Find out more about the
rpa interface here.
The module was designed to not have its own business logic. All business logic is concentrated in automation rules and workflow integrations.
However, it was not possible to absolutely get rid of a custom business logic, but it was maximally isolated from the rest of module code. Several classes were created for this purpose Director and Scenario, which include this logic, when possible.
All the rest can be configured via automation rules and workflows.
At the moment when this article written, access permissions limiting logic hasn't been fully developed yet. The code is written, access permissions handling is being tested, but no flexible settings are available.
When user is an administrator, he can perform all actions independently from settings.
Presently, there are several types of actions:
- creating a process (allowed for all users). All users have access to the process when creating it;
- modifying a process (update process fields, update user fields for process elements, updating process stages) - configuring via process settings;
- deleting a process. The same as with modifying process settings;
- viewing a process (allowed for all users).
- all actions with stages are associated with process update actions.
- creating elements - configured via process editing form;
- modifying the elements - all who can add elements can modify any elements;
- deleting the elements - the same as modifying.
- all who have element viewing permissions can add timeline comments
- only comment author can modify or delete this comment
You can find more in the class description Bitrix\Rpa\UserPermissions.
RPA has only one public page, all further routing is performed inside the module.
General handling is similar to references in
Symfony. Array with reference templates is available, with the key as is the component name.
Class Bitrix\Rpa\UrlManager converts addresses into component names and vice versa.
The component connection itself is performed in the wrapper component
Reference templates are passed to rpa.manager that has set of named methods for getting references to a specific page.
The module sends quite a significant number of pushes about the occurring actions.
Some pushes are united in groups. For example, element updating push is sent by its tag, as well as by this element's process kanban tag
Each action sends pushes to all users. This way, even the user who sent this action, gets a push about it.
In some cases, rendering of performed actions is done for client using JS (for example, moving an element by kanban stages) After action is completed, when receiving the push containing data about the same action, it must be "rendered" again.
To avoid this situation, a unique identifier is added to each user action (that was rendered) on page.
After getting a push, a check is performed whether the page identifies the push ID or not.
Some actions (activity settings update, for example) are not rendered at the client. In this case, ID is not added to the push and all updates will be rendered after receiving the push.
Find more detail [link=11716200]here/link].