Functional options And Functional option parameter- these are 1C 8.3 (8.2) configuration objects, which together represent a mechanism for functional options. The functional options mechanism is a functionality that allows you to determine the set of functionality that users need.

Simply put, the functional options mechanism is an on/off switch for various functionality in a configuration.

Why might you need to disable functionality?

Get 267 video lessons on 1C for free:

Often, additional functionality can complicate the work of employees. A trivial example of using functional options in 1C - the database keeps records for one organization or warehouse, then why oblige the user to fill out this data in all documents?

What do the functional options control?

First of all, the use of functional options is most conveniently reflected in the interface: form details, command forms, general interface - all this can be associated with functional options. Depending on the value of the functional options, you can limit the display of data in a report built on the basis of .

1. Access rights.

In fact, everything is very simple. In 1C by default everything that is not permitted is prohibited. Eat only one entity responsible for access user to any functionality or data. This entity is called "Access right". She happens to be the only one an element responsible for access to a specific operating mode, directory, details....

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 entire system access rights to platform mechanisms, responsible for access to certain operating modes of the platform (Administration, Exclusive mode, Thin client, Interactive opening of external reports....). AND object permissions, allowing you to work with various configuration objects. Their number depends on the type of configuration object. For example, the directory has 16 different types of access (Read, Add, Change, Delete....). There are only five types of access for the information register. All these rights can only be set at the directory level as a whole. You can also restrict access at the credential level. But in this case, only a part of the types of rights are available (for directories these are View and Edit rights).

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

Let's consider access rights to the directory. This diagram shows that most rights are clarifications of more general rights. If Right1 is completely located on the diagram inside the rectangle of another Right2, then Right1 cannot be issued without issuing Right2. The most common right is the "Read" right. If the Read right is not available, then all other rights are not available. If the "Add" right is not available, then the "Interactive Add" right cannot be set. However, the system of rights cannot be called a full-fledged hierarchy. For example, the "Editing" right can only be given if you have the "View" and "Edit" rights. But you can give "View" without "Change" or "Change" without "View".

An access right is the minimum unit of access. All access control comes down to issuing the user the required set of rights. The remaining objects (roles, access groups) are simply additional bindings that serve for grouping and more convenient issuance of access rights.

2. Roles - a mechanism for granting access rights

Let's look at how exactly it's done granting the user access rights. For the convenience of issuing access rights in the 1C platform, a special "Roli" mechanism. It is a layer between information base users and access rights. Each role combines a set of access rights, the assignment of which makes sense 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 the role to the user is opening the information security user card in the configurator and checking the boxes next to the roles the user needs. This is a universal method and it works in any configuration. However, with the increasing complexity of configurations and the increase in the number of roles, it has become quite labor-intensive. Therefore, in current standard solutions there is an additional layer between the information security user and the roles. This layer is implemented in the form "Access Control" subsystem. It allows you to combine roles into larger entities - “Profiles” and assign the user not individual roles, but profiles containing sets of several roles.

Let's consider the scheme for 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". Each access profile includes several roles. And each user is assigned one or more access groups. Each access group is then associated with an access profile. As a result, we get the opportunity to specify not just roles for the user, but sets of roles depending on the functions he performs.

From a technical point of view, this system for issuing rights is implemented with the participation of two standard subsystems. The "Access Control" subsystem is used to configure the connection of access groups with roles predefined in the configuration. The "Users" subsystem is used to configure connections between information security users and configuration access groups.

3. “Permission logic” as a rule for the intersection of roles.

It is important to understand that in 1C the general access control logic is permission logic. In the 1C platform in general there are no access denial mechanisms. There are only mechanisms issuing access. By default, access to all data is denied, and setting up access consists of issuing each user the rights he needs. This means that if some role gives the user the right to view documents “Sales of goods”, then this right cannot be taken away in any way other roles or any other platform and configuration mechanisms. You can initially not give 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 can no longer be taken back by other roles.

That is why, when limiting user access to a directory by roles, it is very important to check that the user is not assigned any other role to 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 while performing a separate operation. This feature is called Privileged Mode. It allows the user to perform actions on data that is not available to him. However, the platform does not have the ability to even temporarily reduce the user’s rights.

4. Indirect access control.

There are separate mechanisms that, although not directly intended to control access, influence it indirectly and can be used for additional restrictions. Let's look at 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, since 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 platform 8.2 as a result of more complex configuration functionality. Functional options are intended to hide from the interface functionality not used by this particular company or by this particular user. The mechanism only affects the display of data. Commands disappear from the interface, and details disabled by functional options are hidden on forms. Wherein the user still 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 the mechanisms listed above affect the provision of access to objects as a whole. To reference books, documents, reference details. Access rights affect access to objects, functional options affect the display of objects in the interface. Often the task arises of allowing a user access to directory or document data. But not to all the data, but only to part of it. For example, allow access to implementation documents for only one organization.

There is an additional mechanism to configure this resolution RLS (Record Level Security). As the name suggests, this access control mechanism is at the level of specific table records. If access rights provide access to tables as a whole (directories) or table columns (details), then RLS determines specific table rows (records) with which the user is allowed to work. It allows you to determine the data that is available to the user.

When analyzing this mechanism, you should always remember that RLS is not an access denial mechanism. He is the mechanism access issuance filtering. Those. RLS does not affect the user's rights; it is a filter that limits the issuance of rights. RLS affects only the specific “Role” - “Access Right” connection in which it is registered. And does not affect access rights granted by other roles. For example, if one role allows access to documents only for Organization1, and another role allows access to documents for Warehouse1, then the user will eventually have access to all documents that indicate Organization1 OR Warehouse1. Therefore, if a user is given several roles, then a filter using RLS must be installed in each role for both fields (by organization and warehouse). In standard 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 other roles available that contain the right to access restricted documents.

It’s also worth noting that RLS filters can’t be applied to everything. possible types access to data, but only to top level access types. For example, for directories, out of the sixteen available types of access, RLS filters can be applied to only four main ones: Reading, Modifying, Adding and Deleting. This means that we cannot, for example, give the user simultaneously the “Edit” right without a filter for the ability to work programmatically with any documents and the “Edit” right with an RLS filter by organization for interactive work. If we need the user to be able to edit documents with an RLS filter, we are required to impose a general filter at the top level of "Edit" or "Read".

Given the overall 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 "Access rights". It analyzes all rights granted to the user and displays the final list of rights issued by all access groups, taking into account RLS filters.

4.3. Data separation.

Another mechanism that affects data access is data separation. This mechanism is designed to maintain in one physical database several independent databases that have a common configuration and common directories. In some very limited cases, this mechanism can be considered access control. When enabled, each user can work only in one of their independent databases, but use common data.

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

Actually RLS is just additional selections, added automatically to every database query. Splitting data is adding a separator into all partitioned tables and their indexes, including the clustered one. The data is grouped according to the separator, i.e. physically redistributed across the disk into separate groups for each separator value. Thanks to this, each user works only with his own data, and the server does not need to physically scan the entire table with each request. It is enough to view only the data area of ​​the current partition.

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

4.4. Program code.

Perhaps the most universal 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 document list form, to the selection form, and can programmatically check the ability to view document data when opening a specific document form. The developer can apply a filter in his reports when selecting data.

However, the program code there is no way to limit rights as a whole by configuration. The most a developer can do is to build restrictions into specific individual data retrieval mechanisms. Due to the fact that 1C uses an object model for working with data, program code can guarantee data protection from modification, adding the necessary checks to the object module. But the developer cannot fully guarantee that the user will definitely not be able to obtain information about other people’s implementation documents through other reports or processing.

This principle is used, for example, in. By connecting to the configuration, the extension adds custom restrictions and checks to all reference books and documents. It filters the data displayed to users in lists, checking access when viewing or changing data. Ensures that prohibited data cannot be changed. But it cannot filter data in reports or queries.

There are always options for obtaining prohibited data by request, own processing or report. Unless you very strictly 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 limitation.

5. Results.

Each method of setting restrictions has its pros and cons. From a technology point of view, the most correct way is to correctly divide it into roles. The most reliable way to filter available data is to use RLS. It is for this task that the mechanism is designed. Point constraints are easiest to implement using 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.

Functional options are common configuration objects. They are part of the functional options mechanism and allow you to select functionality in an application solution that can be turned on/off during implementation without changing the application solution itself.

For example, depending on the conditions of a specific implementation, it is necessary to disable the accounting of goods by warehouse. So that when preparing documents for receipt of goods, the field Stock was not displayed in the document form.

For this purpose, a functional option can be defined in the configuration Warehouse accounting, stored in a type constant Boolean.

Various configuration objects or their details can be associated with this functional option. For example, you can associate the attribute with this functional option Stock document Receipt of goods.

Then, during implementation, you can enable or disable this functional option in a specific infobase in 1C:Enterprise mode.

The platform will automatically turn on and off the display of all relevant interface elements (fields, commands, list columns, report elements). In our case, the field will be hidden or displayed Stock in all document forms Receipt of goods.

With the release of the 1C:Enterprise 8.2 platform, a new object appeared in the configuration tree - "Functional options". It is actively used in all standard configurations based on managed forms, and serves to simplify the process of displaying individual details and objects in the interface. For example, in your configuration there is a module for exchanging with external web services. This module uses a number of details in documents, registers and individual components in subsystems. The module is optional and not necessary for every company. It is logical that since not everyone needs a module, then it is also not always necessary to display all elements/fields associated with it.

In older versions of the platform, solving such problems required writing additional code, which had to be called in all dependent areas. For example, if we needed to hide certain form details (depending on the setting value), then we needed to call the corresponding code when opening the form. This was not very convenient and in most cases the developers gave up on such things.

It’s good if you only need to hide fields in the form of documents, but we can also have register forms with which user interaction is also possible. Writing a universal display control function is quite difficult and will require additional time, which is never enough.

Functional options are designed to solve this and many other difficulties associated with displaying interface elements/the composition of available objects in the user interface. In this note, I will not consider examples of using the main purpose of functional options, but will draw attention to their use in a non-standard way. It may be familiar to many advanced developers, but I came to this method completely by accident. More precisely, it was inspired by the practice of programming in JavaScript.

Case No. 1: a functional option as a wrapper over other objects

The first non-standard feature of functional options is the ability to create wrappers. Let's consider the most simplest example– constants. For example, you add a new constant to a configuration with a huge number of user roles. In order for users to access the value of a constant, you need to set read rights to the appropriate roles. If the rights are not set, then users will not be able to get its value. If there are many roles and they are not inherited from the base role, then you will have to spend time checking the appropriate boxes.

A function option can solve this problem more elegantly. The idea is this: create a constant (for example, ). We do not assign rights to it. Create a functional option of the same name and indicate it in the property "Storage" indicate a constant "Data Saving Possibility". We also set the flag "Privileged treatment upon receipt".

That's it, now anywhere in the code where you need to refer to a constant we write like this:

Since we have set the option to privileged mode, we do not need to specify any additional rights for the constant. Of course, there is no need to apply this technique in all conceivable and inconceivable situations. Remember competent arrangement rights are the key to peace. Use the trick only in truly necessary cases.

Case No. 2. Additional level of abstraction

I don’t know what to call this method more correctly, but in my mind it sounds exactly like that. Let's look at the previous example. We still have the same constant “Ability to save data”. We work with it using the functional option of the same name as a wrapper.

Now imagine that we wanted to get rid of the constant and switch to using a directory. A typical scenario for solving such a problem (if we are using only a constant) would be to run a global search tool in order to detect access to the constant. Let me remind you that if we do not use a functional option as a wrapper, then we should treat the constant like this:

Constants.Ability toSaveData.Get();

We find all the calls and replace them with the path to the new storage object. Agree, this is quite inconvenient. If we used the previous case (using a functional option as a wrapper), then to “move” we only need to go to the properties of the functional option and change the property "Storage". For example, indicate there "Directory" or "Register of information". No games with global search are required. The code for accessing the value of a constant through a functional option will remain the same:

GetFunctionalOption("DataSavingAbility");

Object 1c "Functional options" - are intended to highlight functionality in an application solution that can be turned on (off) during implementation without changing itself (together with 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 options parameters.

More details

Functional option represents a metadata object that can directly influence the composition of the application interface (if the functional option stores its value in a Boolean attribute). Using objects of this type, you can hide elements that are related to unavailable 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 a functional option is the metadata object selected as the Storage property, for example it could be .

If the value of a functional option is stored in a directory attribute or resource, additional information is required that indicates exactly how to select the option value. For this purpose, a separate metadata object is provided - Functional Options Parameters.

We can say that the parameters of functional options are the coordinate axes of the value space of functional options. Moreover, one parameter of functional options can determine the value of “its” coordinate axis simultaneously for many functional options.

[collapse]

Functional options may have an impact:

1. to the user interface:
   • global ;
   • details (including columns of form details like Table of Values or ValueTree);
   • form commands;
2. on reports implemented using a data composition system;
3. to algorithms written in a built-in language - it is possible to obtain the values ​​of functional options from the built-in language and use them in different conditions, for example, to reduce the amount of calculations (see, for example,).

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

Properties of Functional Options 1C

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

For example, depending on the conditions of a particular implementation, it is possible to disable the accounting of goods by warehouse so that when registering documents for goods receipt, the Warehouse field is not displayed in the document form.

Features of using 1C Functional Options:

1. Functional options can have values ​​of any type (not necessarily Boolean).
2. When adding a new constant to use a function option, be sure to include it in the appropriate subsystem and assign permissions 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 interface command will be excluded from the command interface if the functional option is disabled:
   • an attribute that is a command parameter;
   • command parameter type (if the command parameter type is compound, then the command becomes unavailable when all parameter types 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 form details and commands:

1. managed form type<Вид>An object ( DirectoryObject, DocumentObject, etc.) will be disabled if the corresponding object is disabled by the functional option. Only those functional options that do not have parameters are analyzed.
2. Basic attributes of a managed form type DynamicList will be disabled if the functional option disables the configuration object that is specified as the main table of the dynamic list. Only those functional options that do not have parameters are analyzed.
3. The form attribute of a reference type is disabled if the configuration object that forms this type is disabled by a functional option. The form attribute of a composite type is disabled if the functional options disable all constituent types.
4. A form table will be disabled if it displays form attribute data that is disabled by a functional option.
5. There are no types in the type selection dialog (for example, for input fields associated with attributes of a complex type) if the configuration objects that form these types are disabled by a 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 functional options parameters 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 up a set of objects whose values ​​will determine how the value of a functional option should be selected. The list of available objects includes directories and information register dimensions. For each functional options parameter 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.