Standard roles

This article describes the standards that apply to standard roles. All of the listed recommendations are mandatory unless noted otherwise.

1.1. If your application provides different levels of user access to the infobase, use roles for specifying access rights. Roles are created by application developers according to the required user access levels.

1.2. In a simple scenario, roles match employee positions (Director, Accountant, Storekeeper, and so on).

To give administrators the option to fine-tune access rights, you can create roles that match "small" responsibilities, and then combine them to specify access rights for various user categories. In this scenario, each user has a set of roles, such as ReadManufacturingDocuments, AddEditWarehouseDocuments, or ReadRegulatoryInfo. We recommend that you add typical role combinations (for example, director, accountant, and storekeeper profiles) to the application to facilitate administrator work.

2.1. An application must have two mandatory roles intended for business-level administration and system administration of the infobase: FullAccess (synonym: Full access) and FullAdministrator (synonym: Full administrator).

2.1.2. FullAccess is a mandatory role that grants full access to business data stored in the infobase but does not grant the right to administer the entire infobase (update applications or access Designer). The role complies with the following standards:

  • available for independent use (can be assigned to users);
  • grants full access to all data within a data area (to all separated data), except interactive deletion (see also paragraph 5 of this article);
  • grants all of the rights required for administration of the data area (user management, application setup, deletion of marked objects, and so on);
  • includes the following rights:
    • Data administration
    • Active users
    • Event log
    • Exclusive mode (if the application is intended for running on 1C:Enterpise 8.3 with version 8.2 compatibility mode disabled)
    • Thin client
    • Web client
    • Saving user data
    • Output

If the application is intended for running in the software as a service (SaaS) mode, assign the FullAccess role to subscriber administrators (data area administrators).

If the application is intended for running in the on-premise mode, we recommend that you assign the FullAccess and FullAdministrator roles to the same user because in this scenario business-level administration and system administration are usually performed by a single person.

2.1.3. FullAdministrator is a mandatory role that grants additional rights to administer the entire infobase: application update, access to Designer, and so on. The role complies with the following standards:

  • available only to users that have the FullAccess role;
  • provides full access to all nonseparated infobase data;
  • grants all object access rights, except interactive deletion (see also paragraph 5 of this article);
  • includes all of the rights available at the configuration root level: Administration, Data administration, and all the rest. 

If the application is intended for running in the SaaS mode, assign the FullAccess and FullAdministrator roles  to the service administrators.

2.1.4. If the application is intended for running on 1C:Enterpise 8.3 with version 8.3.3 compatibility mode disabled, include the FullAccess and FullAdministrator roles in the list of default configuration roles (the DefaultRoles configuraion property).

2.2. The following application types can be considered as exceptions from 2.1: standard applications, single-user applications, and applications that are not intended for running in the SaaS mode.

In these scenarios, the FullAdministrator role is not mandatory. Instead, you can assign the administrators the mandatory FullAccess role, which grants full access to infobase data and infobase configuration. The role complies with the following standards:

  • available for independent use (can be assigned to users);
  • grants full access to all data, except interactive deletion (see also paragraph 5 of this article);
  • included in the list of default configuration roles (the DefaultRoles configuraion property, in 1C:Enterprise versions 8.2 and earlier the property name is DefaultRole). This is only required in the single-user mode(when the user list is empty), otherwise regular users will have more rights than system administrators (namely the interactive deletion role).

We recommend that this is the only role that includes the Delete right.

This recommendation is optional

If you need to give the right to delete objects to a user that does not have full access rights, we recommend that you add a DeleteMarkedObjects role with the right to delete objects. The role is not intended for idependent use, assign it to users together with other roles.

3. Roles granting infobase access. If you need to organize infobase access rights (such as Thin cient, Thick client, or Interactive open external data processors), specify separate roles for those rights. Such roles are not intended for independent use, assign them to users together with other roles.

The application must be intended for use both in scenarios where users have these rights and in scenarios where none of the users have them.

3.1. Administration, which grants the Administration and Active users rights.

3.2. OutputToPrinterFileClipboard, which grants the Output right.

3.3. StartAutomation, which grants the Automation right.

3.4. StartWebClient, which grants the Web client right.

3.5. StartExternalConnection, which grants the External connection right.

3.6. StartThickClient, which grants the Thick client right.

3.7. StartThinClient, which grants the Thin client right.

3.8. InteractiveOpenExtReportsAndDataProcessors, which grants the Interactive open external data processors and Interactive open external reports right.

3.9. DataBaseConfigurationUpdate, which grants the Update database configuration right.

3.10. ViewEventLog, which grants the Event log right.

3.11. AllFunctionsMode, which grants the Mode "All functions" right. This mode is only intended for developers and deployment engineers, and for investigating unexpected application behavior. Thus, the application functionality must not require using this mode. For example, all of the standard data processors, such as marked object deletion or totals and aggregates management, must be available in appropriate user interface sections.

3.12. SaveUserData, which grants the Saving user data right. We recommend that you assign this role to all user categories, except users that should not edit application settings and users who should never introduce any changes to the data (this is usually required for external and temporary users, such as respondents or auditors, and for users that share a single account for some reason).

Applications must support the scenario when none of the users has the SaveUserData role. If the application accesses the following objects from 1C:Enterprise script:

  • user settings (saving and loading data to or from storages: CommonSettingsStorage, ReportsVariantsStorage, FormDataSettingsStorage, ReportUserSettingsStorage, and SystemSettingsStorage);
  • user work history (UserWorkHistory) and favorites (UserWorkFavorites);
  • user report settings (the SetCurrentUserSettings method of managed form report extension);

then this code is skipped for users that do not have the SaveUserData role in the manner that does not hinder regular user activities. If the application features dedicated user interfaces or form items for editing user settings (the history of entered values, "Remember the settings" check box, and so on), they are not available to users that do not have the SaveUserData role.

If your application is based on 1C:Subsystems Library, you can use the CommonSettingsStorageLoad and CommonSettingsStorageSave methods of the CommonUse module. 

See also: User settings.

4.1. If some users need temporary or permanent access for reading all infobase data, we recommend that you create dedicated roles for this. For example, you can create a role for temporary auditor access, or for permanent company owner or director access.

4.2. In a simple scenario where roles match employee positions (Director, Accountant, Storekeeper, and so on), also add the ReadOnly role.

The ReadOnly role includes the following rights: Read, Use, View, and String Input (where applicable) for most of the metadata objects, except those that are implemented for internal purposes and are never shown to users (and therefore can be only accessed in the privileged mode).

4.3. In applications where roles represent "small" responsibilities and are combined to describe the rights of various user categories, we recommend that you assign combinations of read-only roles to users (for example,  ReadManufacturingDocuments, ReadWarehouseDocuments, and ReadBillingDocuments). We recommend that you add typical combinations of these roles (for example, auditor, owner, and director profiles) to the application.

To ensure that such users can view all infobase data, disable (do not set) record-level access restrictions.

5. None of the roles, including the FullAccess and FullAdministrator role, can include the following rights (excluding specific justified cases):

  • Interactive delete
  • Interactive deletion of predefined objects
  • Interactive deletion mark on predefined objects
  • Interactive removal of deletion mark from predefined objects
  • Interactive deletion of marked predefined objects

 We recommend that you only include the Delete right in the FullAccess and FullAdministrator roles.

Add comment