Desktop version

Main > Knowledge Base > Best practices > Access rights > Standard roles > Best practices > Access rights > Standard roles > Best practices > Access rights > Standard roles

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:

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:

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 configuration 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:

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 independent 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:

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" checkbox, 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):

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

Next page: Optimizing client/server applied solutions for SaaS application delivery model





© 1C LLC. All rights reserved
1C Company respects the privacy of our customers and visitors
to our Web-site.