1.1. Use the common settings storage for storing personal user settings. For example, reading and writing of the setting "Confirmation is required upon exiting the application" is implemented in 1C:Enterprise script using the CommonSettingsStorage object:
SettingValue = CommonSettingsStorage.Load("ApplicationSettings", "DisplayExitConfirmation");
CommonSettingsStorage.Save("ApplicationSettings", "DisplayExitConfirmation", SettingValue);
Do not use any other methods for storing user settings. For example, do not use metadata objects (registers, attributes, catalog tabular sections, and so on) or external files.
1.2. To access user settings, a user must have the Saving user data right.
See also: Standard roles
1.3. To access a setting in a common settings storage, use the unique setting key. For example, the default company and the default warehouse for a specific user are different settings that have the DefaultCompany and DefaultWarehouse keys.
At the same time, you can combine some settings into a structure, array, or mapping, provided that they are always accessed together as a whole. For example, proxy server parameters include multiple values (server address, user name, and password), which are stored in a structure (in a single setting).
2.1. The configuration must include a single place for editing all of the user settings. Normally, it is a common user settings form.
You can see a personal settings form implementation example in the 1C:Subsustems Library demo.
2.2. The user settings form might not be the only place for editing the settings. For user convenience fields with individual settings can be added to the forms affected by the settings. For example, the Do not show file editing tooltips check box can be located in the form that displays those tooltips.
2.3. The user settings form, other forms that contain the settings, and individual form items that contains the settings must be only available to the users with the Saving user data right.
See also: Standard roles
3.1. When using the common settings storage, remember that the settings are node-specific and they are not synchronized between nodes. You can implement the synchronization using 1C:Enterprise script.
3.2. All of the settings in the common settings storage are tied to specific users (to user name strings). When a user is renamed, its settings are lost. If a new user whose name matches a previously available user name is created, the new user inherits their settings. To avoid this, implement the settings migration when users are renamed, and implement the settings deletion when users are deleted.
If your configuration includes 1C:Subsystems Library, you have the handlers for saving and deleting infobase users where you can implement the settings migration and deletion (see the OnWriteInfoBaseUser and AfterInfoBaseUserDelete procedures in the UsersOverridable common module). An example is available in the 1C:Subsystems Libtary demo.