Object 1c "Functional options" - designed to highlight the functionality in the application 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.

Function Options Mechanism includes two metadata objects:

1. Functional option;
2. Functional options parameters.

More

Function 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 the help of objects of this type, you can hide elements that relate to inaccessible functionality. For example, the Currency accounting option can hide Currencies, the Currency from field, the Currency amount column from reports.

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

In the case of storing the value of a functional option in a directory attribute or resource, additional information is required that indicates exactly how to select the option value. A separate metadata object is provided for this purpose − Function Options 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" coordinate axis simultaneously for a plurality of functional options.

[hide]

Functional options may affect:

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

ATTENTION! If the client application works with the file version of the infobase through the 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 - a field in which you need to select an object with the boolean type. As a rule, constants are used.
• when getting - the flag is responsible for the possibility of obtaining the value of the functional option in the privileged mode.
• Composition - a list of objects and attributes of objects, the visibility of which is turned on / off when the functional option is turned off / off (to be controlled using a managed form).

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

Features of using 1C Functional Options:

1. Function options can have values ​​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 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 function option is disabled:
   • attribute, which is a command parameter;
   • the type of the command parameter (if the type of the command parameter 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 the details and commands of the form:

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 have no parameters are parsed.
2. The main attribute of the 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 have no parameters are parsed.
3. A form attribute of a reference type is disabled if the configuration object that forms that type is disabled by a functional option. The form attribute of a composite type is disabled if the functional options disable all component types.
4. The form table will be disabled if it displays the data of 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 composite type attributes) 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 parameter values ​​of functional options are set only for a specific form instance.

Creating a Functional Options Parameter

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

[hide]

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

Function 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 dictionaries and dimensions of the information register. 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 more than one function option parameter.

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

So, for example, the "Use 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 related to this functionality.

Today in the article we will look at the operation of functional options, their settings 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, the functional option allows you to enable / disable the configuration functionality associated with it. Let's consider the sequence of actions for creating and configuring this configuration object.

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

Properties "Name" and "Synonym" 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. Usually boolean type constants are used for this purpose. By the value of the constant, the platform will determine whether to include the related functionality or not.

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

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

The "Privilege mode on getting" option allows you to disable access rights checking when getting the value of the functional option, which will positively affect performance (excessive access checking operations will be eliminated) and reduce the complexity of further development (no need to configure rights for the object that stores the value of the functional option ).

Usage example

In our test configuration, let's create an "Importance" enumeration, as well as a constant

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

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

The test document will have two requisites:

• "Comment" with type "String".
• "Importance" with type "EnumerationReference.Importance".

Let's add the document attribute "Importance" to the functional option and then consider the behavior of the platform in the user mode.

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

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

The operation of functional options extends to almost all configuration objects, with the exception of some of the "General" branch, which mainly perform service functions. For example, you cannot include other functional options in the composition of a functional option (and this does not make much sense).

Let's take a look at a few interesting aspects of how this configuration object works:

1. Setting functional options has almost 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 the 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 the values ​​for the properties "Visibility" and "Accessibility" equal to TRUE.

Indeed, both when creating a form on the server, and when opening the 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 get the value of the functional option, the platform generates an SQL query to the DBMS in accordance with the storage object, i.e. 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 receiving the value of the functional option, the platform is guided by the following principle : the first receipt of the value of a functional option occurs when accessing the object/props included in its composition. The platform then 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 a functional option is cached within a single session.

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

Conclusion

Functional options are an integral part of almost any circulation solution based on the 1C:Enterprise 8.x platform. It is thanks to this mechanism that you can create configurations with block construction of functionality, which can be easily enabled / disabled when configuring the program. At the same time, the capabilities of the mechanism can be extended by using the parameters of functional options, but this is a topic for another article.

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

Downloads:

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

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

Why might you need to disable functionality?

Get 267 1C video lessons for free:

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

What do functional options control?

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

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

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

To do this, a functional option can be defined in the configuration Warehouse accounting, stored in a constant of type boolean.

You can associate various configuration objects or their attributes with this functional option. For example, you can associate props 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 Goods receipt.

30.03.2017

Functional options 1C 8.3 (Mechanism, use)

To start important note that the function options mechanism NOT restricts access to data, but only controls the visibility (display) of data on the form. To restrict access to objects in the platform, the mechanism of roles is used.
Therefore, we begin our consideration of the mechanism of functional options with a description of the problem. In our mini-configuration, there is one directory "Warehouses". Assume that all users have access to this directory.
Again! The mechanism of functional options controls the display of data on the form, and does not restrict access to the metadata object (Directory, document, registry entries ....) It is necessary to make the setting "Use multiple warehouses" (Yes, yes ... It's in UT 11.X, it's done there for organizations). If we use several warehouses, then the warehouses directory is available in the interface, if not, then the command that opens one warehouse (we assume that there is only one in this case, and we do not complicate the task).

Configuration Metadata Objects

To accomplish this task, we need:

• Two functional options "UseMultipleWarehouses" and "Do NotUseMultipleWarehouses". The first is responsible for the availability of the directory, and the second for the availability of the general command to call the algorithm for "opening" the warehouse
• Constants of the same name with the "Boolean" type for storing the values ​​of functional options
• Directory "Warehouses"
• General command "Open Main Warehouse". Do not forget to specify a group of commands for it, otherwise do not apply the configuration (there will be an error)

And add one subsystem where we include all the existing objects

Setting functional options

The first option is "Use Multiple Warehouses". The value is stored in the constant of the same name, the "Warehouses" directory is included. Thus, when the value of the constant is "True" the directory is available in the interface, when false, the directory will not be displayed in the interface either (Contents of subsystems, object forms, etc.)

The second function "Don't UseMultipleWarehouses" is set when the first "UseMultipleWarehouses" is NOT set.
Those. if we do not use multiple warehouses (UseMultipleWarehouses = FALSE and the "Warehouses" lookup is not available), then the command "Open MainWarehouse" is displayed, the availability of which is controlled by the option "Do not UseMultipleWarehouses" (Do notUseMultipleWarehouses = TRUE)

Checking system behavior

Option number 1. UseMultipleWarehouses = True, Do NotUseMultipleWarehouses = False. The "Warehouses" directory is available in the interface

Option number 2. UseMultipleWarehouses = False, Do NotUseMultipleWarehouses = True. The reference book "Warehouses" is NOT available in the interface, instead the general command "Open Main Warehouse" is available