1c 8.3 subsystem functional options. Access control: roles, rights, profiles, access groups, functional options, RLS. Data composition system

Functional options mechanism is one of the development tools. It allows you to define in the configuration the functionality that may or may not be used during implementation, depending on the needs of a particular organization.

The mechanism is based on two configuration objects:

• Functional option
  Configuration objects and their attributes can be linked with functional options added to the application solution. For example, with the functional option Warehouse accounting you can link props Warehouse document Goods receipt... Then, if you enable this functional option in 1C: Enterprise mode, the Warehouse will be displayed in all forms of the document. If you turn it off - the field Warehouse will not be displayed. More information ...

• Functional option parameter
  Functional options can be used with parameters. For example, so that the type of a particular form can depend on the value of the parameter selected in the form. For example, by the parameter of the functional option Currency accounting may be Organization... Then, depending on which organization is selected in the form, the field Settlement currency will be hidden or shown. More information ...

Functional Options is a metadata object located in the "General" group:

Functional options are part of the mechanism of functional options that allow you to enable or disable some functionality in the operation of an application solution, depending on the user's needs, without modifying the configuration itself.
For example, not every organization can use inventory control. If accounting for warehouses is not used, then it makes sense to remove the warehouse field in all documents, reference books and registers - then functional options come to our aid.

Let's take an example:

Let's create a functional option " Accounting by Warehouses".
Storage: the field that stores the value is indicated.
You can select a constant, a reference attribute, or an information register resource.
You and I will use a constant.

Let's create a constant " KeepAccountingByWarehouses"and select it in the storage field. This constant will be responsible for enabling and disabling the functional option. Set the" Privileged mode upon receipt "checkbox. This checkbox means that the values ​​of the functional option will be received in the privileged mode:

Updating, launching 1C Enterprise. Let's set the value of the constant = True:

As a result, we have:

When setting the constant = False, we get:

Do you have a question, need a consultant's help?

So, we have created a functional option that controls fields of the ReferenceLink type.

Let's now look at an example of using functional options parameters.
Let's add a new functional option " Currency accounting"
Storage: Directory.Organization.Partners.Furrency Accounting

Add to the composition of the document attribute "Setting item prices" - "Currency"

In the form of a Document in the procedures "OnCreateAtServer" and "OrganizationOnChange"
Let's add the following code:

We update the configuration and run it.
We create two Organizations and for one of them set the "Currency accounting" checkbox

What do we get in the end? As a result of using the parameters of the functional option, you and I got parametric control of the "Currency" field in the document "Setting item prices". Those. for the Alpha organization, the Currency field will be displayed, and for the Beta organization, the Currency field will not be displayed.
Let's see this. Open the document and try to change the "Organization" field
When setting Organization = "Alpha", the currency is displayed; change to "Beta" - the currency is removed

1. Access rights.

In fact, everything is very simple. In 1C by default everything that is not allowed is prohibited... There is only one entity responsible for access user to any functionality or data. This entity is called "Right of access"... She happens to be the only one an element responsible for access to a specific operating mode, reference book, props ...

The number of types of access rights is predetermined by the platform. In total, the platform has two main groups of access rights. Common to the whole system access rights to platform mechanisms responsible for accessing certain operating modes of the platform (Administration, Exclusive mode, Thin client, Interactive opening of external reports ....). AND object permissions that allow you to work with various configuration objects. Their number depends on the type of configuration object. For example, the directory has 16 different types access (Read, Add, Modify, Delete ....). There are only five types of access for the register of information. All these rights can be set only at the entire directory level. You can also restrict access at the requisite level. But in this case, only a part of the types of rights is available (for reference books, these are the View and Edit rights).

All access rights are linked and dependent on each other. There are rights higher and higher low level... You cannot grant a lower-level right if the user does not have higher-level action rights.

Consider access rights to the directory. This diagram shows that most of the rights are a specification of more general rights... If Law1 is completely located on the diagram inside the rectangle of another Law2, then Law1 cannot be issued without issuing Law2. The most common right is the "Read" right. If the "Read" right is absent, then all other rights are unavailable. If the "Add" right is not available, then the "Add online" right cannot be set. But, the system of rights cannot be called a full-fledged hierarchy. For example, the "Edit" right can only be granted if you have the "View" and "Modify" rights. But you can give "View" without "Change" or "Change" without "View".

An access right is the smallest unit of access. All access control is reduced to giving the user the required set of rights. The rest of the objects (roles, access groups) are just additional binding that serves for grouping and more convenient issuance of access rights.

2. Roles - a mechanism for granting access rights

Consider how exactly granting access rights to the user. For the convenience of issuing access rights in the 1C platform, a special mechanism "Roles"... It is a layer between infobase users and access rights. Each role has a set of access rights, the assignment of which makes sense to perform only at the same time. For example, in the "Read contact information" role, it is logical to combine sets of rights responsible for related directories with contact information... Most in a simple way setting a role to a user is opening the IB user card in the configurator and setting the checkboxes opposite the roles the user needs... This is a versatile method and works in any configuration. However, with the increasing complexity of configurations and the increase in the number of roles, it became quite time consuming. Therefore, in current standard solutions there is an additional layer between the information security user and the roles. This layer is implemented as subsystems "Access control"... It allows you to combine roles into larger entities - "Profiles" and assign a user not separate roles, but profiles containing sets of several roles.

Let's consider the scheme of assigning access rights to users, used in most typical configurations. In a simplified form, it can be represented as follows. New entities are introduced "Access Profile" and "Access group"... Several roles are included in each access profile. And each user is assigned one or more access groups. Next, each access group is associated with an access profile. As a result, we get the ability to specify for the user not just roles, but sets of roles depending on the functions he performs.

From a technical point of view this system the issuance of rights is implemented with the participation of two standard subsystems. The "Access control" subsystem is used to configure the association of access groups with roles predefined in the configuration. The "Users" subsystem is used to configure links between IS users and configuration access groups.

3. "Logic permissions" as a rule of intersection of roles.

It is important to understand that in 1C the general logic of access control is permission logic... In the 1C platform in general there are no mechanisms to deny access... There are only mechanisms granting access... By default, access to all data is denied, and setting up access is to give each user the rights he needs... This means that if a user role is given the right to view the "Sales of goods" documents, then no way can this right be taken away other roles or any other platform and configuration mechanisms. You can initially give not full access to the directory, but filter the data to which we give access using RLS. But if access has already been granted, then it is no longer possible to take it away by other roles.

That is why, when restricting user access to a directory by roles, it is very important to ensure that the user is not assigned any other role for the same directory. Otherwise, the first role will give the necessary access, which the second cannot deny.

The platform has the ability to give the user additional rights for the duration of a single operation. This feature is called "Privileged Mode". It allows the user to perform actions on data that are not available to him. However, the platform does not even have the ability to temporarily reduce the user's existing rights.

4. Indirect access control.

There are separate mechanisms that, although they are not intended directly to control access, are indirectly affected and can be used for additional restrictions. Let's consider their main features.

4.1. Functional options.

An access control system is sometimes referred to as a mechanism functional options... This is not entirely true, as functional options do not affect data access in any way. This is a purely interface mechanism, designed to simplify the interface for the user. It appeared in the 8.2 platform as a result of the complexity of the configuration functionality. Functional options are designed to hide from the interface functionality that is not used in this particular company or by this particular user. The mechanism only affects the display of data. Commands disappear from the interface, and requisites disabled by functional options are hidden on forms. Wherein the user has access to all these commands and details... It can work with hidden data programmatically using processing without any problems.

You can read more about working with functional options on ITS

4.2. RLS (Record Level Security)

All of the above mechanisms affect exactly the provision of access to objects as a whole. To reference books, documents, reference books requisites. Access rights affect access to objects, functional options for displaying objects in the interface. The task often arises of allowing the user to access data in a reference book or document. But not all data, but only a part of them. For example, only allow one organization to access implementation documents.

To configure this permission there is additional mechanism RLS (Record Level Security)... As the name suggests, this access control mechanism is at the level of specific table entries. If access rights give access to tables in general (reference books) or columns of tables (attributes), then RLS defines specific table rows (records) that the user is allowed to work with. It allows you to define the data that is available to the user.

When analyzing this mechanism, you should always remember that RLS is not a deny mechanism... He is the mechanism filtering the issue of access... Those. RLS does not affect the user rights, it is a filter that restricts the issuance of rights. RLS affects only that specific Role - Access Right relationship in which it is specified. And it does not affect the permissions granted by other roles. For example, if one role is allowed access to documents only for Organization1, and the other role allows access to documents for Warehouse1, then as a result the user will have access to all documents in which Organization1 OR Warehouse1 is specified. Therefore, if the user is assigned several roles, then a filter using RLS must be installed in each role in both fields (by organization and warehouse). In typical solutions, this task is usually solved by creating one role in which all possible RLS filters are registered. This role is then assigned to all users working with these directories. It is also controlled that the user does not have access to other roles that contain the right to access restricted documents.

It is also worth noting that RLS filters can be applied not to all possible types of data access, but only to top-level access types... For example, for directories out of the available sixteen types of access, RLS filters can be applied to only four basic ones: Reading, Modifying, Adding and Deleting. This means that we cannot, for example, give the user at the same time the "Change" right without a filter for the ability to work programmatically with any documents and the "Edit" right with the RLS filter by organization for interactive work. If we want the user to be able to edit documents with the RLS filter, we must apply a general filter at the top level "Modify" or "Read".

Taking into account the total complexity of the mechanisms, it is usually quite difficult to figure out what exactly is available to a specific user of a typical configuration. To check the granted rights in typical configurations, there is a very convenient report, which is called that. "Access rights"... It analyzes all the rights granted to the user and displays the summary list of rights granted by all access groups, taking into account the RLS filters.

4.3. Data separation.

Another mechanism that affects data access is data sharing... This mechanism is intended for maintaining several independent bases in one physical database, having a common configuration and common reference books. In some very limited cases, this mechanism can be considered as access control. When enabled, each user can work only in one of his own independent bases, but at the same time use common data.

In a general sense, this mechanism can also be considered a data filter and a special case of RLS implementation. In contrast to RLS, separation is a much more rigid mechanism. And thanks to this rigidity, the developers have the technical ability to use additional indexes to make such filtering without the slowdowns inherent in RLS.

Actually RLS is just extra tackles added automatically to each database query. Splitting data is adding a separator to all partitioned tables and their indexes, including clustered ones. The data is grouped in terms of the separator, i.e. physically reallocated across disk into separate groups for each delimiter value. Thanks to this, each user only works with their own data, and the server does not need to physically view the entire table with each request. It is enough to view only the data area of ​​the current section.

However, precisely because of this physical reallocation of data, when working as a full-fledged user who does not have a filter by separator values, all queries are executed very, very slowly. Full use of indexes is impossible without a separator value, therefore, the amount of data physically read from the disk and processed with each request can increase by orders of magnitude... Accordingly, in reality, the separation makes sense only if all users constantly working in the database will work only within their area.

4.4. Program code.

Perhaps the most versatile way to set additional restrictions is program code... They can influence any platform mechanisms. For example, to restrict access to documents, a developer can add a filter to the form of a list of documents, to a selection form, and can programmatically check the ability to view document data when opening a specific form of a document. The developer can apply a filter in his reports when selecting data.

However, the program code there is no way to restrict the rights in general by configuration... The most a developer can do is build constraints into specific, individual data retrieval mechanisms. Due to the fact that 1C uses an object model for working with data, the program code can be guaranteed to protect the data from being changed by adding the necessary checks to the object module. But the developer cannot fully guarantee that the user will definitely not be able to get information about other people's implementation documents by other reports or processing.

This principle is used, for example, in. By connecting to the configuration, the extension adds custom constraints and checks to all references and documents. It filters the data displayed to users in the lists, checks access when they view or change the data. Ensures that prohibited data cannot be changed. But it cannot filter data in reports or queries.

There are always options for obtaining forbidden data by a request, by your own processing or by a report. Unless it is very strict to limit the list of configuration functionality used by the user and add a separate filter to each mechanism (form, processing, report, request) allowed to the user.

4.5. Comparison of options.

Let's try to briefly compare the considered options for additional data restriction.

5. Results.

Each method of setting limits has its own pros and cons. From the point of view of technology, the most correct way is a competent division into roles. The most reliable way to filter available data is to use RLS. It is for this task that the mechanism is intended. Point constraints are most easily accomplished with code. Functional options and data separation are quite specific mechanisms that are not intended to restrict access. Although in some cases they can be used for this.

Almost all typical solutions on the 1C: Enterprise 8.x platform use the functional options mechanism. It allows you to manage configuration functionality in blocks.

For example, the "Using internal orders" option (see the screenshot on the right) allows you to make this document available for use in the "1C: Enterprise" mode to the user, and also includes separate branches of algorithms associated with this functionality.

Today in the article we will look at how functional options work, how to configure them, and a small example of their use on a test configuration. Let's start by looking at how they work.

Principle of operation

As mentioned above, a functional option allows you to enable / disable the associated configuration functionality. Let's consider the sequence of actions for creating and configuring this configuration object.

In the configuration branch "General-> Functional Options" we can create a new object or see the properties of already created options. In the test configuration, create a functional option "EnableImportance". At the very beginning, when the object has not been configured yet, the window with the list of its properties will look like this:

The Name and Synonym properties have a standard purpose. Of particular interest are the "Storage" and "Composition" settings.

In the "Storage" field, an object in the configuration is selected, from where the functional option will receive its value. Boolean constants are usually used for these purposes. By the value of the constant, the platform will determine whether the associated functionality is included or not.

The configuration options associated with a functional option are configured on the Contents tab. The screenshot above shows a selection list of objects to be included in its composition.

If one configuration object is included in several functional options, then it will be used in the application solution if at least one of them is included.

The "Privileged mode on checkout" option allows you to disable checking of access rights when the value of a functional option is received, which will positively affect performance (unnecessary operations of checking access rights will be excluded) and will reduce the complexity of further development (you do not need to configure rights for an object that stores the value of a functional option ).

Usage example

In our test configuration, we will create an enumeration "Importance", as well as a constant

"IncludeImportance". The created objects are shown in the following screenshot.

The constant is intended to store the value of the functional option. The enumeration will act as the value of the reference variable in the test document, the availability of which will be determined by the functional option.

• "Comment "with type" String ".
• Importance of type EnumerationRef.Importance.

Add the document attribute "Importance" to the functional option and then consider the behavior of the platform in user mode.

After launching the program in "1C: Enterprise" mode, open a test document. We will not see the "Importance" attribute on the form, since we have not yet enabled the functional option.

To enable the use of the "Importance" attribute, set the value of the "IncludeImportance" constant to TRUE. Then the form will change as follows:

Functional options work for almost all configuration objects, with the exception of some of the "General" branch, which perform mainly service functions. For example, you cannot include other functional options in a functional option (and it doesn't make much sense).

Let's consider a few interesting aspects of the operation of this configuration object:

1. Setting up functional options has practically no effect on the SQL queries generated by the platform.

For example, when opening a document with a disabled functional option, the platform in any case receives the value of this attribute in the request. The following screenshot shows SQL queries generated with the option enabled and disabled.

2. The form element "Importance" on the form, regardless of the value of the functional option, always has values ​​for the "Visibility" and "Accessibility" properties equal to TRUE.

Indeed, both when creating a form on the server and when opening a form, as well as during further work with it, the "Visibility" and "Accessibility" properties are not automatically set to FALSE by the platform. Probably 1C: Enterprise 8.x does it "behind the scenes".

3. To obtain the value of a functional option, the platform generates an SQL query to the DBMS in accordance with the storage object, ie. to a constant. In one of the previous articles, we already talked about building SQL queries to constants and how they are stored in the database.

In our example, the platform generates the following SQL query:

As for the moment of obtaining the value of a functional option, the platform is guided by the following principle : the first receipt of the value of a functional option occurs when accessing an object / attribute that is part of it. In the future, the platform uses the cached value until the value of the object that stores this value is changed (in our example, the "EnableImportance" constants) or the user session is restarted. The value of the functional option is cached in a separate session.

All of the above was checked experimentally. Everything that I used for experiments is in the test configuration (link at the end of the article), except for.

Output

Functional options are an integral part of almost any production solution based on the 1C: Enterprise 8.x platform. It is thanks to this mechanism that you can create configurations with a block-based structure of functionality that can be easily turned on / off when setting up the program. In this case, the capabilities of the mechanism can be expanded by using the parameters of functional options, but this is a topic for another article.

For experience with the platform, you rarely have to use functional options, since the customer knows exactly what he needs. And it is very rare to create some kind of universal mechanisms for which you will have to pay extra, plus the fact that they will be used is very rare when finalizing standard solutions or implementing them at a particular enterprise.

Downloads:

Object 1c "Functional options" - designed to highlight functionality in an applied solution that can be enabled (disabled) during implementation without changing itself (together with the Subsystems, they form the 1C thin client interface). They are part of the functional options mechanism.

Functional options mechanism includes two metadata objects:

1. Functional option;
2. Functional option parameters.

More details

Functional option is a metadata object that can directly affect the composition of the application interface (if the functional option stores its value in a Boolean attribute). With objects of this type, you can hide items that are not available functionality. For example, the Currency accounting option can hide Currencies, the Currency from field, and the Currency amount column from reports.

The source of the value of the functional option is the metadata object selected as the Storage property, for example, it can be.

If the value of a functional option is stored in a reference book attribute or resource, additional information is required that indicates how to select the option value. A separate metadata object is provided for this purpose - Functional Option Parameters.

We can say that the parameters of functional options are the coordinate axes of the space of values ​​of functional options. Moreover, one parameter of functional options can determine the value of its "own" coordinate axis simultaneously for a variety of functional options.

[collapse]

Functional options can influence:

1. to the user interface:
   • global;
   • requisites (including the columns of the props of the form type Table of Values or Value Tree);
   • form commands;
2. for reports implemented using the data composition system;
3. to algorithms written in the embedded language - it is possible to obtain the values ​​of functional options from the embedded language and use them in various conditions, for example, to reduce the amount of computation (see, for example,).

ATTENTION! If a client application works with a file-based infobase via a web server, then changing the functional option will change the user interface only after restarting the web server (restarting the client application will not change the user interface).

Properties of 1C Functional Options

• Storage is a field in which you need to select an object with a boolean type. Typically, constants are used.
• on receipt - the flag is responsible for the ability to get the value of a functional option in privileged mode.
• Composition - a list of objects and object attributes, the visibility of which is turned on / off when the functional option is turned off / off (will be controlled using a managed form).

For example, depending on the conditions of a specific implementation, you can provide for disabling accounting of goods by warehouses so that when registering goods receipt documents, the Warehouse field is not displayed in the document form.

Features of using Functional options 1C:

1. Functional options can be of arbitrary type (not necessarily Boolean).
2. When adding a new constant to use a functional option, be sure to include it in the appropriate subsystem and assign rights to it.
3. Working with functional options is available from the built-in language, thanks to which the developer can create his own algorithms for the values ​​of functional options.
4. The command of the command interface will be excluded from the command interface if the functional option is disabled:
   • an attribute that is a command parameter;
   • the type of the command parameter (if the type of the command parameter is composite, the command becomes unavailable when all types of the parameter are disabled).

ATTENTION! Functional options and their parameters do not affect the composition of the database: all tables and fields are present in the database, regardless of the state of the functional options.

Influence of functional options on attributes and commands of the form:

1. managed form type<Вид>An object ( ReferenceObject, DocumentObject, etc.) will be disabled if the corresponding object is disabled by the functional option. Only those functional options that have no parameters are analyzed.
2. Main props of a managed form type Dynamic List will be disabled if the functional option disabled the configuration object, which is specified as the main table of the dynamic list. Only those functional options that have no parameters are analyzed.
3. A form attribute of a reference type is disabled if the configuration object that forms this type is disabled by a functional option. A composite type attribute of a form is disabled if functional options disable all constituent types.
4. A form table will be disabled if it displays data from a form attribute disabled by a functional option.
5. There are no types in the type selection dialog (for example, for input fields associated with complex type attributes), if the configuration objects that form these types are disabled by the functional option. Information about types disabled by functional options is cached on the client side and cleared after 20 minutes or during a method call UpdateInterface ().

ATTENTION! Unlike the command interface, the values ​​of the parameters of functional options are set only for a specific instance of the form.

Creating a Functional Options Parameter

A functional option parameter is created using the 1C configuration object "Functional option parameters".

[collapse]

This can be done in the configuration window by adding a new object.

Functional options parameter properties:

• Usage - sets a set of objects whose values ​​will determine how the value of the functional option should be selected. The list of available objects includes directories and information register dimensions. For each parameter of functional options in this list, you can select one directory (from the entire list of directories) and one dimension of each information register.

ATTENTION! You cannot use the same metadata object in multiple functional option parameters.