Programmer's notebook. Accounting info Radar limitation

The “role” configuration object gives a set of rights to operations (actions) over configuration objects.

Role "Full Rights".

This is just a role (not predefined) in which all types of rights to all configuration objects are checked.

What distinguishes it from other roles is the presence of the “Administration” right.

If at least one user is created, the system begins to check for the presence of the “Administration” right - at least one user must have it.

Record-level access restrictions

Row Level Security (RLS) – record-level restriction.

The data access restrictions mechanism allows you to manage access rights not only at the level of metadata objects, but also at the level of database objects. The following objects can be used to restrict access to data:

roles,
session parameters,
functional options,
privileged shared modules,
keyword ALLOWED in the query language.

The mechanism is designed to restrict access to metadata object table records based on arbitrary conditions imposed on the values of the row fields of these tables. For example, to see records only for “your” counterparties, organizations, etc.

Technical implementation of access restrictions in 1C

1C generates a request to the DBMS. The server cluster adds a WHERE section to the request, which contains the text of the condition for restricting access via RLS, then this request is sent to the DBMS, the extracted data is returned to the 1C client.

This mechanism will work for any request from the client:

in reports,
in dynamic lists and in regular list forms
in custom queries.

Such an implementation of the mechanism greatly affects performance.

Ways to bypass access restrictions.

In large resource-intensive operations (processing document reposting, for example), part of the code can be moved to privileged modules.

A) Privileged module is a common module with the “Privileged” flag in the properties.

Its peculiarity is that the code in it is executed without any access rights control, including RLS.

B) Also privileged the mode can be turned on for document object modules. This is done in the document properties, flag

Privileged treatment when conducting
Privileged mode when canceling a transaction

B) Method SetPrivilegedMode()

System command allows you to make part of the code of any module privileged.

From the next line of code, the privileged execution mode will operate.

It will operate until the line to disable this mode or until the end of the procedure / function

(True);

// any code here will be executed without rights control and RLS

SetPrivilegedMode(Lie ); // or end of procedure / function

The number of times privileged mode is enabled must match the number of times it is disabled. However, if within a procedure or function the privileged mode was turned on (once or more), but was not turned off, then the system will automatically shutdown as many times as there were incomplete turns on in the procedure or function being left

If in a procedure or function calls a method SetPrivilegedMode(False) made more than method calls SetPrivilegedMode(True ), then an exception will be thrown

Function PrivilegedMode() returns True if privileged mode is still enabled, and False if it is completely disabled. This does not analyze the number of privileged mode settings in a particular function.

All called procedures and functions will also be executed in privileged mode.

It is also possible to start a privileged session. This is a session in which privileged mode is established from the very beginning of the system. Moreover, during operation the method PrivilegedMode() will always return True, and the ability to disable privileged mode is not supported. Only a user who has administrative rights (Administration right) can start a privileged session. The session can be started using the client application launch command line switch UsePrivilegedMode or the infobase connection string parameter prmod .

The question naturally arises: Why then set up access restrictions at all if it can be so easily bypassed?

Safe mode.

Yes, you can write external processing with a privileged execution mode and unload/corrupt data. To prevent this, the system has a global context method

SetSafeMode().

Safe mode, among other things, ignores privileged mode.

It must be installed before programmatically calling external processors or export procedures and functions from their modules.

When performing prohibited operations, an exception is thrown at runtime.

In addition, at the role settings level, you can disable the ability for users to interactively launch external reports and processing.

Setting up access restrictions

RLS can only be configured for rights:

read (select)
adding (insert)
change (update)
delete

For read operations and deletion, an object residing in the database must comply with data access restrictions.

For the add operation The data access restriction must correspond to the object that is planned to be written to the database.

For change operation the data access restriction must comply with the object both before the change (so that the object is read) and after the change (so that the object is written).

For all other rights there is no such option.

Let's add a new restriction for the “read” right of the “Nomenclature” directory. A list of fields for which you can configure the added restriction will open.

This means that if you try to access checked fields, the restriction will be triggered, but if you try to access unchecked fields, the restriction will not work.

If you select the flag " Other fields", the restriction will be configured for all table fields, except for fields for which restrictions are explicitly set.

*Feature: for rights to add, change, delete:

The restriction can only be configured for all fields.

There can be only one limitation.

For the “Read” right, you can configure several conditions; they will be combined with the logical operator “AND”.

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, restrictions can only use balance sheet measurements of the main object of the restriction

If, under conditions of limited access to the data of the circulating 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.

Mechanism for imposing access restrictions.

Any operation on data stored in a database in 1C:Enterprise ultimately leads to a call to the database with some request to read or change the 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, modify, delete), a list of database tables, and a list of fields used by this query.
From all roles of the current user access restrictions are selected to data 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 a restriction on access to data means the presence of a restriction WHERE IS THE TRUE.
Retrieves the current values of all session parameters and functional options participating in the selected restrictions.

To obtain the value of a session parameter or feature option, 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.

Constraints derived from one role are combined using the AND operation.

Constraints derived from different roles are combined using the 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”.

*Feature: If a user has access to several roles with configured restrictions at the record level for one object, then in this case the conditions of the restrictions are added using the logical operation “OR”. In other words, the user's powers are cumulative.

This leads to the following conclusion: do not allow the conditions for restricting access to one object in different roles to intersect, because in this case the text of the request will be greatly complicated and this will affect performance.

"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 due to an access violation.

Imposing access restrictions using the “all” method is schematically presented in the figure:

“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 and do not affect the result of the operation, which is schematically presented in the figure:

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.

However, this option (ALLOWED) will not work if in a query we refer to a table for which access restrictions are not configured, but which contains references to table rows with configured restrictions. In this case, the query result will display “<Объект не найден>......" instead of the value of the reference field.

If you are developing a report or processing using standard or custom configuration queries, always check the "Allowed" flag for the report to work under any user with any set of rights.

In the case of object reading of data from the database, it is not possible to set the “Allowed” flag. Therefore it is necessary configure selections for object reading, taking into account possible access rights restrictions for the user. There are no means of obtaining only permitted data in object technology.

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.

Practice 1. Query builder in RLS settings.

Let’s compose the text of the “WHERE” section in the query to the directory. You can use the query builder.
The designer has a stripped down appearance.

“Tables” tab

The main table will be the table of the object for which the constraint is being configured.

You can also select other tables and set up various connections between them on the “Relations” tab.

Tab "Conditions"

Here you can configure the actual access restriction conditions

Let’s add conditions to the “Price” attribute of the nomenclature directory for the right to “read” to all fields of the table.

“Nomenclature WHERE Nomenclature.Price > 500”

Let's see how this simple rule works. The directory table contains the following elements:

After setting up an access restriction, the table will show only elements that satisfy the condition:

Groups also disappeared. Let's change the text of the restriction

“Nomenclature WHERE Nomenclature.Price > 500

OR Nomenclature.This is a Group"

Well, now that's what you need.

If you remove the display of the “code” field in the list settings, all elements of the directory will be displayed, i.e. the restriction didn't work. If you set the “Code” field to display, the restriction will work.

In this case, despite the fact that the directory element is visible in the list field, its form cannot be opened because a restriction on the attribute is configured. The same thing happens in an arbitrary request: when you try to get a “restricted” property, there will be an access error.

If you try to get the “restricted” credentials programmatically, an access error will also be thrown.

Moreover, it will not be possible to access any fields of an object through a link, because when receiving a link, the system reads the entire object, and if it contains “restricted” details, the object will not be read.

Therefore, when working programmatically with database objects, you need to keep in mind possible restrictions at the record level and obtain all the necessary object data by request and then place them in a structure or execute part of the code in a privileged module.

After setting up the access restriction, the display of the line in the list of rights changed - it became gray and an icon appeared.

Restrictions when setting up access (RLS).

There is no Summary section;
Virtual register tables cannot be accessed;
You cannot use parameters explicitly;
Can be used in nested queries any>/span> query language tools except:
- operator IN HIERARCHY;
- RESULTS proposals;
- nested query results must not contain table parts>/span>;
- virtual tables, in particular Balances and Turnovers

Practice 2. Nomenclature with current price.

Make an access restriction if you need to display items with a current price greater than a certain value, for example, 100.

Solution:

We are adding a new access restriction rule for the “Nomenclature” directory with the “read” right.
Select “other fields”.
In the constructor we add a nested query. In it, select the information register table “Item prices”.
There is no “order” tab - this is a feature of the query designer for building an access restriction request.
On the “Advanced” tab, set “first 999999999”, the “order” tab appears.
We set up ordering by the “Period” field in descending order.
Then we set up a connection between the main table and the subquery by reference.

Access Restriction Templates.

Practice 3. Restriction on “counterparties” by value in a constant.

Let's set up an access restriction for the Counterparties directory based on the value stored in the Constant.

In addition, you need to set up a restriction for all objects that use the “Counterparties” directory in the details.

Solution

For the “Counterparties” directory, we will set up a restriction for the “read” right by adding a nested query to the constant in the “Conditions” section. Don't forget This is a Group.

We see a problem, the Counterparties directory is filtered correctly, and all documents with the “Counterparty” attribute are displayed, some with “broken” links in the “Counterparty” attribute.

Now you need to configure access restrictions for all objects that use the link to “Accounts”. Let's find them using the “search for links to an object” service.

Let’s copy and slightly modify the text of the RLS condition from the “Counterparties” directory. This must be done as many times as there are objects found.

Or use an access restrictions pattern to avoid code duplication issues.

Access restriction templates are configured at the role level and can be used for any object within the edited role.

You can add any piece of access restriction text to the template. The template is called using the “#” symbol. For example, #TemplateCounterparty.

Through # in 1C instructions are written to the preprocessor. In the context of executing access restriction settings, the platform replaces the template call text with the template text.

Let’s add the text after the word WHERE to the “Contractor Template” template, except for the text about EtoGroup.

Parameters in access restriction templates.

Let's continue solving problem 2.

The problem now is that the main table in the directory is called “counterparty”, in the document “Receipt invoice”. The field being checked in the directory is called “link”, in the document it is called “Counterparty”.

Let’s change the name of the main table in the template text to “#CurrentTable”

"#CurrentTable" is a predefined parameter.

And through a dot we indicate the number of the input parameter - “.#Parameter(1)

“#Parameter” is also a predefined value. Can contain an arbitrary number of input parameters. They are addressed by serial number.

In the text of the access restrictions for the directory, we indicate the following:

For the document the following:

“Sales of Goods WHERE #TemplateCounterparty (“Counterparty”)”

When calling an access restriction template, parameters must be passed to it only as a String, i.e. in quotes.

Main table - Nomenclature

The template text is:

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

The template text contains part of the text in the data access restriction language and may contain parameters that are highlighted using the “#” symbol.

The "#" symbol may be followed by:

One of the keywords:
- A 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;
- NameCurrentAccessRight– contains the name of the right for which the current restriction is executed: 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 character “#” into the text.

An access restriction expression may contain:

Access restriction template, which is specified in the format #TemplateName("Template parameter value 1", "Template parameter value 2",...). Each template parameter is enclosed in double quotes. If you need to specify a double quote character in the parameter text, you must use two double quotes.
Function StrContains(WhereWeLook, WhatWeLook). 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.

They cannot be installed using SetParameter() or something similar.

The parameters in this case are:

Session Options
Functional options

Reading of session parameters in an access restriction request occurs in privileged mode, that is, without controlling the rights to operate with them.

Practice 4. Access to “your” counterparties

It is necessary to configure restriction of the current user’s access to “their” counterparties.

There is a directory “Users”, a directory “Counterparties”, documents with the details “Counterparty”.

The current user should see data only for those counterparties for whom a connection has been established with him.

Communication also needs to be configured.

Possible options:

Establishing connections between user and counterparty

Details in the counterparties directory
Register of information

Possible solutions to the problem:

Storing a user in a constant is a bad option; the constant is available to all users.
Storing a fixed array of the current user's counterparties in the session parameters is not a very good option; there can be many counterparties
Storing in the session parameters of the current user, then requesting a list of “his” counterparties is an acceptable option.
Other options.

Solution.

Let’s create a new session parameter “CurrentUser” and fill it out in the session module.

Let’s create a register of information “Compliance of managers and contractors”

Let's create a new role and in it a new access restriction for the document “Invoice”.

In the text of the request, we will connect the main table with the information register for Account = Account and Manager = &CurrentUser. Connection type Internal.

If possible, it is better to avoid nested queries in access restriction texts, since it will be executed every time data is read from this object from the database.

Checking - the restrictions work

*Feature: If you change the list of user counterparties in the register, access restrictions will take effect immediately without restarting the user session.

Practice 5. Date of prohibition of changes.

It is necessary to implement a restriction on editing data before the established date for prohibiting changes.
You need to limit it for users.

Let's create a register of information “Dates of Prohibition of Changes” with the dimension User, resource Date of Prohibition.

Let's build the logic of the solution this way:

if a user is not specified, then the ban applies to all users
if there is a restriction for all users and a restriction for a specific user, then the restriction applies for a specific user, and for others according to the general principle.

Obviously, such a constraint can be configured for database objects that have some position on the time axis. It can be

Documentation
Periodic information registers

Let's create a new role “Restrictions by Date of Prohibition of Changes”.

In it, for the document “Receipt Invoice” for the right “change” we will add a new access restriction.

We specify the settings for all fields.

The text of the restriction is:

ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice

Change Ban Dates. Ban Date AS Ban Date
FROM

INNER JOIN (SELECT
MAX(Change Prohibited Dates.User) AS User
FROM
Register of Information. Dates of Prohibition of Changes AS Dates of Prohibition of Changes
WHERE
(Change Prohibited Dates.User = &CurrentUser
OR Dates ProhibitedChanges.User = VALUE(Directory.users.EmptyLink))) AS VZ_User
BY Date of Prohibition of Changes.User = VZ_User.User) AS NestedQuery
Software Receipt Invoice.Date > Nested Query.Ban Date

Let's check - the restriction works.

Using Preprocessor Instructions

#If Condition1 #Then

Request fragment 1

#ElseIf Condition2 #Then

Request fragment 2

#Otherwise

Request fragment 3

#EndIf

In conditions, you can use logical operations (and, or, not, etc.) and access to session parameters.

This approach in the context of constructing access restrictions is convenient in that, depending on the conditions, a shorter request text will be compiled. A simpler query loads the system less.

The downside is that the query constructor will not work with such text.

*Peculiarity :

In contrast to the instructions to the preprocessor of the built-in language in the access restriction texts, before the operator Then you need to put a hash - #Then

Practice 6. Switch “Use RLS”

Let's supplement our system of restrictions with a switch that turns on/off the use of restrictions at the record level.

To do this, add a Constant and a session parameter named “UseRLS”.

Let's write in the Session Module to set the value of the session parameter from the value of the constant.

Let's add the following code to all access restriction texts:

“#If &UseRLS #Then….. #EndIf”

We check - everything works.

However, now after turning on the “use radar” flag, the changes will not immediately take effect. Why?

Because the session parameter is set when the session is started.

It is possible to set the value of the session parameter to be reset when a new constant value is written, but this will only work for the current user session. Other users should be prompted to restart the system.

End of the first part.

In the 1C Enterprise 8 system, today we will continue to study the rights mechanism and delve further into the RLS mechanism (restriction of rights at the record level).

Below we will look at the advantages and disadvantages of this method and look at setting up RLS in 1C Enterprise 8.3 using an example.

1C RLS (Record Level Security) or restriction of rights at the recording level- these are user rights in the 1C system, which allows you to separate rights for users in the context of dynamically changing data.

The most common type of 1C RLS setting is to limit user visibility across organizations or clients (the user sees only “his” data).

The main advantage is the presence of a mechanism at all; 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, a noticeable drop in system performance can be noted. This is due to the fact that the platform, when building a query in the database, complicates any developer request with additional conditions.

Also among the disadvantages is the complexity of setting up this functionality and the difficulty of debugging. 1C has released very little material on the setup and operation of this functionality. It is quite difficult to find a specialist who would correctly set up the mechanism.

Setting up rights restrictions at the 1C RLS record level

Record-level permissions (RLS) are used to restrict the following types of rights:

Reading
Addition
Change
Removal

Get 267 video lessons on 1C for free:

Externally, setting up RLS (record-level rights) is similar to creating a simple . An example of a template for restricting access to the visibility of documents by client from the document header:

##If &UseRecord-Level Access Rights Restrictions ##Then

CurrentTable FROM #CurrentTable AS CurrentTable
LEFT JOIN (SELECT VARIOUS
Group Composition.Link AS User Group
FROM
Directory.User Groups.UsersGroups AS Group Composition
WHERE
GroupComposition.User = &CurrentUser) AS UserGroups
Software (&UseRecord-Level Access Rights Restrictions)
WHERE (&UseRecordLevelPermissionRestrictions = FALSE
OR (NOT 1 V
(SELECT TOP 1
1 HOW TO SELECT
FROM
Register of Information. Purpose of Types of Access Objects AS Purpose of Types of Access Objects
WHERE
Purpose of Types of Access Objects.UserGroup = UserGroups.UserGroup
AND CHOICE
WHEN Purpose of Types of Access Objects. Type of Access Object = VALUE (Enumeration. Types of Access Objects. Counterparties)
And CurrentTable.#Parameter(1) LINK Directory.Counterparties
AND NOT CurrentTable.#Parameter(1) = VALUE(Directory.Accounts.EmptyLink)
THEN CHOICE
WHEN 1 V
(SELECT TOP 1
1
FROM
Directory.Counterparties AS Contractors INTERNAL JOIN Information Register.User Access Rights Settings AS User Access Rights Settings
BY
UserAccessRightSettings.AccessObject = Counterparties.AccessGroupToCounterparty
And UserAccessRightSettings.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Counterparties)
AND (User Access Rights Settings. User = Assignment of Types of Access Objects. User Group
OR UserAccessRightSettings.User = VALUE(Directory.UserGroups.AllUsers))
And UserAccessRightSettings.Record = TRUE
WHERE
Counterparties.Link = CurrentTable.#Parameter(1))
THEN THE TRUTH
ELSE FALSE
END
OTHERWISE TRUE
END = FALSE))
AND NOT UserGroups.UserGroup IS NULL)
##EndIf

Essentially, this query is added every time the table "#CurrentTable" is queried. From which we can imagine what additional load the restriction mechanism at the record level carries.

As you can see, the request has special parameters, for example “&Use Access Rights Restrictions at the Record Level”. These parameters in the radar are selected from metadata objects - “ “. As a rule, they are set at the start of the user session.

Data Access Restriction Constructor

For the convenience of the developer, 1C 8.3 has a special utility to help configure the radar - Data Access Restriction Designer. It is called from the "Access Restriction" field. As follows:

This tip provides step-by-step instructions for setting up Record Level Sceurity (RLS) in Axapta 3.0.

Where is this written in the Documentation?

Russian version: Users Guide for Admin (Russian)_3.0.pdf (p. 126)
English version: User's Guide for Administration (pages 40, 101)

Introduction

Record Level Security (RLS) allows you to restrict access to records to different user groups. For example, one group of managers may see Russian clients, and another – foreign ones. Moreover, managers working with Russian clients should not see foreign clients. Moreover, managers shouldn’t even see them.

RLS in Axapta works in conjunction with the system for setting up regular rights. This means that in order to restrict access to a particular table field, you need to configure normal rights to these tables. The purpose of RLS is to filter records unnoticed by the user.

Setting up rights restrictions at the record level comes down to defining filters for certain tables for different user groups. If the user is a member of several groups, then the filters are combined using the OR condition.

The art of setting permissions is to correctly define filters on the right tables. Moreover, do this in an optimal way so as not to reduce system performance.

Settings

Before we set up access rights restrictions, we need to take the following preliminary steps:

The preparatory work has been completed. Currently the Test user does not have any rights. You can log into Axapta as a test user and make sure that he cannot even open the main menu.

You can start setting up RLS:

Let's set up normal rights for the tstGroup1 group.

Now let's configure RLS

For the created setting, edit the request.

Click on the Request button;

Actually, that's all! RLS is configured. Now the Test user has the rights to read data from the Accounts Receivable module and the right to create and delete orders. In addition, a filter is applied to the customer table. Starting from this moment, users belonging to the tstGroup1 group will be able to see only other clients (clients for whom the Other group is set).

Let's check the setting

Log in to Axapta as the Test user. Open the list of clients (Main menu \ Accounts receivable \ Clients). Make sure that the list of clients shows only those clients for which the group with the Prch code is set.

Please note that not only the Accounts receivable tab has opened in the main menu. The General Ledger, Cash, CRM, Inventory Management, and General bookmarks also opened. The fact is that by giving rights to the clients module, we affected many tables from other modules. Yes, of course, unnecessary bookmarks are almost empty. But still, in real life, rights must be given much more carefully.

In addition, in real life, bookmarks from unpurchased modules never appear. For example, try disabling the CRM module in the configuration keys setting.

Try applying the "*" filter to the group (Place the mouse on the Client Group column, right-click, select Find..., enter the "*" filter).

Try also applying the "!Prch" filter. Try applying filters to other fields. Make sure that the client filter actually works correctly in all cases.

Check how RLS works in reports. Open a report with a list of clients (Main Menu \ Accounts Receivable \ Reports \ Basic Data \ Client). Try building the same report with filters. Make sure that the client filter works correctly in your reports.

Please note that the programmer does not need to change or redo anything for RLS to work in his report if he used the kernel in forms or to build reports and did not override the data retrieval mechanism. If the programmer manually coded queries, then he needs to add a call to the recordLevelSecurity(true) method for those tables where it is necessary to enable record access restrictions. See the developer guide for the Record Level Security keyword for more details.

Open orders. Oops! And orders are shown for all clients. Why? But because orders contain customer codes, and not the customers themselves. Try going to the main table with clients - you will not be able to see the parameters of hidden clients.

Generally speaking, in real life, setting up permission-level restrictions is not enough to set up one table. Typically, interrelated constraints must be applied to multiple related tables.

Record-level permissions apply not only to forms and reports, but also to drop-down lists. Open the order and click on the drop-down list button for the client. Yes everything is correct. The Test user sees only other clients.

RLS for multiple groups

Now consider a situation where you need to configure several different groups with different rights and with different rights restrictions.

Let's assume that one group of managers has access to Other clients (client group = Prch), and another group of managers has access to Regular clients (client group = T&U). We have already set up the first group. All that remains is to configure the second group.

Repeat steps 8-10. Just give the tstGroup2 group full rights to the Accounts Receivable module and specify “T&U” as a criterion in the RLS setting for the tstGroup2 group.

To check, go to Axapta under the Test user and make sure that the forms and reports work correctly, make sure that you have received full rights to clients and can edit client parameters.

What happens if a client changes group? The client will be visible in the form until he leaves the screen form. As soon as Aksapta reads the data from the server again, RLS will work and the manager will no longer see the “foreign” client.
This example again shows that rights need to be configured comprehensively. In this situation, you can either prevent managers from editing the customer group field, or set up a record-level restriction (RLS) and on the table with groups.

In order to allow some users access to the entire list of clients, it is necessary to give the third group rights to the client table, but not configure RLS. Axapta looks at regular permissions. And, if there is access permission, then it looks in the RLS settings. If there are no RLS settings for a given group and table, then Axapta shows all records from the table.

Please note that the tstGroup3 group did not affect the behavior of RLS as long as it did not have rights to the clients table. As soon as the right to clients appeared in this group, this group immediately began to participate in RLS. To test this thesis, remove rights to the Accounts receivable module in the tstGroup2 group and check the RLS for the Test client. You will only see other clients.

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. There is an important feature that the Read operation can have multiple record-level constraints applied, while all other operations 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 generating 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

To make the use of restrictions more convenient, the 1C Enterprise system provides 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!

Every manager will unconditionally agree that every employee at the enterprise should have access only to the information that is within his competence. For example, a storekeeper in a warehouse does not necessarily need to see what operations are being performed by the financial director or chief accountant. However, quite subtle situations often arise, for example, when the 1C: Enterprise 8 program is used not for one, but for several enterprises. Each of them has its own employees, who must have access only to authorized information related to their enterprise.

In this case, technology is an ideal assistant in providing the necessary access rights. Record Level Security(RLS), which allows you to provide access to information at the record level.

Let's look at an example of a specific situation. Our company consists of two organizations. The first is engaged in the sale of software, the second - training in working with it. To account for both of these organizations, we use the 1C software product: Integrated Automation 8.

Our task is to differentiate the access rights to information of employees of two organizations so that employees with the same rights can see only what relates to the organization in which they work.

The first thing that comes to mind when posing this problem is setting up selections for organizations. However, this solution has two significant drawbacks:

selections will have to be adjusted in all forms of the program;
For a more or less savvy user it will be absolutely no problem to disable them.

The surest way is to limit user access at the record level. How to implement this?

The first thing you need to do is enable the program to use this method. To do this you need:

In our case, it is necessary to restrict access by organization, but it is clear that the program provides much wider opportunities. For example, limit access to directories and documents.

A similar mechanism is implemented in other 1C application solutions:

(revision 10.3)
and 1C: Salaries and personnel management 8 (revision 2.5).

In these programs, access rights are differentiated using the “User Groups” directory, which is accessible from the “Tools” menu, section “Setting up user access”.

Thus, in these programs we need to divide all our users working as part of the company into groups by organization.
Then click the “Access Settings” button.
In the window that appears, click the “Add” button and enter the access object (in our situation this is an organization).
If we need to allow employees of the organization to enter data into the information database, then we need to check the box in the “Record” column.

These steps must be completed for each organization. After this, each employee, after entering the program, will see only those documents that are determined by his access rights by position and relate to his organization.