System of access rights allows describing the sets of rights that correspond to the positions of user or to the kind of activity. The structure of rights is determined by a particular application solution.

In addition, for the objects stored in the database (catalogs, documents, registers, etc.) the access rights can be specified for the individual fields and records. For example, the user can operate with the documents (invoices, bills, etc.) of specific contractors and do not have an access to the similar documents of other contractors.

Roles

To implement the restriction of access rights, the special configuration objects are intended in the application solutions - Roles. Read more .

Interactive and basic rights

All the rights supported by the 1C:Enterprise system can be divided in two large groups: basic and interactive. The basic rights describe the actions performed over the items of system data or over the entire system as a whole and are always checked, regardless of the method of data access. The interactive rights describe the actions that can be performed by the user interactively. Thereafter, they are checked only when executing the interactive operations in a standard way, and in the client-server variant all the checks of rights (except interactive) are made on the server.

The basic and interactive rights are interrelated. For example, there is a basic right Delete to which two interactive rights correspond: Interactive delete and Interactive delete marked. If it is denied for the user to Delete, then all the interactive "deletions" will be also denied for him. At the same time, an Interactive delete marked is permitted for the user, this means that it is permitted also for him to Delete.

In addition, the basic rights can depend on each other. As a result, rather complex chains of interrelations are created that are tracked by the system automatically: as soon as the developer removes the permission for any right, the system removes itself the permissions for all the rights that depend on this right. Conversely, when enabling any right by the developer, the system enables itself all the rights on which this rights depends.

For example, to have a right Interactive delete marked, the user must have an interactive right Edit. This right, in turn, requires the presence of interactive right View:

A right Interactive delete marked requires the presence of basic right Delete. Interactive right Edit requires the presence of basic right Change. Interactive right View requires the presence of basic right Read.

In addition, the basic rights Change and Delete require the presence of basic right Read.

Data access restriction at the levels of records and fields

Among the actions over the objects stored in the database (catalogs, documents, etc.), there are the actions responsible for reading and changing information stored in the database. These actions include:

• read – receiving the records or their fragments from the database table;
• add – adding the new records without changing the existing ones;
• change – changing the existing records;
• delete – deleting some records without changing the remaining ones.

For these actions, the additional conditions for data (data access restriction) can be specified during customizing the roles. In this case, the requested action can be performed over a particular object stored in the database only in the case if the data access restriction of this object has a value "true". The similar conditions can be specified for the database tables that do not have an object (register) nature.

For the objective tables and information registers different restrictions can be specified for the different table fields that allows specifying the restrictions not only at the level of database records, but also at the level of its individual fields:

Data access restriction is a condition described in the language which is a subset of query language. This condition is applied for each database table record for which an operation is performed. If condition possesses the value "true", then operation is performed, otherwise, it is not performed. The access restriction condition can be specified using the preprocessor instructions (#IF <condition>, #THEN.., etc.) that makes it more effective. When viewing the lists and generating the reports, there is an ability to display only those data the access to which is permitted for the user.

For the accumulation, accounting and calculation registers the conditions allow delimiting the access according to the values of measures (for the accounting registers according to the balance measures) and for the objective data and information registers the conditions allow delimiting the data access according to any fields.

The restriction condition can be entered manually or created using row- and cell-level security wizard .

Session parameters

The session parameters are the application solution objects intended to be used in the data access restrictions for the current session (but can be used for the other purposes). Their values are saved during this session of 1C:Enterprise. The use of session parameters allows reducing the data access time in case of access restriction at the level of records and fields. Read more .

Server-side execution without checking the rights

Privileged modules

There is an opportunity to assign the privileged modules. In these modules the operations can be transferred that use the data for which the user has no rights.

For example, the rights can be assigned for the user that allow creating a new document. However, the user does not receive any rights for the register in which this document creates a record in conduction. In this situation, a procedure of document conduction can be moved in the privileged module executed on the server without checking the rights. As a result, despite the fact that the corresponding register is not available for usage, the user is still able to conduct the documents he created.

Privileged mode of software code execution

The privileged mode of code execution, similar to the code operating mode of the privileged modules, can be enabled/disabled using the script tools. To do this, the global context provides a procedure SetPrivilegedMode() as well as a function PrivilegedMode() which allows determining whether the privileged mode is enabled or not.

The use of privileged mode allows, firstly, to accelerate the work, because the data access will not be constrained, and secondly, allows performing the operations with data for the users for whom these data are unavailable.

The privileged mode is recommended to use when from the logical point of view it is required to disable verification of rights or when it is possible to disable verification of rights in order to accelerate the work. It is allowed to use the privileged mode when the work with data for a particular user does not violate the access rights for this user.