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 ....) You need 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 warehouse 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 do not complicate the task).

Configuration Metadata Objects

To accomplish this task, we need:

• Two functional options "UseMultipleWarehouses" and "Don'tUseMultipleWarehouses". 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

Functional Options Setting

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

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 attributes, 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 required by every company. It is logical, since not everyone needs the module, then it is also not always necessary to display all the elements / fields associated with it.

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

Well, if you want to hide only the fields in the form of documents, but we can still have forms of registers with which user interaction is also possible. Writing a generic display control function is quite difficult and will require extra time, which is never enough.

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

Case #1: functional option as a wrapper over other objects

The first non-standard feature of functional options is the ability to create wrappers. Consider the 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 the constant, you need to set the corresponding roles to read permissions. 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.

The functional option can solve this problem more elegantly. The idea is as follows: we create a constant (for example, ). We do not assign rights to it. We create a functional option of the same name and specify it in the property "Storage" specify a constant "Ability to Save Data". We also set the flag "Privileged Mode on Receive".

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

Since we set the option to privileged mode, no additional rights need to be specified for the constant. Of course, it is not necessary to apply this technique in all cases of conceivable and unthinkable situations. Remember, a competent arrangement of rights is the key to peace of mind. Use the trick only when absolutely necessary.

Case number 2. Additional level of abstraction

I don’t know how to properly call this method, but in my opinion it sounds exactly like that. Consider 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 reference book. A typical scenario for solving such a problem (if we use only a constant) would be to run a global search tool in order to find a reference to the constant. Let me remind you that if we do not use a functional option as a wrapper, then we must refer to a constant like this:

Constants.DataSaveAbility.Get();

We find all the calls and replace it with the path to the new storage object. Agree, it's pretty 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, put there "Directory" or "Register of Information". No games with a global search are required. The code for accessing the value of a constant through a function option will remain the same:

GetFunctionOption("DataSavePossibility");

Print (Ctrl+P)

1. Purpose of functional options

Functional options allow the developer to describe the capabilities of the application solution, which can be quickly enabled or disabled at the implementation stage and/or during system operation. For example, the ability to work with additional product properties can be separated into a separate functional option. Then, if you disable this feature, all related (with additional product properties) features will “disappear” in the interface of the applied solution.
The system is able to automatically take into account the status of the settings made - to hide disabled features, making the application interface more clear and understandable to the user.
During development, situations arise when the value of a functional option should depend on certain parameters, for example, not all organizations maintain currency accounting. To implement such a dependency, use the Parameters of functional options - objects that parameterize functional options.

2. What functional options affect

2.1. general information

Functional options may affect:
● On the user interface - when you turn off any functional options, the system hides all elements related to it in the user interface. This affects the following interface elements:
● global command interface;
● form attributes (including form attribute columns of the ValueTable or ValueTree type);
● form commands;
● reports implemented using the data composition system.
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).
● Algorithms written in the 1st language – it is possible to get the values ​​of functional options from the 1st language and use them in various conditions, for example, to reduce the amount of calculations.
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.

2.2. Global command interface

The effect of functional options on the global command interface is that the system hides the commands of all objects related to disabled options. For example, if the value of the Purchases functional option is set to False , then the commands for opening the Purchases section, creating a Goods Incoming document, opening the Goods Incoming list, etc. will be hidden.
In turn, the Purchasing option can take into account the value of a functional option parameter, for example, Organization. By changing the value of this parameter using the methods of the built-in language, it is possible to change the state of the functional option, and, consequently, the visibility of the interface element.
You should also consider the following features of the formation of the command interface:
● The command will be excluded from the command interface if the attribute, which is a command parameter, is disabled by a functional option.
● The command will be excluded from the command interface if the command parameter type is disabled by a function option. If the command parameter type is compound, then the command becomes unavailable when all parameter types are disabled.

2.3. Form

In a form, functional options can affect form attributes and commands and (as a result) change the visibility of associated form elements (fields and columns for form attributes, buttons for form commands). When developing a form, it is necessary to take into account the following features of the system behavior:
<Вид>An object ( DirectoryObject m, DocumentObject, etc.) will be disabled if the corresponding configuration object is disabled by a functional option. Only those functional options that have no parameters are parsed.
● The main attribute of the type managed form 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.
● 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 component types.
● Disables form type props<Вид>An object (including the main form attribute), if the configuration object that constitutes this type is disabled by a function option. Only those functional options that have no parameters are parsed.
● The form table will be disabled if it displays the data of a form attribute disabled by a functional option.
● There are no types in the type selection dialog (for example, for input fields associated with attributes of a composite 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 parameter values ​​of functional options are set only for a specific instance of the form.

2.4. Data composition system

The data composition system is mainly used for building reports. Functional options affect the composition of the data that is displayed in the report, and the composition of the report settings available to the user. For example, if the functional option is disabled Currency accounting, then in the report that displays the register of documents Goods receipt, there will be no column Currency and Currency amount, and in the settings there will be no possibility of selection, grouping, sorting, etc. by the field Currency.

2.5. Characteristics

Functional options affect the visibility of form fields that display the value of an object characteristic. To do this, it is necessary to include in the functional option an attribute that stores the value of the characteristic.
Consider an example. Characteristics are used for the Goods directory, types of characteristics are stored in the plan of types characteristics Characteristics, and the values ​​as a resource of the information register ValuesCharacteristics. The resource is part of the functional option AccountingCharacteristics.

Rice. 1. Effect of functional options on performance

In case of deactivation of the functional option AccountingCharacteristics in the forms, the visibility of the fields (column Value and field Value ), displaying the values ​​of characteristics, is turned off, as shown in Fig.1.

3. General scheme of work

The functional options mechanism includes two types of metadata objects: Function option And .
A functional option is a metadata object that can directly affect the composition of the application interface (if the functional option stores its value in an attribute of type Boolean ). 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 the Currencies lookup, the Currencies field from documents, 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, this
may be a constant.
If the value of a functional option is stored in a directory attribute or information register 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.

Rice. 2. Parameterizable functional option

Consider an example: let's say total accounting depends on a warehouse owned by a particular organization (see Figure 98). In our information base
you can keep records on behalf of different organizations and in different warehouses.
To store the values ​​of functional options, we will create a register of information, where the dimensions (coordinate axes) will be:

● Organization (appropriate type);
● Warehouse (appropriate type).

The resource of the information register will be the value of the functional option of total accounting.
Then the general structure of the configuration will look like this:
● Information register Sum Accounting:
● Organization dimension;
● dimension Warehouse;
● the resource Total Accounting of the Boolean type.
● Functional options parameter Organization . The Usage property points to the dimension Organization of the information register SumAccounting.
● Functional options parameter Warehouse . The Usage property points to the Information Register Warehouse Sum Accounting dimension.
● Functional option Total Accounting. The Storage property points to the SumAccounting information register resource SumAccounting.
As a result, in order to determine the need for total accounting, we need to specify the values ​​of the parameters of the functional options (Organization and Warehouse) in each specific case and get the value of the functional option.
So, in the example shown in Fig. 2, for Organization 1 and Warehouse 1, total accounting is allowed, and for Organization 2 and Warehouse 1, total accounting is prohibited.

4. Interaction with other objects

Functional options can be assigned to the following configuration objects:
● Subsystems,
● General commands,
● General forms,
● Constants,
● Selection criteria,
● Handbook,
● Document,
● Magazine,
● Chart of accounts,
● Plan types of characteristics,
● Plan of settlement types,
● Business process,
● Task,
● Exchange plans,
● Report,
● Processing,
● Accumulation register,
● Information register,
● Accounting register,
● Calculation register,
● Team,
● Attribute of the metadata object,
● Tabular part,
● Details of the tabular section,
● Sign of accounting,
● Subconto accounting sign,
● Addressing details,
● Register measurement,
● Register resource.
Also, functional options can affect the visibility of form elements.

5. Creation

5.1. Creating a functional option

In order to create a functional option, you need to create a configuration object Functional option. This can be done in the Configurator mode in the usual way, that is, in the configuration window, select the General item, then Functional options and add a new object.

Rice. 3. Creating a functional option

This will create a Functional Option configuration object that can be used to assign functional options to other metadata objects.

Rice. 4. Storing the value of a functional option

In addition to the name, the object has a mandatory property - Storage. In the editor, you can select one of the objects for it, which will be the source of the option value. The list of available objects includes:
● constants,
● details of directories,
● information register resources.
There is no restriction on the source type of the option value, but only those functional options that store their values ​​in attributes of the Boolean type are suitable for interface control. Function option values ​​with other types are only available for parsing in 1C:Enterprise.
The Privileged Mode on Get property determines how the function option value is retrieved (and cached).

Rice. 5. Privileged mode when getting the value of a functional option

If this property is set, then the value of the function option is obtained in privileged mode. The resulting value is cached for all sessions associated with this infobase.
If the Privileged Mode on Get property is cleared, then getting the value of the functional option is done in normal mode.
Caching is done for the current session. Both the value (if it was possible to get it) and the sign of the impossibility of obtaining the value (in the event that the value could not be obtained) are cached.
The cache is flushed when session parameter values ​​change.
ADVICE. It is recommended to set the Privileged Mode on Get property for all cases where the value of a functional option does not contain sensitive information.

5.2. Creating a Functional Options Parameter

In order to create a functional option parameter, you need to create a configuration object Function Options Parameters. This can be done in the Configurator mode in the usual way, that is, in the configuration window, select General, then Function Options Parameters and add a new object.

In addition to the name, the parameter has the required Usage property. It specifies 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.

6. Usage

6.1 Assigning metadata to objects

A metadata object (for example, a directory) can be attributed to one or more functional options. To do this, use the Functional options property, which contains links to the functional options created in the configuration.

Rice. 6. Assigning a functional option to an object

The list of available options is limited only to those options for which an object with a value type of Boolean is assigned in the Storage property.
ATTENTION! If no functional option is assigned to an object, then it is always considered visible. IN otherwise an object is considered visible if at least one of the function options assigned to it is enabled (i.e., the function options are ORed together).

6.2. Assigning form details and commands

Objects belonging to the form (Attributes and Commands) can also be used in the functional options mechanism.

Rice. 7. Assigning a Function Option to a Command

You can do this in the form editor by setting the Functional options property for the required object.
The state of the functional options will affect the display of form objects in the same way as it does with metadata objects.
For example, in the case of a command disabled by a functional option, all buttons associated with it will be removed.
If no functional option is assigned to a form attribute or command, then the form attribute or command is considered always visible. Otherwise, the form attribute or command is considered visible if at least one of the functional options assigned to it is enabled.

6.3. Use in the data access restriction mechanism

Under the conditions of the data access restriction mechanism Functional Options can be used in the same way as Session Options. It is permissible to use only options that do not depend on parameters, that is, those that are bound to constants.
ATTENTION! The system controls the uniqueness of names between session parameters and functional options.

6.4. Determining the Function Option Value

The value of the functional option is determined by the object specified in the Storage property. In the case of a constant, its value is used. For an option associated with a directory attribute or information register resource, the values ​​stored in these objects. In order to find a specific object that stores the value of the functional option, additional information is needed - a set of parameter values ​​of the functional options.
If the option is stored in a directory attribute, the parameter must contain a link to a specific element of the directory. If the option is stored in an information register resource, the values ​​of all dimensions of the register must be specified. In this case, each measurement must be characterized by its own parameter.
If not all parameters are specified for a functional option of the Boolean type, then the addition “by OR” of all values ​​with no parameters is performed. For example, if a feature option is stored in a detail register with dimensions Organization and Warehouse, and only the dimension Organization is specified, then the value of the feature option will be True if at least one of the warehouses listed in the dimension Warehouse has the value of the feature option set to True.
For a functional option that is of type other than Boolean , an incomplete parameterization situation results in an exception being thrown.
The built-in language methods allow you to get the value of the option, both depending on the parameters passed, and for the parameters set
for command interface or specific form. In the case when changing the value of the object specified in the property of the functional option Storage is performed in a transaction, the actual value of the functional option will be changed only after the completion of the transaction. While the transaction is open, the value of the functional option will be equal to the value that is relevant at the moment the transaction starts.
If a functional option is bound to a periodic information register resource, then the system uses a slice of the latter to obtain the option value. If you want to receive the option value on some other date, you must specify a value for the Period functional options parameter, which has the Date type, which will be used as the date when the slice was received. This parameter does not need to be created in the metadata. It is provided automatically by the system.

When using parameterized function options, the following behaviors should be taken into account:
● In list forms, the attribute column associated with a parameterized functional option will be displayed if the infobase stores at least one enabled value of this functional option.
● If you want the details associated with functional options to be disabled by default when opening the form, then you need to
set the values ​​of these parameters to values ​​that are not in the infobase (for directories - a null reference, for information registers - measurement values ​​for which there are no records). In this case, the function option will have the value False .
● When a group reference is specified as a parameter (if the parameter type of a functional option allows the creation of groups), and not a reference to an element, the behavior of the system will be as follows:
● if the attribute that stores the value of the functional option is used for both the element and the group, then the value of the functional option will be determined by the value of this attribute.
● if the attribute in which the value of the functional option is stored is not used for the group, then when obtaining the value of the functional option using methods GetFunctionOption(), () and () will return NULL . If, parameterized with this value, a function option affects the user interface, the system will treat it as disabled (the function option will have the value False).
● For commanding metadata objects, it is possible to link to a parameterized function option. In the command interface, the commands of such objects will be displayed only if there is at least one combination of functional option parameters, in which the value of the functional option is True . However, using the () method, you can set specific values ​​for the parameters of functional options, and then the visibility
commands will be determined by the specified parameters.
● The dynamic list automatically uses the functional options used by the form. If the attributes used in the dynamic list request are disabled with a given combination of functional options parameters, the data on them will not be selected and displayed in the dynamic list, and the attribute will be removed from the lists of available attributes in the data display settings dialog
dynamic list (in 1C:Enterprise mode).

7. Working with functional options in the built-in language

Global context methods GetFunctionOption() And GetFunctionInterfaceOption() return the value of the function
options. The difference between them is that the first method allows you to specify a set of functional option parameters, and the second method returns the value of the functional option based on the parameters specified for the command interface. The form has its own method that returns the value of the option for the parameters specified within the form − GetFunctionOptionForm().
To update the global command interface, explicitly call the method SetInterfaceFunctionOptionParameters().
The command interface will be updated to reflect the new state of the functional options.
NOTES E. If the value of a functional option changes in the database, then automatic update there is no global command interface and forms open at this time. To do this, use the method UpdateInterface() after writing the values ​​of the functional options to the database.
It should be remembered that setting the parameters of the functional options (and executing the method UpdateInterface()) leads to the following consequences:
● for each form, all auxiliary forms are closed (with the corresponding handlers being called);
● forms that refuse to close are not closed;
● the content of the main form elements is updated;
● if at the time of updating the interface active form was the main one, the main form is displayed in accordance with the new composition of the elements;
● if an auxiliary form was the active form at the time of the interface update, then:
● the command to open an auxiliary form will be executed if it is available after updating the interface;
● otherwise, the composition of the main form elements is updated and its display is performed;
● if at the time of updating the interface, the active form was an auxiliary form opened with a command that is not related to the form's navigation bar, then instead of this form, the content of the main form elements will be updated and displayed.
To update a particular form, either reopen it or call the SetFormFunctionOptionsParameters(),
at the same time, the sequence of actions described above works only for the form in the context of which the setting of the parameters of the functional options of the form is called.
Parameters do not have to be specified all at once, you can change the value of a particular parameter or set of parameters selectively. But it is the group setting of values ​​​​with one call that is more efficient.
To get the parameter values, you need to call the corresponding function ( GetInterfaceFunctionOptionParameters() or
GetFormFunctionOptionsParameters()), which will return the set parameters as a structure, where the parameter name will be the key.
When opened, the form automatically uses the parameters of the functional options set for the command interface.

Functional Options is one of the new features of the 1C:Enterprise 8.2 platform. The meaning of their use lies in the fact that they allow you to customize the user interface in accordance with the settings of functional options, set the visibility of details in forms. In addition, the developer has the ability to implement program code, the execution of which depends on the state of the functional option.

Let's create a functional option that allows you to enable and disable the calculation wages in configuration. With its help, we can quickly hide those parts of the interface that are related to solving computational problems. A function option by itself does not store any value that allows it to be enabled or disabled. Usually, a constant is used to store the state of a functional option, although it can also be bound to another object, for example, to an attribute of some object.

Let's create a new constant and call it AccountingSalary, type - boolean. Let's include a constant in the subsystem Administration and into a constants form so that we can edit it. In addition, in the form of constants, we will set the AfterWrite handler of the following form:

&At the Client Procedure AfterWrite(WriteParameters) UpdateInterface(); EndProcedure

The meaning of using the command UpdateInterface() is to update, redraw the interface after the change of the constant associated with the functional option takes effect. Otherwise, in order for the changes to take effect, you will have to restart the configuration.

Let's create a new functional option, call it AccountingSalary, on the tab Main, in the parameter Storage we indicate the newly created constant, fig. 7.23. Include a functional option in a subsystem Administration.

Rice. 7.23.

Now let's go to the tab of the functional option settings window Compound and select everything (Figure 7.24) that relates to payroll. If any objects, for example, directories, refer to different parts of the configuration, we will not mark them, otherwise, when the functional option is turned off, they will "disappear" from the interface.

Rice. 7.24.

Subsystem selection Payroll preparation V this case does not automatically select all objects included in the subsystem. When choosing, we only mean hiding or showing the command interface section Payroll preparation.

By running the system in user mode, we can enable and disable the visibility of objects related to the payroll subsystem of our configuration by simply setting or unchecking the flag of the constant AccountingSalary.

More difficult use case functional options is to set the visibility of individual form elements in the event that the value of the functional option is stored in the attribute of an object.

We will make changes to the configuration, in particular, to the directory Individuals add a boolean attribute Has Experience in Human Resources and place it on the form of the directory element.

Function 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 operation of the mechanism is based on two configuration objects:

• Function option
  Functional options added to the application solution can be associated with configuration objects and their attributes. For example, with the functional option Warehouse accounting can link props Stock document Goods receipt. Then, if this functional option is enabled in 1C:Enterprise mode, the field Stock will be displayed in all forms of the document. If disabled - field Stock will not be displayed. Read more...

• Function option parameter
  Function options can be used with parameters. For example, in order for the appearance of a particular form to depend on the value of the parameter selected in the form. For example, a function option parameter Currency accounting May be Organization. Then, depending on which organization is selected in the form, the field Settlement currency will be hidden or displayed. Read more...