In the 1C Enterprise 8 system, today we will continue to study the rights mechanism and delve further into the RLS mechanism (restricting rights at the record level).
Below we will consider the advantages and disadvantages of this method and consider setting up RLS in 1C Enterprise 8.3 using an example.
1C RLS (Record Level Security) or restriction of rights at the record level- these are user rights in the 1C system, which allows you to divide the rights for users in the context of dynamically changing data.
The most common type of 1C RLS setting is limiting the visibility of the user in the context of organizations or clients (the user sees only "his" data).
The main advantage is the presence of a mechanism in general, the mechanism is quite complex and interesting. Allows you to very finely differentiate user rights - users may not even be aware of the existence of other data in the system.
Disadvantages of 1C 8 RLS
Among the shortcomings can be noted a noticeable drop in system performance. This is due to the fact that the platform, when building a query in the database, complicates any developer's request with additional conditions.
Also among the disadvantages are the complexity of setting up this functionality and the complexity of debugging. 1C has released very little material on setting up and operating this functionality. It is difficult enough to find a specialist who would correctly configure the mechanism.
Setting up restriction of rights at the level of 1C RLS records
Record Level Restriction (RLS) is applied to restrict the following types of rights:
- Reading
- Adding
- The change
- Deleting
Get 267 1C video tutorials for free:
Externally, setting up RLS (record-level rights) is similar to composing a simple one. An example of a template for restricting access to visibility of documents by client from the document header:
## If & UseAccessLevelLevel Restrictions ## Then
CurrentTable FROM # CurrentTable AS CurrentTable
LEFT JOINT (SELECT DIFFERENT
Group Composition.Link AS User Group
FROM
Reference.GroupsUsers.UsersGroups AS CompositionGroups
WHERE
Group Membership.User = & CurrentUser) AS Usergroups
SOFTWARE (& UseAccessLevelLevel Restrictions)
WHERE (& UseRecordLevelAccessLevel = FALSE
OR (NOT 1 V
(SELECT FIRST 1
1 AS Picking Field
FROM
Information Register.Assignment of AccessObjectViews AS Assignment ofAccessObjectViews
WHERE
AccessObjectViews.UserGroup = UserGroups.UserGroup
AND CHOICE
WHENAccessObjectView.AccessObjectView Assignment = VALUE (Enumeration.AccessObjectView.Contractors)
AND CurrentTable. # Parameter (1) REFERENCE Directory.Contractors
AND NOT CurrentTable. # Parameter (1) = VALUE (Directory.Contractors.EmptyLink)
THEN CHOICE
WHEN 1 IN
(SELECT FIRST 1
1
FROM
Directory.Contractors AS Contractors INTERNAL CONNECTION Information Register.User Access Rights Settings AS User Access Rights Settings
ON
UserAccess Settings.AccessObject = Contractors.ContractorAccessGroup
And UserAccessObject.AccessObjectView = VALUE (Enumeration.AccessObjectTypes.Contractors)
And (UserAccessPrintSettings.User = AssignmentViewsAccessObject.UserGroup
OR UserAccess Settings.User = VALUE (Reference.UserGroups.AllUsers))
And UserAccess Settings.Write = TRUE
WHERE
Contractors.Ref = CurrentTable. # Parameter (1))
THEN TRUE
ELSE FALSE
THE END
OTHERWISE TRUE
END = FALSE))
AND NOT Usergroups.UserGroup IS NULL)
## EndIf
Basically, this query is added every time you query the #CurrentTable. From which one can imagine what additional load the restriction mechanism at the record level carries.
As you can see, there are special parameters in the query, for example "& UseRemainsAccessLevelRecordLevel". These parameters in the radar are selected from the metadata objects - "". As a rule, they are set at the start of a user session.
Data Access Restriction Constructor
For the convenience of the developer, 1C 8.3 has a special utility to help you configure the radar - the Data Access Restriction Constructor. It is called from the "Access restriction" field. As follows:
RLS- this is the developer's ability to set a condition on the database tables for certain users (user groups) and not let them see too much. The condition is of boolean type. If the condition value is "true", then access is granted, otherwise it is denied.
RLS is used at the same time as setting normal access rights. Therefore, before you start configuring RLS, you need to grant normal rights to the configuration objects.
RLS applies to the following types of access rights:
- Reading
- Adding
- The change
- Deleting
RLS Configuration Procedure
Let's look at a simple example of how to perform customization. Screenshots were taken on 1C Enterprise 8.2 (8.2.9.356). The syntax of constraint text templates is described in the documentation for 8.2 in the book "Developer's Guide. Part 1 ”, so we will not dwell on it.
So, the first step is to define constraint templates for each existing role.
After that, based on the specified templates, constraints to the required objects are set. To edit the text of a condition, you can use the Data Access Restriction Designer.
To edit multiple roles, it is convenient to manage through the "All Roles" window.
You can use the All Access Restrictions window to copy conditions to other roles. Templates to other roles can only be copied manually.
That's all. You can check the result.
Disadvantages of using RLS:
- The use of a record-level access restriction mechanism leads to an implicit increase in the tables participating in the query, which can lead to errors in the client-server mode of the database.
- For write control, it can be difficult or impossible to implement complex application logic. In such cases, it is better to use conditions in the OnRecord () procedure.
- Writing a condition (request) requires a certain qualification of the developer.
- Additional difficulties can be created by the impossibility of debugging a condition (query).
In typical configurations, the rights at the record level can be set interactively for the following objects: organizations, business partners, items, warehouses, departments, individuals, applications of candidates, and others.
It should be remembered that restrictions on access rights at the level of records are quite resource-intensive mechanism and the more complex restrictions you set, the slower the program will work, especially with a large database.
All settings of user rights that will be made by us within the framework of this article are located in section 1C 8.3 "Administration" - "Settings of users and rights". This algorithm is similar in most managed form configurations. As an example, the 1C Accounting program will be used, but setting the rights in other programs (1C UT 11, 1C ZUP 3, 1C ERP) is done in exactly the same way.
Let's go to the "Users" section of the settings window. Here we see two hyperlinks: "Users" and "Login Settings". The first of them allows you to go directly to the list of users of this infobase. Before creating a new user, let's consider the possible login settings (hyperlink on the right).
In this form of settings, you can configure the password complexity (at least 7 characters, the required content of various types of characters, etc.). Here you can also specify the length of the password, its expiration date and the prohibition of entering the program for users who have had no activity for a certain period of time.
Now you can go directly to adding a new user to 1C. This can be done by clicking the "Create" button, as shown in the image below.
First of all, we will indicate the full name - "Antonov Dmitry Petrovich", and select an individual from the corresponding directory. Here you can also indicate the department in which our employee works.
The login name "AntonovDP" was substituted automatically, as an abbreviation for the full name "Antonov Dmitry Petrovich". Let's set a password and 1C Enterprise authentication. Here you can also indicate whether this user can change the password on his own.
Let's say we want Dmitry Petrovich Antonov to be available in the selection list when starting this infobase. To do this, set the flag on the item "Show in the selection list". As a result, the authorization window when starting the program will look as shown in the figure below.
Let's pay attention to one more important setting in the user guide card - "Entry to the program is allowed". If the lag is not set, then the user simply will not be able to enter this infobase.
Access rights
After filling in all the data in the user's card - Dmitry Petrovich Antonov, we will write them down and proceed to setting up access rights, as shown in the figure below.
A list of access profiles previously entered into the program has opened before us. Let's check the necessary boxes.
Access group profiles
Access group profiles can be configured from the main form for setting users and rights. Go to the "Access Groups" section and click on the "Access Group Profiles" hyperlink.
Let's create a new group from the opened list form. In the tabular section, on the "Permitted actions (roles)" tab, checkboxes should be used to mark the roles that will affect the access rights of users included in the group we are creating. All these roles are created and configured in the configurator. They cannot be changed from user mode or new ones created. You can only choose from the existing list.
RLS: Record Level Access Restriction
Allows more flexible customization of access to program data in certain sections. To activate it, set the flag on the item of the same name in the form for setting up users and rights.
Please note that enabling this setting may negatively affect system performance. The point is that the RLS mechanism changes all requests depending on the established restrictions.
Let's go to the "Test group" access group profile we created earlier. The figure below shows that after enabling access restriction at the record level, an additional tab "Access Restrictions" appeared.
Suppose we want the users assigned to the test group to have access to data for all organizations in this infobase, except for those specified in the profile.
In the upper tabular section, we will set the access restriction by organization. In the lower part, we will clarify that access will not be provided to data (documents, directories, etc.) for the organization "Horns LLC".
The eighth version of the 1C: Enterprise platform (today 8.3) carried many changes in relation to the "seven", among which the mechanism for restricting access rights at the record level stood out. Although you can, in theory, do without it, using only roles, RLS allows you to achieve more fine-tuning of access. But for the correct operation of this mechanism, you need to clearly understand its essence and have sufficient experience in development in 1C.
What is RLS?
The essence of this functionality is the developer's ability to prevent a certain user or group of users from accessing tables or fields of database tables. Typically, restrictions are used to prevent 1C users from seeing and editing confidential, secret information, for example, to restrict employees of a company belonging to a group by viewing documents only for their organization. Also, the mechanism for restricting access rights at the record level can be used to remove unnecessary information from the interface.
To be able to write requests for RLS restrictions, you need to create a role or take an existing one. RLS setting in 1C 8.3 can be used for the following user actions:
- Adding;
- Reading;
- Removal;
- The change.
In addition to the broadest options for configuring access, RLS also have disadvantages:
- Requirements for the developer's qualifications, since the request will have to be written in an embedded language, taking into account the syntax rules;
- Inability to quickly debug the condition;
- Limited possibilities for describing the logic: too complex conditions will still have to be written in the modules of documents and reference books;
- In the client-server version of the databases, the implicit growth of the tables included in the query is possible. Moreover, it is very difficult to track this process;
- Resource requirements. RLS restrictions consume a lot of client and server power;
- Scarce documentation in the public domain.
Reports can become another problem that may arise after setting up 1C RLS. The fact is that the developers provide for possible RLS restrictions and build reports in such a way that they show only permitted data. If users have different RLS restrictions configured, then the data in the report for the same parameters may be different for them. This can be questionable, so be aware of these situations when designing reports or writing queries in RLS.
Create an RLS constraint
To add an RLS restriction, you need to find the required role and double-click it to open it.
The window that opens contains 2 tabs: "Rights" and "Templates of restrictions". To impose certain restrictions on a specific action, you must select it and click on the green plus in the lower right part. A line will appear in which we can set the restrictions of 1C RLS in the language built into 1C.
If you know the 1C syntax (like the back of your hand), then you can write directly in the "Access restriction" field. 1C developers have provided for the ability to open a query designer, which will help and tell you what the restriction can be applied to. To open it, you need to click on the button with three dots (Select) or F4 and a window with the "Query constructor ..." button will appear.
In the window that appears, you can configure restrictions not only for this reference book, but also for other objects of the system. To do this, add them on the "Tables and Fields" tab. We register the restrictions on the fields of the "Nomenclature" reference book and click on "OK". Pay attention to the names of the variables: RLS parameters are set at the start of a user session and must be contained in the metadata object.
On the "Restriction templates" tab, you can set the requests that are necessary when copying the same RLS settings in 1C 8.3. After you have added your template, you can refer to its name in the access rights settings.
It is also possible to simultaneously add restrictions on several roles. To do this, in the configuration tree, right-click on the "Roles" section and select "All roles".
As a conclusion, I would like to note that this article is aimed at consultants-developers of 1C and can help, first of all, those who already had experience in development on 1C: Enterprise. Despite the seeming simplicity, knowledge of the semantics and understanding of the structure of business processes of your own enterprise or the customer's organization for the correct distribution of rights require a certain level of knowledge and experience.
The 1C: Enterprise 8 platform has a built-in mechanism for restricting access to data at the record level. You can read general information about it here. In short, RLS will allow you to restrict access to data according to certain conditions for field values. For example, you can restrict users' access to documents depending on the value of the "Organization" attribute. Some users will work with documents for the "Management Company" organization, and the rest with the "Dairy Plant" organization. As an example.
Training
The example is implemented in the demo configuration of the SCP 1.3. Let's create the "Storekeeper" user and add the "Storekeeper" role of the same name to it.
Now let's proceed directly to setting up permissions at the record level. Let's switch to the "User Administration" interface. In the main menu, select "Record Level Access -> Options". Here we mark the checkbox "Restrict access at the record level by types of objects", and in the list of objects select "Organizations".
Thus, we have enabled the use of RLS. Now you need to configure it.
Access control at the record level is not configured separately for each user or authorization profile. RLS is configured for user groups. Add a new user group, let's name it "Storekeepers"
The composition of the group on the right of the form shows a list of users belonging to this group. Let's add the user we created earlier. On the left is a table of access restrictions. In the RLS setup, we have chosen that access will be limited to organizations only, so we see only one type of access object. Click on the "Access Settings" button. Processing of setting access rights for the current group will open.
In the list of access objects for the group, add the organization "IPP" Entrepreneur "". We will leave the type of rights inheritance unchanged. Let's set the right to the access object for reading and writing. Click "OK", the settings are ready. We have just configured RLS at the organization level.
What the user sees
Let's start the program under the user created earlier and open the "Organizations" directory. This is how the list will look for our user and for a user with full rights:
As we can see, the storekeeper user sees only one organization for which we have opened read access. The same applies to documents, for example, receipts of goods and services.
Thus, the user will not only not see the organizations, access to which is not set for him, but also will not be able to read / write documents and other objects in the infobase, to which the rights are set in the role for the "Organization" variable.
We have covered the simplest example of setting up RLS. In the next article, we will talk about the implementation of the RLS mechanism in the Factory Management configuration version 1.3.
