Clearing the user settings storage. Clearing the user settings storage Methods for storing 1c settings

It's no secret that periodically, in 1C you need to clean user settings!

because During the process of updating the program or finalizing new functionality, the form of the document or report changes and old saved settings may not be displayed correctly with the new interface. To fix this, you need to clear the old settings and save them with new ones.

The settings for document printing forms are also stored here; if the document is not printed from 1C or is printed crookedly, then need to clear 1C settings.

Processing clearing user settings works in 2 modes:

1. Select a user - click Clear ALL user settings - all old settings will be cleared for the selected user, and the program will work and display as it was intended by the developers. This method helps to get rid of the problems of form display in 1C.

2. Selectively - Click Get settings of all users - check the boxes for what you want to delete and click Delete marked ones. This method allows you to delete only those settings that you consider problematic or unnecessary.

Print (Ctrl+P)

To save information about user settings that must be saved between work sessions, the platform implements settings storage.
There are two types of settings stores:
● Standard storage– storage used by the system by default and storing data in system tables of the infobase.
● Settings repositories– special metadata objects that describe the storage of data in a certain information base object.
For example, this object may describe working with settings that are stored in the directory.
The platform uses the following storages:
● System storage– the system saves all possible settings that are needed for the platform to operate in this storage. These settings include settings for form sizes, settings for printing a spreadsheet document, etc. For a complete list of settings saved in the system storage, see here. The standard settings storage is always used as the system settings storage. That is, system storage data is always stored in the infobase system table.
● General settings storage– this storage is intended to store various settings of the application solution. Platform
does not independently write any settings to this storage. This storage must be used by the developer from the built-in language in order to save/restore user application settings.
● Storage of custom report settings – custom report settings are placed in this storage.
● Report variant storage– report options are placed in this storage.
● Form data settings storage– Form data is saved to this storage. This storage can be used, for example, for
saving processing details. In this case, you can select individual storage for each report and processing.
● Dynamic list user settings storage– user settings of the dynamic list are saved in this storage.
When developing a configuration, it is possible to define your own settings stores for all stores except the system store.
To do this, you need to create a settings storage object in the appropriate branch of the metadata tree and then specify it in the desired configuration property. The properties of the Configuration object have the same names as the above stores.
Storage data can be stored both in the infobase system table and in some special infobase object, for example, in a directory or information register. For example, you can create a settings storage object in the configuration and specify in the configuration property that this storage should be used to store report settings. Thus, the report settings will be saved not in the system table, but in some object, for example, in a directory, which makes it possible to organize work with uniform report settings, implement a system of rights, exchange settings, etc.
Creating your own storage makes sense in cases where a special structure for storing settings is needed, special settings management mechanisms are needed, settings are required to be exchanged within a distributed database, and other similar cases.
Note. To store settings, it is recommended to select objects for which the system supports an identification method in which the identifying attribute can be converted to a string and back without losing data. An example is a directory and standard attribute Code, unique throughout the directory

1. General principles of operation of the settings storage

Metadata object Settings Storage designed to provide storage of application configuration settings. By implementing event handlers and creating object forms, the mechanism for working with settings is modified in such a way that the storage location of the settings changes (instead of system tables, configuration objects created by the developer are used) and the visual mechanisms for working with settings.
The configuration can define an arbitrary number of settings stores.
The settings storage can be used both for programmatic work only and for programmatic and interactive work. In the first case, to provide the necessary functionality, a mandatory implementation by the object module handler is required Settings Storage:
● ProcessingSaving– contains an implementation of the Save() method. In this handler, it is necessary to save the settings to some object. For example, in a directory element.
● ProcessingLoads– contains an implementation of the Load() method. In this handler, it is necessary to obtain settings from some object.
For example, from a directory element.
ATTENTION! If you do not implement one or another handler, then the action that the handler implements will be unavailable. For example, if you do not implement a handler ProcessingSaving, saving settings will not be available.
During the storage development process, the developer independently determines how the storage object will be identified, thereby determining the type of parameter. For example, if settings are saved in a directory, then the Code field or the Link value (of a directory element) can be used as the settings key.
If interactivity is required to work with settings (forms for saving and restoring settings), then it is necessary to implement forms for saving and restoring settings and fill in the corresponding properties of the Settings Storage object (Main saving form and Main loading form).
ATTENTION! Implementation of forms for saving and restoring settings is mandatory for performing interactive operations.
Programmatic saving and restoring of settings is possible without implementing these forms.
When the user applies the save or load settings commands, the system receives the corresponding settings storage object form and displays it on the screen. For example, when saving report settings, the system will use the form for saving the metadata object that is specified as the report settings storage (directly for the report itself or for the entire configuration). In this case, the form will be passed parameters, more detailed information about which can be obtained in the object description Description of Settings in the syntax assistant.
When creating a form using the designer, the necessary parameters will be automatically added to the list of form parameters.
Forms should use the passed parameters and filter the list of settings accordingly. Thus, you should display only the settings for the settings object specified in the ObjectKey parameter (for example, a report).
If the user has selected a setting, then the result of the form should be a value of the SelectSettings type. This value, in the SettingsKey property, should contain the key of the selected setting (for example, the code of a directory element or another parameter identifying the setting), and in the D property additional properties– additional information that the user could indicate in the form:

Close (New Settings Selection ( KeyKeyStoredSettings));
ATTENTION! Saving a setting in the standard settings store is not supported if the object key length exceeds 256 characters; the length of the settings key exceeds 128 characters; The username is longer than 64 characters.

2. Create a metadata object

To create a Settings Store, you must create a configuration object of the same name. This can be done in the General branch, Settings storage item.

Rice. 1. Creating a settings storage

3. Standard settings storage

The standard settings storage is represented in the built-in language by the StandardSettingsStorageManager object. This object implements that
the same set of methods as the SettingsStorageManager object, and additionally implements the following methods:
● GetList()– method for obtaining a list of settings for the selected setting object;
● Delete() – deletes a specific setting of the selected setting object.
Standard storage saves settings in system tables of the infobase.
The system settings store accepts a string as both the setting object key and the setting key.
As settings, the system store accepts any value that can be placed in the value store.
Note. When using the Save() , Delete() and SetDescription() object StandardStorageSettingsManager Please note that if the object to which the settings relate (for example, a form) has already been used in the current session, then the changes will occur only in the next session.
Advice. When making significant software changes to settings (for example, when copying settings from one user to another), it is recommended that the user be prompted to restart the client application.

4. Saving form settings

The developer can control the saving of form data in the settings. To do this, when developing a form, he needs to use the following form properties:
● Saving form data in settings– using this property, the form developer can enable the ability to save form data (with the ability to select the setting in which the data will be saved). If the form has the need to save enabled, then the form provides commands for saving/loading settings.
● Automatic saving of data in settings– indicates the need to automatically save settings when closing the form and restore them when opening the form. It does not matter whether the settings list is used or not.
If the ability to save data is set for the form, then you must indicate which form details should be saved (the Saving column on the Details tab of the form editor).
When saving settings, the full name of the form is used as the object key. In the settings, an object of the Compliance type is saved, in which the paths to the saved details are used as keys, and their (the details’) values ​​are used as values.

5. Saving report settings

The Report and External Report objects have the Variant Store and Settings Store metadata properties. These properties indicate in which storage options and report settings should be saved, respectively. If storages are not specified, then the storages specified in the configuration properties are used. If the configuration properties also do not specify specific objects Settings Storage, then system storage is used.
The report form provides commands for saving and loading report options and settings.
If you need to store some additional information in data composition settings or custom data composition settings, you can use the properties Additional Properties objects Data Layout Settings And CustomSettingsData Layout. Property Additional Properties is an object of type Structure.

6. Saving dynamic list settings

User settings for dynamic lists are saved in the storage specified in the configuration properties ( Storage of UserSettingsDynamicLists). If it is not specified in the configuration properties settings storage, then the system storage is used.
The ability to automatically save user settings for a dynamic list is controlled by the property Automatic saving custom settings for form type attributes DynamicList. When the property is set to True, user settings are automatically saved when the form is closed and loaded when the form is opened.
The dynamic list form provides commands for saving and loading user settings. The dynamic list also provides a command to set standard settings. If this command is executed, the dynamic list will include the settings that are in the property List.SettingsLinker.Settings.
For a dynamic list, it is possible to call an event When Updating the Composition of User Settings on the Server in the following cases:
● When opening a dynamic list form;
● After finishing editing user settings, if the composition of the settings has changed.

7. Procedure for developing a settings repository

The following is a recommended process for developing settings stores:
1. It is determined which storage (see the beginning of the section) will be used. For example, a storage of configuration form data settings will be implemented.
2. A list of metadata objects that will use this repository is determined, and a list of information stored in the repository, its structure and types are determined. This information will help us choose the right metadata object in whose data our settings will be stored.
3. Based on the information from step 2, an object (and its structure) is created that will store the settings. Let our settings be stored in directory elements. Since in our case the structure of the stored data is extremely heterogeneous, there is no point in implementing a separate set of details for storing the settings of each form. Therefore, the settings will be stored in the type directory attribute StorageValues.
4. An object of type is created Settings Storage, and implementation of save and load forms is performed for it. This ensures interactivity when saving and restoring settings.
5. For the created object Settings Storage the implementation of event handlers related to saving and restoring settings is performed. If you do not perform this operation, the actual settings read/write operations will not occur. To solve this problem you need to implement event handlers ProcessingSaving And ProcessingLoads in the module of the created object of the Settings Storage type.
6. In the objects selected in step 2 (or in the configuration properties), the corresponding properties are filled in, thereby indicating to the objects in which storages the settings will be stored. In our example, it is necessary to fill the configuration property Form data settings storage with a link to the object created in step 4.
7. If necessary, implement event handlers related to saving and restoring settings in those application objects where this is necessary.

8. Working with the settings store from the built-in language

This example considers copying the settings of the current user to other users of the system. Used as a source of settings System Settings Storage.
NOTE. The example below is not complete. It is intended to demonstrate working with a standard settings repository.
The list of usernames is passed as a procedure parameter CopySettings() as an array.

Procedure CopySettings(List of Users)
Description of Settings= New Description of Settings;
SelectionSettings = System Settings Storage.Select();
While SelectSettings.Next() Loop
For each User From A list of users Cycle
Description of Settings.View = SelectionSettings.View;
Settings Storage.Save(SettingsSelection.ObjectKey, Selection of Settings.Settings Key, Selection of Settings.Settings, Description of Settings);
EndCycle;
EndCycle;
End of Procedure

I call the 1C object "System Settings Storage" the "internal cache" of 1C; it contains a standard settings storage manager object intended for accessing system settings.
When modifying the configuration, sometimes it is not enough to clear the external 1C cache, i.e. files created by the 1C platform on the hard drive to store user settings, and you need to additionally clear the “internal cache” of 1C, which is what the presented development can handle!

Description

Treatment "System settings storage" is a completely autonomous solution, from the point of view of embedding into any configuration, both on regular and managed forms! And the platform version starting from 8.2 does not matter! The code does not use synchronous or modal calls!

Processing shows working with data type methods:

StandardStorageSettingsManager

StandardSettingsStorageManager
Methods:
Select
Load
Get Description
GetList
Save
Delete
SetDescription
Description:
Objects of this type are designed to access settings stored in standard storage.
To access the settings of report options, an object of this type must be obtained from the global context property ReportOptionsStorage.
To access custom report settings, an object of this type must be obtained from the global context property CustomReportSettingsStorage.
To access user settings for form data, an object of this type must be obtained from the global context property FormDataSettingsStorage.
To access general settings, an object of this type must be obtained from the global context property GeneralSettings Storage.
To access system settings, an object of this type must be obtained from the global context property SystemSettings Storage.
To access user settings for dynamic lists, an object of this type must be obtained from the global context property DynamicListsUserSettings Storage.
Availability:
Server, thick client, external connection.
See also:
Global context, System Settings Storage property

All functionality is illustrated in screenshots.

Attention! The username must match the IB username! Otherwise, the "Get user settings" button will not work correctly and some of the functionality will not work. But if renaming users is problematic, just use only the “Get settings of all users” button!

P.S. If the material helped you, thank the author by giving it a star!

Send this article to my email

It is very convenient that reports in 1C programs can be customized “for yourself” almost in any way, and any user who just needs to specify the necessary indicators, additional columns, sortings, totals, etc. in the report settings can handle this. But doing this every time is very tedious, especially if you use this report often. In order to make your work easier, 1C has created the ability to save report settings, and one report can have many different settings options; they can be given any names, for example, “Report for management” or “Operational report for me” ...

In order to save the report settings in 1C in regular forms, for example, 1c trade 8 edition 10.3 or 1c accounting 8 edition 2.0, you need to open the report itself, then configure its indicators, columns, sorting, as it is convenient for you. Generate the report and make sure it displays the way you need it.

In the window that opens, click on the "Add" button and specify the name of the report, by default, the name will be "Main", set the "Open" flags - if you want this setting to be automatically applied when opening the report, and set the "Save" flag - if you want so that if, during the current setup, you change something in the report setup, for example, add a new column, then with this flag these changes will automatically be written to the setup, i.e. There will be no need to save the setting again.

In the same window you can delete unnecessary settings.

If you did not check the "Open" flag or you need to apply another setting, then you will need to apply the desired setting manually; to do this, in the report, click "Actions" - "Restore setting..." (or use the special icon on the toolbar like shown in the figure below) and select the desired setting:

When restoring the settings, you can select the settings of another 1c user, for example, if your employee displays the report you need exactly as needed, then you don’t have to reinvent the wheel, just click on the “Settings for all users” button and select the desired setting from the user you need .

Read about how to save and restore report settings in managed 1c forms in the following articles.

The purpose of the “Settings Storage” configuration object is clear from the name - to store various user settings. The scope of application of this object is wide - in any configuration, however serious, it is necessary to store some user settings.

For the convenience of programmers, in each configuration there are several standard settings stores; in addition, it is possible to create as many additional settings stores as needed.

First, let's look at the standard settings stores that are present in any 1C configuration starting from version 8.2.

Standard settings stores

So, by default, the configuration contains the following settings stores:

  • Report Options Storage - to access the settings of report options.
  • Storage of Custom Report Settings - for accessing custom report settings.
  • Form DataSettings Storage - for accessing user settings for form data.
  • General Settings Storage - for accessing general settings.
  • SystemSettings Storage - for accessing system settings.
  • Storage of UserSettings of Dynamic Lists - for accessing user settings of dynamic lists.

Each of these stores can be accessed as a property of the global context.

The programmer can use standard storage for his own needs, saving various settings in the context of the user, object and the setting itself.

To work with settings repositories (both standard and those added by the programmer), the following methods are used.

Recording and receiving settings:

GeneralSettings Storage.Save(ObjectName,SettingsName,SettingsValue,SettingsDescription,UserName); SettingsValue = GeneralSettings Storage.Load(ObjectName, SettingsName, SettingsDescription, UserName);

Removing redundant/unnecessary settings:

GeneralSettings Storage.Delete(ObjectName,SettingsName,UserName);

Getting a list of settings:

SettingsValueList = GeneralSettings Storage.GetList(ObjectName, UserName);

The parameters “ObjectName”, “SettingsName” and “UserName” must be of string type.

In the database, all settings are stored in a separate table.

Settings repositories created by the programmer

Now let's talk about those settings repositories that are created by the programmer. In general, the programmer is not limited in any way in his desire to create a new settings store, but usually separate settings stores are created for the following reasons:

  • it is necessary to move settings between databases;
  • reference control is required when storing settings;
  • a special structure of 1C settings is required.

Settings stores are added in the corresponding configuration section.

A key feature of settings stores created by the programmer is the need to manually implement methods for writing and retrieving values ​​(Save() and Load()). In these methods, the programmer must describe saving (in information registers, files, directories, etc.) and loading settings using the built-in language.

Otherwise, the principles of working with the created repository are practically no different from working with standard settings repositories.

The created repository can be accessed this way:

Settings Storage.StorageName.Load();

In addition, the created storages can replace the standard ones in various configuration objects and in the configuration itself.

Managed forms have two properties:

  • Automatic saving of data - if the “Use” value is selected, the data will be saved automatically to the standard storage of form data settings;
  • Saving data in settings - if the “Use list” value is selected, then the “Save” column will appear in the form details window, with which you can specify which form details should be saved, and you will also be able to select the settings storage for this data.

That's all, I hope this article helped you.