Scope: managed applications, ordinary applications.
1.1. To store personal user settings, use a storage of common settings. For example, a value of the "Ask when exiting the application" setting for the current user is read and written in 1C:Enterprise language using the CommonSettingsStorage object:
SettingValue = CommonSettingsStorage.Load("ApplicationSettings", "AskOnExit");
CommonSettingsStorage.Save("ApplicationSettings", "AskOnExit", SettingValue);
We recommend that you do not use other methods to store user settings, in particular other metadata objects (registers, attributes and tabular sections of catalogs), external files, and so on.
1.2. To be able to work with user settings, grant the SaveUserData right to a user.
See also: Standard roles
1.3. To access each setting in the storage of common settings, use a unique string setting key. For example, a main company and a main warehouse the current user deals with are two different settings stored separately in the MainCompany and MainWarehouse keys.
Some settings can be combined in a structure, an array, or a mapping if they are accessed at the same time as a single setting. For example, proxy settings used to access the Internet include several values (proxy server address, username and password). However, they are stored together as a single structure similarly to a separate setting.
2.1. The configuration needs to have a common place for editing all user settings. Usually, it is the common form of personal user settings.
You can find an example of implementing the "My Settings" personal settings form in the Standard Subsystems Library demo configuration.
2.2. The personal settings form can be not the only place where data is edited. To improve user experience, you can display fields with separate settings directly on workstations they refer to. For example, you can display the "Hide tooltips when editing files" check box directly in the form of a tooltip that appears when you work with files.
2.3. The form of personal user settings, other forms (workstations), and separate form items used to work with personal settings are to be available only for users with the SaveUserData right.
See also: Standard roles
3.1. When you work with the storage of common settings, note that the settings do not migrate between infobase nodes but they are specific for a particular node. If necessary, user settings can be transferred between nodes using 1C:Enterprise language.
3.2. All settings in the storage of common settings are saved by infobase users with the help of string usernames. Therefore, if you rename a user, previous settings are lost. If further you create a user with the same name as the previous name of the renamed user, the previously saved settings will be used for the new user.
To avoid this, we recommend that you transfer the settings upon renaming users and clear the settings upon deleting users.
If Standard Subsystems Library (SSL) is used in the configuration, developers can use handlers of writing and deleting infobase users (see the OnWriteInfobaseUser and AfterDeleteInfobaseUser procedures in the UsersOverridable common module). Using these handlers, you can transfer or delete the settings. See a usage example in the SSL demo configuration.