An important difference between EDMS applications and other applications familiar to the user (for example, ERP systems) is that an EDS document is an object with a very complex and long life cycle. For example, a document of the type Contract - is being developed, agreed, approved, transferred to contractors, it is actively working, applications are accumulated, additional artifacts are created, it is archived, written off, etc. Naturally, the logic of its processing and access rights to the document data stage of its processing. But this is not the most difficult.

The fact is that the rules for processing a document at a particular stage in the life cycle of a particular user depend on various parameters: for example, the position of the user in the staff list, the availability of certain data in the document itself (or associated with it), and even information stored in external to the ERMS systems.

Here is an example of such a complex rule that determines the right to make a change in the contents of the contract:

“The contract is available for editing to the head of the department and his deputies, as well as to all employees who are listed in the list of coordinating persons in the contract card, in the event that the task for approval of the document is in the“ in progress ”state,“ the document is not approved ”, and accounting system there is no record of registration of the relevant contract.

For operations with the document can be described a large number of similar rules. This leads to the fact that when creating an application, you have to program the processing logic of the document, taking into account all these factors - the processing stage, the state of the document, the role of the user, the attributes of the document and its associated external factors, etc., which determine the rules for processing the document, the availability of those or other interface elements, the ability to read and modify data.
')
Everything would be fine, but when creating an application in the SED, as a rule, it is not possible to describe the task in general, and with each specific implementation it is necessary to take into account the rules of work and regulations of a specific business process in a particular organization. All this leads to the need to use coding and low-level development in almost every project for the introduction of the SED. And any software improvements are not only a rise in the cost of the project, but also an increase in risks and potential problems in implementing the transition to new versions of the EDMS platform.

To eliminate these problems when implementing EDS applications, Docsvision implements a unique context-role model that allows parametrically adjusting the interface, processing logic and document security for a specific use case without using programming. For this, the Docsvision role designer is used.

It must be said that the traditional notion of “ role ” - for example, the role in the operating system and the role in the context-role model - is different. If a traditional role (for example, the system administrator) is essentially a static group whose members are given certain specific powers in the system (the ability to perform administrative functions), then in Docsvision the role is determined dynamically, in particular with respect to a specific document instance, and not only, access rights to the object, the interface for processing the object and the available business functions for its processing are determined.

Thus, the mechanism of the context-role model Docsvision allows to solve one of the most important problems of modern EDS - optimization and simplification of the user interface when performing certain actions.

Setting up a role model includes three steps:
• Setting up roles (or processing contexts) for a specific type and type of document,
• Definition of document and data processing operations available for a given role,
• Linking one or another interface view configured in the card designer with a specific role and state of the document.
(About the designer of cards and states of Docsvision, see here habrahabr.ru/company/docsvision/blog/263263 ).

Configuring roles for the document view is done in the "Role Designer" interface.

Figure 1. The role designer allows parametrically describing the contexts of using various application objects based on the Docsvision platform.

Setting roles (or processing contexts) for a specific type and type of document

The role designer allows you to describe a variety of roles (usage contexts) for a particular type of document.
Each role is a set of conditions combined in a combination of and / or.
Each condition is a logical expression (parameter – operation – value) that is checked for truth when accessing a specific instance of a document.

It checks the relevance of all roles for the current context (the user is an instance of the document) configured for this type of document. If all (AND) or one (OR) expression is true, this role is updated in the current context. Further, depending on the settings of the card designer, it is determined which interface to show the user in the current context, as well as what data and document operations are available to the user in the current context.

The table contains a list of parameters that define the current context of use.

Parameter	Description
Everything	The condition is set relative to all users.
I	The condition is set relative to the current user.
Head	The condition is set relative to the current user’s manager.
Subordinates	The condition is set relative to the subordinate first level of the current user.
All subordinates	The condition is set relative to all subordinates of the current user.
All subordinates temporarily replaced	The condition is set relative to the Deputy Temporary Head of the current user.
All subordinates are constantly replaced	The condition is set relative to the constantly replaced manager of the current user.
Deputy	The condition is set relative to the current user's substitute.
Substitutable	The condition is set relative to the person whose deputy is the current user.
I am the first active alternate	The condition is set relative to the first active substitute of the current user. The first deputy is the employee who is first listed in the list of deputies in the Employee Directory. This employee must have “Active” status.
I am the first active permanent deputy	The condition is set relative to the first active substitute of the current user. This deputy is considered permanent based on the setting of the Permanent Deputy in the Employee Handbook. This employee must have “Active” status.
I am the first active temporary deputy.	The condition is set relative to the first active substitute of the current user. This deputy is considered temporary due to the fact that the Permanent Deputy parameter in the Staff Directory is not set for it. This employee must have “Active” status.
I am the first active alternate performance	The condition is set relative to the first active substitute of the current user. This status is configured in the Employee Directory.
I - the first active deputy responsible performance	The condition is set relative to the first active assistant of the current user, and the “Responsible Execution” setting is set for the Deputy. This status is configured in the Employee Directory.
I am the first active deputy signature	The condition is set relative to the first active substitute of the current user by the signature. This status is configured in the Employee Directory.
I am a temporary deputy in the period of inactivity of the replaced	The condition is set relative to the first active temporary substitute, but only in the case when the replaced employee is in a state other than “Active”. This deputy is considered temporary due to the fact that the Permanent Deputy parameter in the Staff Directory is not set for it. This employee must have “Active” status.
I am a permanent deputy	The condition is set relative to a permanent substituent, regardless of the activity of the substituent and the substitutable itself. This deputy is considered permanent based on the setting of the Permanent Deputy in the Employee Directory
I am a deputy signature	The condition is set relative to the current user's substitute by the right to sign the document.
Today	The condition is set relative to the current date (excluding the business calendar)
Now	The condition is set relative to the current point in time (excluding the business calendar)
Field	The condition is set relative to some card field

In fact, today there are 3 types of parameters in the system :

• Parameters that define the context of the current user. The simplest example is me = the value of the field of the document, the current user is specified in some field of the document. There are more complex conditions, for example, the current user is a temporary substitute user specified in the field of the card. You can also select not the field of the current document as a value, but the field of the document (or other object) associated with the current one. For example, you can check the condition: I am a temporary deputy of the user specified in the field executor of the task assigned to this document.

• Parameters related to time. Conditions can be associated with the current date and with the current time, for example, to check whether the work time is now and to deny access to a document outside working hours, or to limit the availability of a document for a calendar year.

• Parameters related to the current document data. When you open a document, you can check whether the field value of the document or its associated object matches certain conditions. For example, depending on the amount of the contract, you can give the right to edit it only to users of a particular group.

As with the creation of any visual designer, we are faced with the fact that it is impossible to foresee all situations from real life. Therefore, it was given the opportunity to create an arbitrary condition by connecting a low-level code as a condition. We recommend using this mechanism only to experienced developers, since the execution of role model calculations can have a significant effect on the speed of the solution. This especially concerns the calculation of access rights to documents when displaying tabular views with a large number of documents, for example, the journal of incoming documents for the current year.

Definition of document and data processing operations available for this role.

The second step in setting up the context-role model is to determine the availability of certain data or operations for customized roles.

Figure 2. The role designer allows you to grant permissions to perform certain operations and edit data for various roles.

In this case, one role may have different rights to perform operations with the document in its various states. So, for example, in the example in fig. 2. the operation “Return to preparation” for the incoming document is available to the registrar in the “Registered” state and is not available in the “Preparation” and “In archive” states.
Role model security settings are based on the Docsvision application server. If an operation or data is closed in the context-role model settings, then they are inaccessible not only from the application interface, but also at a low level, when accessed via the API.

Associating an interface view configured in the card designer with a specific role and document status

The final step of the settings is to associate a specific interface of the document configured in the card designer with the role for a particular state of processing the document. This is done in the card design tree.

Figure 3. Card Designer allows you to associate a particular document interface with state and role using the “design tree”.

The described mechanism of the role model allowed us to solve the problem of simple customization of applications developed on the basis of Docsvision to the conditions of a particular organization without significant software improvements .

In the next episode of this series of articles, I will write about the development of directories in the SED, and then about the development of business processes, the navigation and search subsystem, the subsystem of views and reports.