Access rights





The system of access rights allow you to specify sets of rights that correspond to employee positions or business activities. The rights structure is defined in the applied solution.

One can define access rights to specific fields and records of database objects (catalogs, documents, registers, etc.). For example, an end user can have the right to work with documents (invoices or checks) which are issued by specific counterparties yet not have any access to documents of these types issued by other counterparties.

Roles

The Role configuration object is intended for implementing access rights.

Basic and interactive rights

The rights supported by 1C:Enterprise are divided into two major categories: basic and interactive rights. Basic rights describe actions that are performed with the data elements of the system or with the system as a whole. These rights are always checked regardless of the way data is accessed. Interactive rights describe actions that can be performed by the user interactively. Therefore, they are only checked when interactive operations are performed using standard commands. In the client/server mode all checks (except for interactive ones) are performed on the server.

Basic and interactive rights are interrelated. For example, the basic rule Delete has two matching interactive rights: Interactive delete and Interactive delete marked. If Delete is prohibited to the user, all interactive delete operations are also prohibited. On the other hand, if Interactive delete marked is allowed, Delete is also allowed for the user.

In addition, basic rights can depend on each other. As a result, rather complex interrelations can be created. These interrelations are automatically monitored by the system: as soon as the developer removes a specific right, the system automatically removes all the rights that depend on it. On the other hand, if a developer sets a certain right, the system automatically sets all the rights on which this one depends.

For instance, to have the Interactive delete marked right, the user must have the interactive Edit right, which in turn will demand the interactive View right.

The Interactive delete marked right requires the basic Delete right. The ineractive Edit right requires the basic Update right. The interactive View right requires the basic Read right.

In addition, the Update and Delete basic rights require the Read basic right.

Data access restrictions at the record or field level

There are actions performed on database objects (catalogs, documents, and so on) that read or modify information stored in the database. These include:

  • Read. Obtaining records or record fragments from a database table.
  • Add. Adding new records without changing the other ones.
  • Edit. Editing the existing records.
  • Delete. Deleting some records without changing the other ones.

Customizing roles allows you to set additional conditions for handling data (data access restrictions). In this case, a requested action can be performed on a specific object stored in the database only if the data access restriction for this object's data is set to TRUE. You can set similar conditions for database tables that do not store objects (for example, for registers) as well.

You can specify different restrictions for different tabular fields of object tables and information registers. This allows you to set restrictions at both database record level and database field level.

A data access restriction is a condition described in a language that is a subset of the query language. This condition is applicable to each record of a database table on which an operation is performed. If the condition is TRUE, the operation is performed. Otherwise the operation is not performed. The condition can be refined by using preprocessor instructions (#If <condition>, #Then, and so on). You have the option to display only data that the user is allowed to access while they are viewing a list or generating a report.

You can restrict access to accumulation registers, accounting registers, and calculation registers by dimension values (by balance dimensions for accounting registers); and you can restrict access by any fields for object data and information registers.

You can enter a restriction condition manually or create it using the Data access restriction wizard.

Session parameters

Session parameters are applied solution objects intended for data access restriction within the current session (and also for some other purposes). Their values persist within a 1C:Enterprise session. Using session parameters increases the data access speed when access is restricted at the record and field level.

Execution on server without verification of rights

Privileged modules

You have the option to assign privileged modules. You can move operations that use data for which the current user has no rights to privileged modules.

For example, a user has the right to create a document. However, the user is not granted any rights to the register in which this document creates records when posted. In this scenario, you can include the document posting procedure in a privileged module that is executed on the server without rights verification. As a result, the user will be able to post the documents created despite the fact that the register is not available for the user.

Privileged script execution mode

The privileged script execution mode, which is similar to the privileged module execution mode, can be enabled or disabled by script tools. The global context provides the SetPrivilegedMode() procedure and the PrivilegedMode() function that checks whether the privileged mode is enabled.

If you use the privileged mode, your application can work faster as data access restrictions are not applied, and it is capable of performing operations with data on behalf of users who have no access to this data.

Use the privileged mode when you need to disable rights verification from a logical point of view, or when you can disable such verification to improve performance. It is okay to use the privileged mode when working with data on behalf of a user does not violate the access rights set for this user.

See also:


Comments
0
Add comment