Setting Access Rights in 1C:Enterprise (Data Separation Feature)

Alexander Biryukov

28.05.2021 15 min

In the previous article, we've discussed the approaches to separation of rights within the 1C platform. See
https://1c-dn.com/blog/setting-access-rights-in-1c-enterprise-rls-record-level-security/

Now it is time to consider a fascinating platform feature allowing differentiation of user rights without creating a significant impact on the software performance even with large amounts of data. This is the so-called data sharing (or data separation) mechanism. The operation principle for this mechanism is based on the use of special-purpose 1C objects, namely "Common Attributes".

Check this if you want to learn more:
https://1c-dn.com/glossary/common_attribute/
https://1c-dn.com/library/using_common_attributes/


Let me start by explaining how "Common Attributes" differ from usual attributes, e.g., document attributes.
Let's create a new 1C program and immediately go to the Designer. Create a new "Companies" catalog:



Get to "Common Attributes" section and create a common attribute "Company". Specify the "Companies" catalog as an attribute type:



Now our program has common attribute "Company", which means that each catalog, document, or other configuration objects will have a "Company" attribute as well.
Thus, if a developer wants to use the "Company" attribute to the "Invoice" document, it is no longer required to add it specifically to a document. This attribute is already present in the list of document attributes.

Let me illustrate my words with an example. Let's create a document in our program and switch to "Data" tab. Here we have "Standard Attributes" and "Common Attributes" buttons:



As we click "Standard Attributes", we can see a list of standard document attributes. These are the attributes that every document has by default, e.g., Date, Number and so on:



Now, as we click "Common Attributes", we'll see a list of our common attributes. But since these are not predefined, we will see only the "Company" attribute that we've created at the earlier stage:



In order for the "Common Attribute" to be used in our document, it's also necessary to define property of "Use". Let's go back to our common attribute and take a look at its properties. Here we are interested in two of them, "Content" and "Auto-use":



Clicking "Content" button will open a form in which we can specify objects this common attribute should be used for:



Note that for the document, "Use" is set to "Automatic", and the common attribute's "Auto Use" property is set to "Do Not Use". With these settings our common "Company" attribute will not be used in our document.

To enable the common attribute in our document the "Use" document property must be set to "Use":



Also, there is an alternative way to enable common "Company" attribute in the document. For this case, the "Use" property for the document is left unchanged ("Automatic"), and the "Auto-use" property of the common attribute is set to "Use":



The first method is more flexible as it makes it possible to specify where the common attribute is to be used for particular 1C objects. The second method is simpler since in this case the common attribute "Company" will be automatically added to each new 1C object created by the developer, e.g., document or catalog. It is up to a developer to choose a method that better suits the current task the most.

Further in our example, I will use the following settings:



Time to check if we have the new common attribute now. We will create a document form and list document properties:



As you can see, the previously created common attribute "Company" is on the list of available attributes of our document.

"But wait!" you exclaim, "We were supposed to talk about separation of user rights but talking about attributes instead." Don't worry. We are just getting there.

Each "Common Attribute" object has another great "Data separation" property:



By default, this property is set to "Do not use", but if you switch it to "Split", a very interesting will happen!

As we enable splitting for our common attribute "Company," several independent data regions are created in the database. Each of these regions will store data only for one specific organization. Now, on log into the program, a user will not have full access to the Infobase but only the user's area, including documents, catalogs, and other data of the user's organization.

Well, let's put this knowledge to practice. I suggest we expand our program by adding an "Invoice" document with the common attribute "Company". This document will have a tabular section "Products". We will certainly need the "Products" catalog.

And here we will apply our knowledge on data sharing. The "Products" catalog will be common for all organizations, and access to documents will be shared. It means that a user of one organization will not be able to see documents of the other one.

First, we will create a new "Products" catalog:



After that, we need to return to the properties of the common attribute "Company" and configure access for the "Products" catalog. As we have decided earlier, the data on this catalog will be visible to all users, so we do not have to apply any data sharing:



Let's change the document we've previously created. Change its name to "Invoice", add "Products" section to it, and add "Product" and "Quantity" attributes to it:



After making all these settings go back to the properties of the common attribute "Company" and change the "Data separation" property to "Split". A dialog box will appear in which we will be prompted to create session parameters:



Click "Yes", and the system will automatically create two session parameters: "CompanyValue" and "CompanyUse":



The first parameter, "CompanyValue", will store the value of our common attribute and will manage separation of data, or in other words act as a filtering tool. The second parameter, "CompanyUse", is True or False and determines whether data sharing is enabled for the current session. Both parameters will need are to be defined at the start of the program. We will handle it a bit little later.

For now, let's go back to the properties of the common attribute "Company" and check "Usage of split data" parameter:



This can be set to "Independent" or "Independent and shared".

If set to "Independent", the database will permanently remain partitioned, and all users will work in their own areas regardless of any further setting. In this case, it is possible to apply the same identifiers (GUIDs) in different areas within a single database. Please mind that this mode is irreversible.

Since we want the "Products" catalog to be common for all users, this approach does not work for us.

We will opt for "Independent and shared". This mode enables data sharing and allows to specify pieces of information to be globally shared or put in limited access. At that, all object GUIDs will be unique within a single database. As you can see, this is exactly what we need.

Therefore, we will set "Independent and shared" for "Usage of split data" in the common attribute "Company":


The next step will be to create "Users" catalog to store user data. Adding "Company" attribute to the same catalog will enable data sharing between users.


Also, since we want to enable user authorization, we need to create one user role with full rights:


Now let's create some users.


I suggest creating an administrator and two standard users. The administrator will see all documents, while a regular user will see the documents of his/her organization only.


To make things simple, we will assign full rights to all users.

Now is the time to start 1C in dialog mode and fill in "Companies" and "Users" catalogs. By the way, have you noticed we haven't written a single line of source code yet?

So, first, we will add some names to the "Companies" catalog:


then "Users" catalog:


Each user will be assigned to a single company with no access to the other. Also, note that in our example, a user name must match the user name we've entered earlier in the Designer:


Time to add some items to the "Products" catalog:


All we need now is a few settings to make our program work!

Let me remind you that for the data separation to work in the program, it is necessary to set the "CompanyValue" and "CompanyUse" parameters at the start of the system:


To do this we should go back to the Designer and open the session module:


Create a predefined procedure "SessionParametersSetting" in this module:


Finally, let's write a few lines of code:


Procedure SessionParametersSetting(RequiredParameters)


currentUser = Catalogs.Users.FindByDescription(UserName());


If Not currentUser.IsEmpty() Then


     currentCompany = currentUser.Company;

     If Not currentCompany.IsEmpty() Then

          SessionParameters.CompanyValue = currentCompany;

          SessionParameters.CompanyUse = True;


     EndIf;

  EndIf;


EndProcedure


The code is very simple and means that when the system starts, a user is searched for in the "Users" catalog, at that user's name must match the name used for the authorization.

If a user is found and has "Company" specified, the session parameters "CompanyValue" and "CompanyUse" are applied. This is how data sharing is enabled.

Time to check what we got! Let's start 1C on behalf of User1 and add several Invoice documents:




Then let's log in as User2 and open the list of invoices. We can see that the list is empty:


Thus, the documents entered by User1 are not visible to User2.

Let's add some invoices under User2:





Then log in under User1 and recheck the list of available invoices:




As you can see, the list of User1 documents is still limited to ones attributed to the corresponding company.

To complete the experience, let's log into the program under the administrator and see what documents are available here. As you can remember, the administrator does not have the "Company" attribute set, which means that the data sharing is not applied.

So, this is what is available to the administrator:


As you can see, a user with no data sharing enabled can view all documents for all companies.

This is basically it.

We have considered one more way to differentiate user rights in 1C. This method allows developers to flexibly configure the accessibility of objects to users. For example, some objects can be made available to all users (e.g., "Products" catalog), and some others can be set to data sharing mode. As soon as this mode is enabled, the data in these objects will be separated and can be limited to specified users as the case may be.

Also, keep in mind that the examples given in this article are just a tiny portion of exciting and valuable tips to help you create incredible solutions on the 1C platform. Stay tuned!


Be the first to know tips & trick on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.