Restricting access at the RLS record level. Restricting access to data Restricting access to data 1s 8

RLS- this is the developer’s ability to set conditions on database tables for certain users (user groups) and prevent them from seeing unnecessary things. The condition is of boolean type. If the condition evaluates to true, then access is granted, otherwise it is denied.

RLS is used simultaneously with setting normal access rights. Therefore, before starting setting up RLS, you need to assign normal rights to configuration objects.

RLS is used for the following types of access rights:

• Reading
• Addition
• Change
• Removal

How to configure RLS

Let's look at a simple example of how to configure it. Screenshots were taken on version 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 won’t dwell on it.

So, the first step is to define constraint templates for each existing role.

After this, based on the specified templates, restrictions are set on the necessary objects. To edit the text of a condition, you can use the data access restrictions 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 can only be copied manually to other roles.

That's all. You can check the result.

Disadvantages of using RLS:

1. The use of an access restriction mechanism at the record level 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.
2. It may be difficult or impossible to implement complex application logic for write control. In such cases, it is better to use conditions in the OnWrite() procedure.
3. Writing a condition (query) requires certain qualifications of the developer.
4. Additional difficulties can be created by the inability to debug a condition (query).

In typical configurations, rights at the record level can be set interactively for the following objects: organizations, counterparties, items, warehouses, divisions, individuals, candidate applications and others.

It should be remembered that access rights restrictions at the record level are a rather resource-intensive mechanism, and the more complex restrictions you set, the slower the program will work, especially with a large database.

There is often a need to partially restrict access to data. For example, when a user should see documents only from his organization. In such cases, 1C uses a mechanism for restricting access at the record level (the so-called RLS - Record Level Securiy).

For example, let's assume that we are faced with the following task. The enterprise maintains multi-company accounting and each counterparty and database user belongs to a specific organization. It is necessary to provide access to the “Counterparties” directory in such a way that each user can view, edit and add contractors only for his organization.

To solve the problem we will use the 1C:Enterprise 8.2 platform. Let's create new configuration in the properties of which the “Managed application” option will be selected as the main launch mode.

Next, we will create a directory “Organizations” and two more directories – “Counterparties” and “Users” with the requisite “Organization”. In addition to directories, we will need two session parameters – “Organization” and “User” (of appropriate types). The values ​​of these parameters are set when a configuration session starts and are stored until it ends. It is the values ​​of these parameters that we will use when adding access restriction conditions at the record level.

Setting session parameters is performed in a special module – “Session Module”

In this module we will describe the predefined procedure “Setting Session Parameters” in which we will call the function of the previously prepared general module “Full Rights”. This is necessary due to the peculiarities of the database operating in managed application mode, when part of the program code can only be executed on the server side (I will not dwell on explaining these principles in detail in this article).

Code 1C v 8.x Procedure Setting Session Parameters (Required Parameters)
FullPermissions.SetSessionParameters();
End of Procedure

In the properties of the “Full Rights” module, you must check the “Server”, “Call server” and “Privileged” checkboxes (the latter means that the procedures and functions of this module will be executed without access rights control). The module text will look like this:

Code 1C v 8.x Function DetermineCurrentUser()
TechUser = Directories.Users.FindByName(UserName(), True);
Return TechUser;
EndFunction

Procedure SetSessionParameters() Export
CurrentUser = DefineCurrentUser();
CurrentOrganization = Directories.Organizations.EmptyLink();
If ValueFilled(CurrentUser) Then
CurrentOrganization = CurrentUser.Organization;
endIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
End of Procedure

FunctionSessionParameterSet(ParameterName) Export
Return ValueFilled(SessionParameters[ParameterName]);
EndFunction

Function RoleAvailable to User(RoleName) Export
return RoleAvailable(RoleName);
EndFunction

In the managed application module, we will check for the presence of a configuration user in the “Users” directory (for simplicity, we will search for it by name) and shut down the system if it is not found. This is necessary to ensure that the session parameters are filled in.

Code 1C v 8.x Procedure Before Starting the System (Failure)
// we will check everyone except the administrator for presence in the "Users" directory
If Not FullRights.RoleAvailableToUser("FullRights") Then
If NOT FullRights.SessionParameterSet("User") Then
Warning("User """ + UserName() + """ not found in the directory!");
Refuse = True;
Return;
endIf;
endIf;
End of Procedure

Now we can move directly to the description of access restrictions. To do this, create the “User” role and go to the “Restriction Templates” tab, where we add a new template “AccountsReadingChange” with the following template text: WHERE Organization =Organization #Parameter(1)

Constraint pattern text is an extension of the query language. Unlike a regular request, the text of the restriction must necessarily contain the “WHERE” condition. The values ​​of the session parameters of the same name are used as the values ​​of the request parameters (in our case, “&Organization”). A construction like #Parameter(1) means that in this place the system will substitute the text passed as the first parameter where the template is used. Using the template provided, each table entry will be checked (in our case, this will be the “Counterparties” directory). For records whose “Organization” attribute value matches that specified in the corresponding session parameter, the condition described in the template will be met. This way, these records will be available for reading, editing or adding (depending on which of these rights the template applies to). I will demonstrate the above using our example.

Let’s go to the “Rights” tab of the “User” role and open the list of rights in the “Counterparties” directory. We will use the “AccountsReadingChange” restriction template for the “Reading”, “Changing” and “Adding” rights.

For the “Read” right, we will use a template with the “OR ThisGroup” parameter. In this case, users of this role will be allowed to read not only elements of the “Accounts” directory of their organization, but also all groups of this directory.

#CounterpartiesReadChange("OR ThisGroup")

Since when adding new directory elements, the system implicitly reads predefined details (this is necessary, for example, for numbering), it is necessary to ensure unhindered reading of these fields. To do this, add an additional line with empty restriction text to the data access restriction table and list the fields for which it is valid this rule– Reference, Data Version, Parent, Code.

Thus, the task of restricting access at the record level has been solved. Users with existing restrictions will only have access to view and edit data for their organization.

A role is a metadata object that determines which object and what actions a particular user can perform on this object. Each role contains rights and depending on what rights the database administrator sets, access restrictions will occur. The technology platform provides two types of rights: basic and interactive. By basic we mean the rights to Read, Modify, Add and Delete. Interactive ones are carried out only when performing operations such as editing or deleting in the form: Interactive deletion, Interactive adding and others.

In this way, you can once and for all enable access to a particular directory, document and other metadata object, and in its entirety. You can give access or take away. You won't be able to give a little. But a situation often arises when, for example, there is a huge directory and each user should see only certain elements in it. That is, according to some specific condition, the selection of object elements must occur! And starting with the version of the 1C 8.1 technology platform, a very powerful mechanism for restricting access to data at the record level called RLS (Record Level Security) appeared. Restrictions are a set of specific conditions that, if met, will grant access or not.

Access restrictions when using a dynamic RLS system apply to the basic operations: Read, Modify, Add, and Delete. An important feature is that the Read operation can have multiple record-level constraints applied, while all other operations can only have one condition. This mechanism allows you to impose restrictions not only on certain records, but also on certain fields of records. At what point you may need to specify a field, as well as a special field<Прочие поля>.

RLS syntax and language

Data Constraint Language is nothing more than a query language, but very much stripped down. If the condition evaluates to TRUE, then the current user is granted access to the data, if FALSE, then denial. What are the main differences from a full-fledged query language?

There is always only one data table present in an RLS query and it is actually used for conditions.
Only the FROM and WHERE constructions are used.
In such circumstances, you can specify functional options and session parameters as query parameters.
The use of virtual tables is not allowed.
It is possible to use templates to create restrictions
The TOTAL and IN HIERARCHY operators are not applicable.

Consider how to create restrictions. for example in Fig. 1 shows the simplest limitation. It consists in the fact that the user will see only one counterparty with a specific name “Sibirskaya Korona LLC”. You can filter by a specific field. For example, we want the user to see only contractors that are located in the parent folder “Employees”.

The restriction text can be entered manually, or can also be entered using the usual query builder. The query designer in this case will also not be complete, but will be endowed with restrictions for RLS. You can also pass any & parameters to the constraint request.

How restrictions work

Sometimes, when using RLS, the user may receive an error indicating that they do not have enough rights. This may be due to the way the restrictions operate.

• ALL. That is, in the process of imposing restrictions, the operation is performed on all required database data. However, when reading and changing data, if the restrictions for some records are not met, then an emergency failure occurs due to an access rights violation.
• ALLOWED. A method of operation in which, as a result of imposing restrictions, only those records that satisfy the conditions should be read. In this case, there are no emergency failures. Objects that do not meet the requirements are considered missing.

The ALLOWED method is very often used when forming dynamic lists, otherwise errors about rights violations would constantly appear. The ALL method is used when obtaining objects by built-in language and query functions. Actually, where are these methods installed? The default is ALL.

Using templates in RLS

For more convenient use restrictions in the 1C Enterprise system provide for the use of templates. That is, if you use the same constraint or you know that it will differ only in some parameters, then you create your own template. Thus, you can generally design the repeating constraint code as a procedure. The template has a name and text. The text contains the program code of restrictions, in it, as in a procedure, you can use parameters, and the parameters are highlighted with the prefix #.

Consider the example of the 1C: Accounting 8.2 configuration using built-in templates. Let's open the ACCOUNTANT role and go to the Constraint Templates tab. The template used here is BasicConditionReading the following content:

Where we see #Parameter(1)=UserAccessRightSettings.AccessObject. This is the very parameter that can change depending on the transmitted data. Further, in any place where we want to introduce restrictions, we use the template like this:

That is, instead of

#Parameter(1)=UserAccessRightSettings.AccessObject

in the template text it will appear

Organization=UserAccessRightSettings.AccessObject.

Or on a simpler template. The name of the template #MyLimitations is as follows:

WHERE #Parameter(1) = &CurrentUser

As a result of passing the parameters to the #MyLimitations(“Executor”) template, we get the following

WHERE Executor= &CurrentUser.

Results

The mechanism for restricting access to data at the record level is a very powerful thing, but setting it up requires a lot of experience, since you can easily get lost in this “wild.” Thanks to it, any partial delimitation of data can be made. On the other hand, adding various conditions leads to a drop in system performance, albeit slightly. Since the 1C platform adds additional requests in the form of restrictions to the user’s request. In all other respects, this is just a great thing for developers!

How to configure access rights in 1C 8.3?

In this article we will look at how to work with users in 1C Accounting 8.3:

• create a new user
• configure rights - profiles, roles and access groups
• how to configure rights restriction at the record level (RLS) in 1C 8.3 - for example, by organization

The instructions are suitable not only for the accounting program, but also for many others built on the basis of BSP 2.x: 1C Trade Management 11, Salary and Personnel Management 3.0, ERP 2.0, Small Firm Management and others.

In the 1C program interface, user management is carried out in the “Administration” section, in the “Setting up users and rights” item:

How to create a new user in 1C

To create a new user in 1C Accounting 3.0 and assign him certain access rights, in the “Administration” menu there is a “User and Rights Settings” item. Let's go there:

The list of users is managed in the “Users” section. Here you can create a new user (or group of users), or edit an existing one. Only a user with administrative rights can manage the list of users.

Let’s create a user group called “Accounting”, and there will be two users in it: “Accountant 1” and “Accountant 2”.

To create a group, click the button highlighted in the figure above and enter a name. If there are other users in the information base who are suitable for the role of accountant, you can immediately add them to the group. In our example there are none, so we click “Save and close”.

Now let's create users. Place the cursor on our group and click the “Create” button:

In the full name we will enter “Accountant 1”, and the login name will be set to “Accountant1” (this is what will be displayed when entering the program). The password will be “1”.

Be sure to make sure that the “Login to the program is allowed” and “Show in the selection list” checkboxes are checked, otherwise the user will not see himself during authorization.

Leave “Startup mode” as “Auto”.

Setting up access rights - roles, profiles

Now you need to specify “Access Rights” to this user. But you need to write it down first, otherwise a warning window will appear as shown in the picture above. Click “Record”, then “Access Rights”:

Select the Accountant profile. This profile is standard and configured with the basic rights required by an accountant. Click “Record” and close the window.

In the “User (creation)” window, click “Save and close”. We are also creating a second accountant. We make sure that users are enabled and can work:

It should be noted that the same user can belong to several groups.

We chose access rights for accountants from those that were included in the program by default. But there are situations when it is necessary to add or remove some right. To do this, it is possible to create your own profile with a set of necessary rights access.

Let's go to the "Access Group Profiles" section.

Let's say we need to allow our accountants to view the journal entry.

Creating a profile from scratch is quite labor-intensive, so let’s copy the “Accountant” profile:

And let’s make the necessary changes to it - add the role “View log”:

Let's give the new profile a different name. For example, “Accountant with additions.” And check the “View registration log” checkbox.

Now we need to change the profile of the users we created earlier.

Restricting rights at the recording level in 1C 8.3 (RLS)

Let's figure out what it means to restrict rights at the record level, or as they call it in 1C - RLS (Record Level Security). To get this opportunity, you need to check the appropriate box:

The program will require confirmation of the action and will inform you that such settings can greatly slow down the system. It is often necessary that some users do not see documents of certain organizations. It is precisely for such cases that there is an access setting at the record level.

We go again to the profile management section, double-click on the “Accountant with Additions” profile and go to the “Access Restrictions” tab:

“Access type” select “Organizations”, “Access values” select “All allowed, exceptions are assigned in access groups”. Click “Save and close”.

Now we return to the “Users” section and select, for example, the user “Accountant 1”. Click the “Access Rights” button:

Using the “Add” button, select the organization whose data will be seen by “Accountant 1”.

Note! Using a mechanism for separating rights at the record level can affect the performance of the program as a whole. Note for the programmer: the essence of RLS is that the 1C system adds to each request additional condition, asking for information about whether the user is allowed to read the information.

Other settings

The sections “Copying settings” and “Clearing settings” do not raise any questions; their names speak for themselves. These are settings for the appearance of the program and reports. For example, if you set up a beautiful appearance reference book “Nomenclature” - it can be replicated to other users.

In the "User Settings" section you can change the appearance of the program and make additional settings for ease of use.

The “Allow access to external users” checkbox allows you to add and configure external users. For example, you want to organize an online store based on 1C. The store's customers will be external users. Access rights are configured in the same way as normal users.

Based on materials from: programmist1s.ru

Print (Ctrl+P)

Restricting access to data

The data access restrictions mechanism (also known as RLS, Row Level Security) allows you to manage access rights not only at the level of metadata objects, but also at the level of 1C:Enterprise database objects. To restrict access to data, the following 1C:Enterprise objects can be used:
● roles,
● session parameters,
● functional options,
● privileged common modules,
● keyword ALLOWED in the query language.
Sharing the listed objects allows for maximum flexibility when it is necessary to differentiate access rights to data between users performing different functions.
Data access restrictions can be imposed on the following data operations (access rights): reading (Read right), adding (Add right), modifying (Change right) and deleting (Delete right). The current user will be able to perform the required operation in the following cases:
● For read and delete operations, the object residing in the database must comply with a data access restriction.
● For an add operation, the data access restriction must match the object that you plan to write to the database.
● For a change operation, the data access restriction must match the object both before the change (so that the object is read) and after the change (so that the object is written).
When applying data access restrictions, remember that you can specify only one condition for change, add, and delete operations, but more than one data access restriction can be specified for a read operation. This means that different conditions can be set for reading different fields of an object, and when setting a condition, you can specify both the name of a specific field and the special field Other fields. In the first case, the condition will be imposed only if the selection (which reads the data) contains a field for which the restriction is set, and in the second case, the restriction will be imposed for all fields of the object, except for fields for which restrictions are set explicitly .
When setting a restriction on a specific field, this field will be read if the restriction is satisfied, and when setting a restriction on Other fields, the object data will be read only if the restriction is satisfied for all fields of the object included in the data reading request.
For the following types of database objects, various restrictions can be imposed on different types of changes (adding, modification, deletion):
● Exchange plans,
● Directories,
● Documents,
● Plans types of characteristics,
● Charts of accounts,
● Plans for calculation types,
● Business processes,
● Tasks.
For the following types of database objects, it is possible to impose restrictions on reading not only the entire object, but also its individual fields:
● Exchange plans,
● Directories,
● Documents,
● Document logs,
● Plans for types of characteristics,
● Charts of accounts,
● Plans for calculation types,
● Information registers,
● Business processes,
● Tasks.
ATTENTION! When accessing the fields of database objects using the properties of application objects from the built-in 1C:Enterprise language, the entire object is read, and not just the value of the field being used. The exception is when receiving a view, when only the values ​​of the fields involved in generating the view will be read.
Access restrictions are contained in roles, they can be specified for most metadata objects and are written in a special language that is a subset of the query language.

Data access restriction language

Data access restrictions are described in a special language, which is a subset of the query language ( detailed description query language. The data access restriction language has the following changes relative to the query language:
● In a data access restriction request, there is always one table as a data source - this is the table of the object on which the restriction is applied (the main object of the restriction).
● The request description has been shortened. The data access restriction language uses only the FROM and WHERE sections of the query language. So, the description of the query language looks like this:
SELECT [ALLOWED] [DIFFERENT] [ FIRST<Количество> ]
<List of selection fields>
[FROM <Список источников> ]
[WHERE<Условие отбора> ]
[GROUP BY <Поля группировки> ]
[HAVING<Условие отбора> ]
[FOR CHANGE [ <Список таблиц top level> ]]
While the description of the data access restriction query language is as follows:
[Table alias of the main constraint object]
[FROM <Список источников> ]
[WHERE<Условие отбора> ]

In nested queries used in the data access restriction language, the set of allowed capabilities is limited;
● You can specify session parameters and functional options as condition elements;
● At any point in a data access restriction request, it is permissible to use templates that simplify writing restrictions.
The main part of the constraint is a condition that is evaluated for each record of the database table that is subject to a data access restriction. A record is considered available if, as a result of the operation of the condition for one table record of the main object of the constraint, a non-empty table is obtained (that is, a table with 1 or more records). If the condition results in an empty table, the record for which the condition was met in this way is considered inaccessible. Moreover, changing the table entry of the main constraint object
is considered valid if the entry does not contradict the restriction specified for the right, both before and after the modification operation is performed.

Table fields

In data access restrictions you can use:
● Table fields of the object for which the data access restriction is described.
For example, if a restriction is imposed on reading elements of the Counterparties directory, then the restriction can use the fields of the Counterparties directory and its tabular parts. In particular, the simplest restrictions on reading elements of the Counterparties directory may look like this:

WHERE Name = “Brick Factory”
Or like this:

WHERE Products.Name= “The brick is red”
Where Products are tabular part directory Contractors.
● Fields of tables of objects accessible through links in the main constraint object.
For example, if the Main Manager attribute of the Contractors directory has a link type to the Users directory, then the access restriction may have, for example, the following form:

WHERE MainManager.Code= “Ivanov”
Or:

WHERE Main Manager.Individual.Name= “Petrovsky”
● Fields of object tables associated with the main object of restrictions by certain conditions and expressions over them.
For example, the following restriction may be imposed on reading elements of the Counterparties directory:

Counterparties
FROM
Directory.Counterparties HOW Counterparties
LEFT CONNECTION Directory.Users HOW Users
Software = Users.Name
WHERE = “Petrovsky”
This restriction uses the fields of the Users directory elements associated with this element of the Counterparties directory by the value of the Name fields.

Nested Queries

Nested queries are used to form sets of records that can be used:
● to link to the table of the main constraint object;
● for use as an operand for B or NOT B comparison operations.
Nested queries can use any query language features except:
● operator IN HIERARCHY;
● RESULTS proposals;
● the results of nested queries should not contain tabular parts;
● some virtual tables, in particular Remains and Turnovers.
In the following example of a restriction on reading from the Accounts directory, a subquery is used as a set of records to associate with the main object of the restriction:

Counterparties
FROM
Directory.Counterparties HOW Counterparties
LEFT CONNECTION
(CHOOSE
Users.Name, Users.Individual
FROM
Directory.Users HOW Users
WHERE
Users.Code> “Petechkin”) AS Users
BY Counterparties. Main Manager. Name = Users.Name
WHERE Users.Individual.Name= “Petrovsky”
The following example shows a restriction on reading from the Passport Data of Individuals directory, in which a nested query is used in
as the operand of the comparison operation B:

WHERE
Passport dataIndividual.Individual IN
(SELECT VARIOUS
Workers.Individual AS AN INDIVIDUAL
FROM
Register of Information.Employees AS WORKERS)
If in a nested query it is necessary to obtain data from the tabular part, then in the FROM section of the nested query you must access the tabular part directly. For example, instead of:

SELECT Link AS Link.
Products.Name HOW Name of product
FROM Directory.Counterparties
as a query nested within a constraint, you should use:

Session Options

Data access restriction requests may include session parameters. For example, to read directory elements Email Groups The following access restrictions can be set:

WHERE Owner.AccountAccess.User = &CurrentUser
AND Owner.AccountAccess.Administration= TRUE

CurrentUser is a session parameter

Functional options

Data access restriction requests may include functional options. Only parameter-independent functional options can be used. For example, if the Items directory has the MainWarehouse attribute, then the restriction on reading this attribute may look like this:

WHERE &Warehouse Accounting = TRUE

Where Warehouse Accounting is a functional option

Features of use

Not all fields of the main constraint data object may be used in restrictions on the following types of database objects:
● in accumulation registers, access restrictions can only contain measurements of the main object of the restriction;
● in accounting registers, only balance sheet measurements of the main object of the restriction can be used in restrictions.
NOTE. If, under conditions of limited access to the data of the turnover accumulation register, measurements that are not included in the totals are used, then
When accessing the virtual table of revolutions, the stored totals are not used and the request is performed entirely according to the movement table.

Access restriction actions

Access restrictions are checked whenever appropriate operations are performed on database objects (from dialogs, from the built-in language, through queries) and can act in one of two ways:
● Everything. The “all” method implies that some operation on data (from dialogs, from a built-in language, or through queries) must be performed on all database objects implied by this operation. If such an operation requires reading or modifying database objects for which appropriate access restrictions are not met, the operation is terminated
abnormal due to access violation.
● Permitted. The "allowed" method implies that when performing an operation on data, only those database objects that satisfy the appropriate access restrictions should be read. Database objects that do not satisfy access restrictions are considered missing when performing such an operation and do not affect the result of the operation.
Data access restrictions are imposed on database objects at the time 1C:Enterprise accesses the database. In the client-server version of 1C:Enterprise, restrictions are applied on the 1C:Enterprise server.
The method of operation of the restrictions chosen to perform each operation on data is determined by the purpose of this operation and the degree of responsibility of its results. In particular, the “allowed” method is used when displaying dynamic lists and some other interactive actions. The “all” method is used when performing any operations with application objects from the built-in 1C:Enterprise language, including any changes to database objects. Therefore, for example, difficulties may arise when constructing a selection for the Select() method of managers of directories, documents and others with subsequent bypass of the result if a rather complex restriction is set on the corresponding object, since not every condition in the restriction of access rights can be adequately represented as a selection for the Select() method.
In queries, you can control how data access restrictions operate. For this purpose, the query language provides a keyword ALLOWED. If the request does not specify ALLOWED, then the restrictions apply in the “all” way. If the word ALLOWED is specified, then the “allowed” method is selected.
It is important that if a query does not specify the ALLOWED keyword, then all selections specified in that query must not conflict with any of the read restrictions on the database objects used in the query. Moreover, if the query uses virtual tables, then the corresponding selections must be applied to the virtual tables themselves.
Example:

CHOOSE
ContactInformationSectionFirst.Introduction
FROM RegisterInformation.ContactInformation.SliceLast(, Type = &Type)
HOW ContactInformationSliceFirst
WHERE
ContactInformationSliceFirst.Type = &Type
When using object technology, accessing data in ALLOWED mode is not supported. It is assumed that object technology is used for the most critical operations on data, including changing it. To obtain all data using object technology, regardless of the restrictions set, you can perform the necessary actions in a privileged module or on behalf of a user with full rights. There are no means of obtaining only permitted data in object technology.

Mechanism for imposing restrictions

Any operation on data stored in a database in 1C:Enterprise ultimately leads to access to the database with some
request to read or change data. In the process of executing queries to the database, the internal mechanisms of 1C:Enterprise impose access restrictions. Wherein:
● A list of rights is generated (read, add, change, delete), a list of database tables and a list of fields used by this request.
● Of all roles current user data access restrictions are selected for all rights, tables and fields involved in the request. Moreover, if a role does not contain restrictions on access to the data of a table or field, this means that the values ​​of the required fields from any record are available in this table. In other words, the absence of data access restrictions means the presence of restrictions
WHERE is the Truth.
● Retrieves the current values ​​of all session parameters and functional options involved in the selected restrictions.
To obtain the value of a session parameter, the current user does not need to have permission to obtain that value. However, if the value of some session parameter has not been set, an error will occur and the database query will not be executed.
Receipt of functional options is influenced by the Privileged Mode upon Receipt property of the functional option.
If this property is cleared, then the current user must have read access to the object in which the function option is stored.
● Constraints derived from one role are combined using the AND operation.
● Constraints derived from different roles are combined using an OR operation.
● The constructed conditions are added to the SQL queries with which 1C:Enterprise accesses the DBMS. When accessing data from access restriction conditions, rights check is not performed (neither for metadata objects nor for database objects). Moreover, the mechanism for adding conditions depends on the selected method of operation of the restrictions “all” or “allowed”.
"Everything" method
When imposing restrictions using the “all” method, conditions and fields are added to SQL queries so that 1C:Enterprise can obtain information about whether, during the execution of a database query, data that was prohibited for a given user was used or not. If prohibited data was used, the request will crash. The imposition of access restrictions using the “all” method is schematically presented in Fig. 1:

Rice. 1. “Everything” method

"Allowed" method
When applying restrictions using the “allowed” method, conditions are added to SQL queries so that records that are prohibited for the current user do not affect the result of the query. In other words, when restrictions are imposed in the “allowed” mode, records prohibited for a given user are considered missing, which is schematically presented in Fig. 3

Other objects related to data access restrictions

When designing configurations that use data access restrictions, metadata objects such as session parameters, functional options, and shared modules with a Privileged flag may be useful.
Session Options
Session parameters can be used in data access restrictions in the same way that request parameters can be used in a request.
Functional options
Parameter-independent functional options can be used in data access restrictions in the same way that query parameters can be used in a query.
Privileged Common Modules

If the Privileged flag is selected for a common module, then the execution of procedures and functions of this module acquires important specifics:
● In the client-server version of 1C:Enterprise, only the module that is executed on the server can be privileged.
● Execution of procedures and functions of the privileged module and everything that is called from them is carried out when the restriction system is turned off
rights to both metadata objects and data. Thus, from a privileged module any operation can be performed on
any objects even if the current user does not have the appropriate rights.
Privileged modules are designed to initially set the values ​​of session parameters used in data access restrictions.
More general modules can be used for some holistic actions on data by a user with limited rights.
For example, if the user’s functions include entering and posting documents, but the user should not have access to data that is affected by document posting, then the execution of the posting operation can be moved to a privileged module. This will allow the user to post documents without granting him rights to other information (registers, for example).
Privileged mode
It is possible to programmatically install a privileged mode when working with data. Software installation privileged mode
may be required in case of massive data operations information base, and there is no point in checking data access rights.
For a description of privileged mode, see here.

Using the Preprocessor

When editing the text of data access restrictions, it is possible to use preprocessor instructions. The following instructions are available:

#IF<Выражение>#THEN
#ELSEIF<Выражение>#THEN
#OTHERWISE
#ENDSIF
<Выражение>– arbitrary logical expression in an embedded language whose result is of type Boolean. The expression may contain:
● comparison operations<, >, <=, >= , =, <> ;
● logical operations AND, OR, NOT ;
● session parameters – the syntax &Parameter is used, where Parameter is the name of the session parameter.
If the result of the expression of the #IF or #ELSEIF statement is True, then the resulting text of the access restriction statement contains the text located after the #THEN keyword. If the result of the expression is False, then the text located after the #THEN keyword is not placed in the text of the access restriction statement. The text following the #ELSE statement will be placed in the resulting access restriction text if none of the earlier conditions are met.
NOTE. If the text of a data access restriction contains preprocessor instructions, then such a restriction does not pass syntax checking when editing and cannot be changed using the constructor.
Example:

#IF &CurrentUser<>“Klimova” #THEN
<текст ограничения доступа>
#ENDSIF
Here CurrentUser– session parameter type DirectoryLink.Users.
This design means that the condition for setting an access restriction will be checked for all users from the directory, except for the user Klimova.

Access restriction text templates

A role can contain a list of access restriction templates, which are described on the Restriction Templates tab of the role form. You can also edit access restriction templates in the editor for group editing of access restrictions and templates.
Each access restriction template has a name and text. The template name follows the usual rules for names adopted in the 1C:Enterprise system.
The template text contains part of the text in the data access restriction language and may contain parameters that are highlighted using the symbol
“#”.
After the symbol “#” may follow:
● One of keywords:
● Parameter followed by the number of the parameter in the template in parentheses;
● CurrentTable – indicates insertion into the text of the full name of the table for which the constraint is being built;
● CurrentTableName– denotes insertion into the text of the full name of the table (as a string value, in quotes) to which the instruction is applied, in the current version of the built-in language;
●Name of CurrentAccessRight – contains the name of the right for which the current restriction is applied: READ/ADD/INSERT/CHANGE/
UPDATE, DELETE;
● template parameter name – means insertion of the corresponding template parameter constraint into the text;
● “#” symbol – indicates the insertion of one “#” symbol into the text.

An access restriction expression may contain:

● Access restriction template, which is specified in the format
#TemplateName(“Value of template parameter 1”, “Value of template parameter 2”, ...). Each template parameter is enclosed in double quotes. If it is necessary to specify a symbol parameter in the text double quotes two double quotes should be used.
● Function Page Contains (Where We Are Looking, What We Are Looking For). The function is designed to search for an occurrence of the WhatWeLook string in the WhereWeLook string. Returns True if the occurrence is found and False otherwise.

● The + operator for string concatenation.
To make it easier to edit the template text, on the Restriction templates tab in the role form, click the Set template text button. In the dialog that opens, enter the template text and click OK.
The 1C:Enterprise system checks the syntax of template texts, checks the syntax of using templates, and macro-substitutes the texts of role access restriction templates into the request text.
Macro template substitution is:
● replacing occurrences of parameters in the text of the template with parameter values ​​from the expression for using the template in the text of the constraint;
● replacing the template usage expression in the request text with the resulting template text.
When you call the query constructor for a condition that contains access restriction templates, a warning is issued that all templates will be replaced.
The following are examples of constraint templates:

To flexibly manage user access to data according to functionality when setting data access restrictions, it is recommended
adhere to the following principles:
● It is necessary to select a set of information (may be dependent on the current user) for which preliminary preparation is appropriate. The selected information should, on the one hand, simplify the restrictions on access to data as much as possible, and on the other hand, should not be too large. Distribute it according to session parameters.
● Set the values ​​of session parameters in the SetSessionParameters() handler of the session module.
● Set access restrictions to those data for which this is justified (data is secret or most important for maintaining the integrity of the system). Please be aware that setting access restrictions may slow down any access to this data. Excessive complexity of restrictions can also lead to slowdowns.
● If necessary, ensure that a certain limited number of operations on data are performed by the user who full access It is inappropriate to give this data, move these actions to privileged modules, or explicitly turn on and off the privileged mode in the appropriate places in the program code.
● Data access for various checks performed by the system when writing objects is performed in privileged mode.

This allows you not to disable record-level permission restrictions for the corresponding fields if the configuration works with this data
planned only in controlled mode:

● for directories when checking the parent, owner and uniqueness of the code;
● for documents, business processes and tasks when checking the uniqueness of the number;
● disabled for exchange plans when checking the uniqueness of the code;
● for charts of accounts and charts of characteristic types when checking the parent and the uniqueness of the code.

There are some limitations and considerations to keep in mind when creating a data constraint query:

● If data access restrictions are specified for an object table and a join with such a table is used in the data query, then in the connection condition (software request section) the use of the tabular part of the object with the specified access restriction is not allowed.
● If a query specifies a table for which no fields are used in the query, then all data access restrictions are imposed on this table. For example, request SELECT QUANTITY(*) FROM Directory.Counterparties will be executed taking into account all access restrictions specified for the Test directory. Restrictions are imposed “by OR”. This means that all records that are available under at least one condition will be available. If conditions are not specified for some fields, the query will be executed for all records in the table.
If the query uses a top-level table, then the restrictions specified for the columns of nested tables are not imposed.
If a query uses a nested table, then restrictions apply to both the nested table and the top-level table.
For example, request SELECT QUANTITY(*) FROM Directory.Counterparties.Agreements will be executed taking into account all restrictions for the Counterparties directory, as well as taking into account the restrictions relating to the tabular part of the Agreement.

● If access to the fields required to obtain a representation of the reference metadata object is denied by access restrictions
data or access to the object is denied at the access rights level, then obtaining a representation of such an object does not affect the progress of the current transaction.

Data Access Restriction Constructor

To call the constructor in the Data Access Restrictions table field in the Access Restrictions column, you need to go to edit mode and
Click the select button, and in the form that opens, click the Query Builder… button.
The constructor form is displayed on the screen:

Rice. 3. “Tables and fields” tab of the constraint designer

With its help, conditions are created for setting data access restrictions.
On the Tables and fields tab, select the required objects in the Database list and move them to the Tables list. If several tables are specified, the Links tab is added to the designer form.

Rice. 4. “Links” tab of the constraint designer

On the Links tab, conditions are formed that are imposed on the links between table fields. To enter a new condition, click the Add button and select one of the tables in the Table1 column. In the Table2 column, select the table whose fields are related to the fields of the first one. Below the list of conditions there are controls that can be used to create a condition for linking tables.
If a simple condition type is selected, then in Field1 and Field2 the related fields of the specified tables are selected and the comparison condition is set. If fields are selected that are not compared, then in the line of the list of conditions in the Link condition column the text is displayed: Incorrectly filled condition.
On the Conditions tab, if required, you need to specify the conditions by which the source data will be selected.

Rice. 5. “Conditions” tab of the constraint designer

For each selected field, you must select the type of condition and specify the name of the parameter. The session parameter can be used as a parameter. Multiple conditions are allowed. In this case, in the Condition column of the condition table field, the condition text is displayed in several lines.
At any time during the creation of a request, the request text can be viewed by clicking the Request button.

Batch editing of permission restrictions and templates

The mode for group editing of access rights restrictions and templates is called by the All access restrictions command context menu Raleigh branches. The form that opens contains two tabs: Access restrictions and Restriction templates.

Rice. 6 All permission restrictions and templates

On the bookmark Access restrictions You can view all entered access restrictions in a general list (for all roles, objects, rights, field combinations).
It is possible to add access restrictions for several roles, objects, rights and combinations of roles at once.
You can filter the list by various criteria.

Rice. 7. Selecting access restrictions

The group editing mode allows you to delete restrictions selected in the list.
It is possible to edit selected restrictions. In this case, you can change the composition of the fields and/or access restrictions.
The group editing mode also allows you to copy selected restrictions to other roles.

On the bookmark Constraint Templates you can see all access restriction patterns present in application solution, in this case, only the first 10 lines of the template text itself are displayed in the table, which end with the symbol “...” if the template text is more than 10 lines. The template editing window will display full text template.

Fig 8. All access restriction templates

It is possible to add an access restriction template for several roles at once.