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:

  • Roles. Roles are metadata objects. Creating and setting up roles is described in the section "Roles and Access Rights" of 1С:Enterprise Developer Guide.
  • Session parameters. Session parameters are metadata objects, too. Creating and setting up session parameters is described in the section "Session Parameters" of 1С:Enterprise Developer Guide.
  • Privileged common modules. Refer to section "Common Modules" of 1С:Enterprise Developer Guide for more information on how to create and set up common modules.
  • "ALLOWED" keyword of the query language. (See section "Work with Queries" of 1С:Enterprise Developer Guide).

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:

  • exchange plans;
  • catalogs;
  • documents;
  • charts of characteristic types;
  • charts of accounts;
  • charts of calculation types;
  • business processes;
  • tasks.

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

  • exchange plans;
  • catalogs;
  • documents;
  • document journals;
  • charts of characteristic types;
  • charts of accounts;
  • charts of calculation types;
  • information registers;
  • business processes;
  • tasks.

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:

  • Fields of the database object to which the restriction is applied (referred to as a major restriction object) and expressions using such fields. For example, if a restriction is applied to reading the items of the Counterparties catalog, such a restriction can be based on fields of the Counterparties catalog and its tabular sections. Below you can see a few examples of the most elementary restrictions for reading items of the Counterparties catalog:

    Description = "Brick factory"


    Products.Description = "Red brick"

where Products is a tabular section of the Counterparties catalog.

  • Fields of database objects that can be accessed by references stored in the major restriction object and expressions using these objects. For example, if PrimaryManager attribute of the Counterparties catalog has a type of reference to Users catalog, access restriction can be as follows:

    PrimaryManager.Code = "Smith"


    PrimaryManager.Individual.Description = "Johnson"

  • Fields of database objects linked to major restriction object by some conditions, and expressions using these objects. For example, the following restriction can be applied to reading items of the Counterparties catalog:

    Catalog.Counterparties AS Counterparties 
        LEFT JOIN Catalog.Users AS Users 
        ON Counterparties.PrimaryManager.Description = Users.Description 
    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.

  • Embedded queries as record sets to link with the main restriction object or as operands of IN or NOT IN comparison operations. Embedded queries can use any tools of the query language except for HIERARCHY operator, TOTALS statement and some virtual tables, including BalanceAndTurnovers. In the following example of a read restriction for the Counterparties catalog an embedded query is used as a record set for linking to the major restriction object:

    Catalog.Counterparties AS Counterparties 
                       Users.Description, Users.Individual 
                       Catalog.Users AS Users
                        Users.Code > "Smith") AS Users 
        ON Counterparties.PrimaryManager.Description = Users.Description 
    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.Individual IN 
              Employees.Individual AS Individual 
              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

  • Session parameters, independent or used as part of expressions. For example, the following restriction can be applied to reading items of the EmailMessageGroups catalog:

    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:

  • In the accumulation registers, access restrictions can only contain dimensions of the major restriction object.
  • In the accounting registers, restrictions can only use balance dimensions of the major restriction 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:

  • "All". In this method, an operation with data (initiated from a dialog box, 1С:Enterprise script, or query) should be executed with all the database objects implied by the operation. If such an operation requires reading or editing database objects that fail the access restrictions check, the operation is aborted due to the access rights violation.
  • "Allowed". In this method, when an operation should be executed with data, only those database objects that meet the access restrictions are read. Database objects that do not match the access restrictions are considered absent for this operation and do not affect the result.

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:

    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:

  • The list of rights (read, add, edit, delete), the database table list and the list of fields used by the query are generated.
  • Data access restrictions are selected from all the roles of the current user for all the rights, tables, and fields involved in the query. If any role does not restrict access to data from any table or field, it means that in this table the values of the required fields are accessible for any record. In other words, no data access restriction implies that the restriction "WHERE TRUE" is applied.
  • The current values of all the session parameters involved in the selected restrictions are acquired. In order to select the parameter value, the current user does not have to have the right to retrieve the value of this parameter. However, if a value of certain session parameter has not been set, an error will occur and the database query will not be executed.
  • Restrictions received from a single role are joined by the "AND" operation.
  • Restrictions received from different roles are joined by the "OR" operation.
  • The conditions generated are added to the SQL queries that 1C:Enterprise sends to the database management system. The rights to access data are not checked when the data is accessed by the access restrictions (neither for metadata objects nor for database objects). The mechanism for adding conditions depends on the selected restriction application method ("all" or "allowed").

"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:

  • Session parameters are metadata objects. This lets 1C:Enterprise to control their use more thoroughly.
  • Session parameters belong to specific types (with the valid types listed below). An important feature is that it is impossible to change the internal state of an object of this type.
    • primitive types (for details see section "Primitive Data Types" in 1С:Enterprise Developer Guide);
    • ValueStorage;
    • TypeDescription;
    • references to database objects;
    • UUID;
    • a FixedArray containing the values of these types as its elements, including those of FixedArray type. FixedArray does not allow for any modification of its contents and can be designed based on an Array object;
    • AccumulationRecordType;
    • AccountType;
    • AccountingRecordType.
  • In order to define or get a value of a session parameter, the current user should have the required rights.
  • In the client/server mode of 1C:Enterprise, the values of session parameters are stored on the server and can be accessed from both the server and the client.
  • Session parameters do not have any default values. Attempting to get the value of a session parameter before it is defined will result in an error.
  • Session parameters can be accessed both using 1C:Enterprise script (e.g.: SessionParameters.CurrentUser = UserName() or User = SessionParameters.CurrentUser), and using access restrictions (e.g.: Document.Report.User = &CurrentUser). In the latter case, the current user is not required to have a right to get a session parameter value.

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:

  • In the client/server mode of 1C:Enterprise, only a module executed on the server-side can be privileged.
  • Procedures and functions of a privileged module and everything called by them are executed with the access restriction system disabled (both regarding access to metadata objects and access to data). Therefore, in a privileged module, any operation can be executed with any object, even if the current user does not have the respective rights.

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

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

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

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