Desktop version

Main > Knowledge Base > Developer resources > Development recommendations > Record- and field-level access restrictions > Data access restrictions. Operating concepts overview > Developer resources > Development recommendations > Record- and field-level access restrictions > Data access restrictions. Operating concepts overview > Developer resources > Development recommendations > Record- and field-level access restrictions > Data access restrictions. Operating concepts overview

Data access restrictions. Operating concepts overview

This document contains concise information regarding the platform feature that restricts data access at a record level.

Generic concepts

This feature provides access rights management not only at the metadata object level but at the level of 1C:Enterprise database objects as well. You can use the following 1C:Enterprise objects to restrict data access:

When used together, the above objects ensure the best flexibility of data access rights management in systems where users have different responsibilities.

Access restrictions

Access restrictions can control the reading and editing of database objects. The current user is able to read or edit a database object only if the access restrictions allow them to perform these actions. Otherwise, a read or edit operation will not be executed on the database object.

Different restrictions can apply to different edit operations (add, modify, or delete) for the following database objects:

For the following database objects, the reading can be restricted for both the entire object as well as its specific fields:

It is important to remember that when database object fields are accessed using the properties of applied objects from 1С:Enterprise script, the entire object is read and not just the value of the required field. The exception here is obtaining a presentation, where only the values of the fields that take part in generating the presentation are read.

Access restrictions are stored in roles, they can be specified for most metadata objects. Access restrictions are written in a special language that is a subset of the query language. The main part of a restriction is a condition which, when true for a database object, means that the current user is entitled to read or edit this object. Editing a record is considered allowed if the record does not contradict any edit restrictions either before and after the change is applied. The following items can be used in a restriction:

WHERE 
    Description = "Brick factory"

       or 

WHERE 
    Products.Description = "Red brick"

where Products is a tabular section of the Counterparties catalog.

WHERE 
    PrimaryManager.Code = "Smith"

       or

WHERE 
    PrimaryManager.Individual.Description = "Johnson"

    Counterparties 
FROM 
    Catalog.Counterparties AS Counterparties 
        LEFT JOIN Catalog.Users AS Users 
        ON Counterparties.PrimaryManager.Description = Users.Description 
WHERE 
    Users.Individual.Description = "Johnson"

Here we use fields of the Users catalog items that are linked to a specific item of the Counterparties catalog by the values in the Description fields.

    Counterparties 
FROM 
    Catalog.Counterparties AS Counterparties 
        LEFT JOIN (SELECT 
                       Users.Description, Users.Individual 
                   FROM 
                       Catalog.Users AS Users
                   WHERE
                        Users.Code > "Smith") AS Users 
        ON Counterparties.PrimaryManager.Description = Users.Description 
WHERE 
    Users.Individual.Description = "Johnson"

Below you will find a sample restriction for reading from the PassportDetailsOfIndividuals catalog where an embedded query is used as an operand in a comparison operation IN:

     PassportDetailsOfIndividuals 
WHERE 
     PassportDetailsOfIndividuals.Individual IN 
         (SELECT DISTINCT 
              Employees.Individual AS Individual 
          FROM 
              InformationRegister.Employees AS Employees)

Note that the results of the embedded queries that are used in a restriction should not have any tabular sections. If you need to get data from a tabular section in an embedded query, the FROM section of the embedded query should call the tabular section directly. E.g., instead of:

SELECT Ref AS Ref, Products.Description AS ProductName
FROM Catalog.Counterparties

for the correct query embedded in an access restriction use the following:

SELECT Ref AS Ref, Description AS ProductName
FROM Catalog.Counterparties.Products

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

where CurrentUser is a session parameter.

Restrictions for the following database objects can use some (not all) fields of the major restriction data object:

Actions of access restrictions

Access restrictions are checked whenever any relevant operations are executed with database objects (from dialog boxes, 1С:Enterprise script, or queries). This can be performed in one of the following methods:

Data access restrictions are applied to database objects when 1C:Enterprise accesses the database. In the client/server mode of 1C:Enterprise restrictions are applied on the server.

A method to be applied is selected based on the operation's purpose and the importance of its results. In particular, the "allowed" method is used for displaying dynamic lists and in some other interactive actions. The "all" method is used to execute any operations with applied objects from 1С:Enterprise script, including any modifications of database objects. Therefore it may be difficult to build a selection of managers of catalogs, documents and other objects for the Choose method with subsequent iteration through the result if a given object has quite a complex restriction applied to it. This is due to the fact that not every condition in the access rights restrictions can be adequately presented as a selection for the Choose method.

In queries, you can set the method of data access restrictions. For this purpose, the query language provides the ALLOWED keyword. If a query does not contain the ALLOWED keyword, the "all" method is used for restrictions. If ALLOWED is present, the "allowed" method is used.

It is important that if a query does not contain the ALLOWED keyword, none of the selections in the query should contradict any of the read restrictions for the database objects used in this query. Note that if virtual tables are used in a query, the respective selections should be applied to them as well. Example:

SELECT
    ContactInformationSliceFirst.Presentation
FROM
    InformationRegister.ContactInformation.SliceLast(, Type = &Type) AS ContactInformationSliceFirst WHERE 
    ContactInformationSliceFirst.Type = &Type

When you use an object-based methodology, you cannot access data in the ALLOWED mode. It is meant to be that this methodology is used for the most critical data operations, including data modifications. In order to use the object-based methodology to access all the data regardless of the applied restrictions, you can execute required actions in a privileged module or under a user account with full rights. The object-based methodology does not provide any way to access only allowed data.

Mechanism of restrictions application

Any operation on database data in 1C:Enterprise eventually results in sending a read or edit query to the database. Internal 1C:Enterprise mechanisms apply data access restrictions while database queries are being executed. During this process:

"All" method

When restrictions are applied using the "all" method, SQL queries are supplemented by conditions and fields so that 1C:Enterprise is able to receive information regarding the use of data restricted for this user in database query execution. The query is aborted if its result includes any restricted data. This figure shows how access restrictions are applied using the "all" method.

"Allowed" method

When the "allowed" method is used, SQL queries are supplemented by conditions that will not allow records forbidden to the current user to affect the query result. In other words, when the "allowed" method is used to apply restrictions, the data forbidden to the current user is considered absent (this is shown in the following figure):

Other objects related to data access restrictions

When a configuration is developed using data access restrictions, metadata objects such as session parameters and common modules marked as "privileged" can be useful.

Session parameters

Session parameters are metadata objects that have the meaning of the named values and can be used in data access restrictions in the same way the query parameters can be used in a query. We recommended that you use session parameters in access restrictions instead of literals and literal lists (in the comparison operators IN and NOT IN). In addition, they can be used in configurations for other purposes as well if storing information that describes a 1C:Enterprise session is needed.

One should distinguish the application scope of session parameters from that of global variables of application module (an external connection module). Major differences of session parameters include the following:

Privileged common modules

If a common module has the Privileged checkbox selected, the execution of this module’s procedures and functions becomes different in an important way:

Privileged modules are intended to be used for the initial setup of the session parameter values used in data access restrictions. Common modules can also be used for a user with limited rights to execute some actions with data as a whole. For example, if a user is in charge of entering and posting documents but this user should not have access to the data affected by document posting, the posting can be located in a privileged module. This will permit the user to post documents without granting this user any rights to access other information (e.g. registers).

Common access restriction recommendations

For the common access restriction recommendations, see section "Data access restriction" in 1С:Enterprise Developer Guide.

Next page: Efficient operation of data access restrictions on the record level




© 1C LLC. All rights reserved
1C Company respects the privacy of our customers and visitors
to our Web-site.