Configuring roles and access rights

Scope: managed applications, ordinary applications.

Applies to 1C:ERP, 1C:Trade Management 11, and embedded libraries.
Recommended for use in other applications.
Provides clarifications to other standards.

1. General guidelines

1.1. Roles are created atomically, granting access to basic application features. User profiles are then generated based on these roles and assigned to users through Standard Subsystems Library. To avoid creating new roles during application deployment, it is important to carefully distribute access rights among features.

Exception: External user roles must have a complete set of access rights specified for required objects.

For example, the PartnerSelfService role in 1C:ERP.

1.2. The FullAccess role, along with the SystemAdministrator role, provides unlimited access (without RLS) to all objects. Refer to Standard roles for more information.

1.3. No role, including FullAccess and SystemAdministrator, should allow interactive deletion of reference objects.

After creating a new object, switch to the FullAccess role and disable the right to interactively delete reference objects.

1.4. Only the FullAccess and SystemAdministrator roles can grant the permission to delete reference objects.

1.5. Select the "Set rights for new objects" checkbox only for the FullAccess role. For all other roles, clear this checkbox.

1.6. If you want to grant an access right only to system administrators (to use a report or data processor), you can assign it to either the FullAccess or the SystemAdministrator role. There is no need to create separate roles for this purpose.

1.7. Ensure that all documents that require posting have the "Privileged mode for posting" and "Privileged mode for unposting" checkboxes selected. There is no need to create roles specifically for changing registers subordinate to recorders.

Exception: Documents intended for direct adjustment of register records can be posted with access rights verification. In this case, provide roles allowing register changes.

1.8. Ensure that all functional options have the "Use privileged mode for getting data" checkboxes selected.

Exception: Configurations may include parameterized functional options, where developers account for variations in values based on user permissions.

For example, consider the parameterized functional option UseCurrencyForSettlementsWithPersonnel, which allows you to customize the availability of the Currency field depending on the company. In this case, only companies that use foreign currency accounting will see the Currency field.

1.9. There must no roles other than standard SSL roles that grant common rights (such as Administration and ThinClient).

When creating a new role, make sure these rights are disabled.

1.10. For some non-sensitive data and general features, avoid creating separate roles for reading (as well as viewing and inputting by string for reference data). Instead, include these rights in roles BasicAccess<LibraryName> and BasicAccessExternalUser<LibraryName> (only for configurations that support external users). For example, these are constants, national classifiers, common period choice forms, contact information input forms, etc.

1.11. Avoid granting access to objects from different subsystems using the same role.
For example, a role in 1C:ERP that contains permissions for 1C:Trade Management 11 objects must not include permissions for other objects. See also: Libraries — Developing roles.

2. Creating roles for atomic features

2.1. When setting up access rights, group objects into atomic features. When objects belong to the same feature, they cannot not be accessed in different ways.

Example:
Let's consider the "Sales order" document and the associated "Sales orders" accumulation register, which stores the balance of goods not yet shipped and unpaid amounts. This register reflects the current status of the order tabular section. If users have permissions to access the document, they should also have permissions to access the register. So, the "Sales order" document and the "Sales orders" accumulation register can be combined into a single atomic feature. If there is a report that shows the balance of the "Sales orders" register, it should also be included in that feature.

Counterexample:
Let's consider a scenario where there is a "Customer invoice" document, which serves as a reference for goods shipment. The balance for shipment references is maintained by the "Goods for shipment" accumulation register. It would not be practical to combine the "Customer invoice" document and the "Goods for shipment" register into a single feature because, for example, a warehouse supervisor might have permission to read the "Goods for shipment" register but not the "Customer invoice" document.

2.2. If there is any doubt as to whether or not two objects can belong to the same atomic feature, assign them to separate features.

2.3. Each object must be assigned to a single atomic feature.

2.4. Do not assign objects from different libraries to the same atomic feature.

3. Reference objects and registers

3.1. For features that involve reference objects and independent information registers, create two roles:

Read<FeatureName>.
AddEdit<FeatureName> or Edit<FeatureName> if addition is automatic or administrator-only.

These roles must include the following rights (if applicable to a metadata object):

Read<FeatureName> includes:
- Read, View, and String input.
Edit<FeatureName> includes the same rights as Read<FeatureName>, along with:
- Update and Edit.
- Posting, Undo posting, Interactive posting, Interactive undo posting, and Interactive change of posted (for documents).
- Totals control (for registers).
AddEdit<FeatureName> includes the same rights as Edit<FeatureName>>, along with:
- Insert and Interactive insert.
- Interactive mark for deletion and Interactive unmark for deletion.

3.2. Note that for registers subordinate to a recorder, editing permissions are usually not required (see item 1.7).

4. Document journals

4.1. If all documents in a journal are related to a single atomic feature, assign the rights to read and view the journal to all roles associated with that feature.

4.2. If a user does not have permission to read any document in a journal, 1C:Enterprise will restrict access to all journal columns where that document is displayed. Therefore, it is not practical to create a separate role just for journal access. The journal can be included in an atomic feature, or it can be accessible only to users with full privileges.

5. Constants

5.1. If you want a constant to be changed by system administrators only, assign change and edit rights to either the FullAccess or the SystemAdministrator role. These roles must also include rights to read and view constants.

5.2. If a constant should be changeable by users, assign read, view, change, and edit rights to the existing role or create an ad-hoc Edit<ConstantName> role.

5.3. Typically, constants store non-sensitive information. Assign read and view rights for constants to roles BasicAccess<LibraryName> and BasicAccessExternalUser<LibraryName>. This allows you to avoid privileged mode activation when programmatically accessing constant values.

5.4. Rarely, when a constant stores sensitive information, create a Read<ConstantName> role. However, a separate read role is not required if a constant is to be accessible only to administrators.

For example, for the IBAdministrationParameters constant, simply include read and view rights in the SystemAdministrator role.

6. Subsystems displayed in the main command interface

6.1. For each top-level subsystem, create a Subsystem<SubsystemName> role that grants viewing permissions.

6.2. If a subsystem interface displays some settings and catalogs in a separate form, ensure that the subsystem access role includes permissions to view that form. For example, in 1C:ERP, some catalogs are not part of the command interface sections. They are displayed in a form accessed through the "Settings and catalogs" command.

7. Reports

7.1. If a report is based on data from a single atomic feature (item 2.1), access rights to the report can be included in roles associated with that feature.

Example:
A sales order fulfillment report relies entirely on data from the SalesOrders accumulation register. Therefore, the rights to access the report must be included in a role that allows reading the register.

7.2. If you need to customize access rights for a report that is based on data from a single atomic feature, create an ad-hoc ViewReport<ReportName> role that grants usage and viewing permissions.

Example:
Even though a contact information report utilizes customer data from an atomic feature, you might need to restrict access to the report if you do not want to display information on all customers.

7.3. For reports built on data from multiple atomic features, create a ViewReport<ReportName> role that grants usage and viewing permissions.

Example:
A sales plan fulfillment report uses data from both sales plans and sales records. Access to this data is managed by roles associated with different atomic features. To provide access to the report, create an ad-hoc role.

7.4. When setting up access rights, consider consolidating reports of the same type into atomic features if they meet the following criteria:

Reports are not part of other atomic features (see item 7.1).
Conflicting access setup tasks are unlikely to occur during application deployment.

8. Data processors and common forms

8.1. For each data processor that serves as a separate workspace accessible through the global command interface, create a UseDataProcessor<DataProcessorName> role that grants usage and viewing permissions.

Avoid consolidating access rights for different data processors, each serving as a workspace, into a single role.

8.2. Other types of data processors include:

Auxiliary data processors that are not directly accessible from the global command interface but can be opened from other objects. For example, a data processor for picking goods.
Data processors that contain common code, such as print form generation code.

Assign rights for these data processors to the BasicAccess<LibraryName> role.

8.3. Permissions for data processors intended only for system administrators must be assigned to the FullAccess role (or the SystemAdministrator role for a session with no separators). Do not create separate roles for such data processors.

8.4. These rules also apply to common forms. The role name for a common form as described in item 8.1. is UseCommonForm<CommonFormName>.

8.5 Exceptions to these rules are outlined in item 6.2.

Example:
In 1C:Trade Management 11, access rights for the SelectGoods and SearchForObjectsByBarcode data processors are assigned to the BasicAccessTM role.

9. Commands

9.1. If a command only involves viewing data without making changes, assign the view right to a role that allows viewing the object.

Since roles that allow editing objects also include the right to read them, make sure to include the command permissions in all roles that allow reading or editing.
Print commands within data processors (print forms printed out from multiple objects) must have permissions assigned to the BasicAccess<LibraryName> role.

9.2. If a command involves changing data, the view right must be assigned to a role that allows editing objects.

10. Rights unrelated to object access

10.1. When granting users additional rights not related to object access, create a role with a descriptive name (<RightDescription>) that does not provide access to any specific object. Do not use the word "Right" in the description.

Example:
Correct: DeviationFromPurchaseConditions
Incorrect: RightToCreateProductsReleaseWithoutOrder.

10.2. Verify whether a user has this role programmatically. Users with the FullAccess role must be checked without including this role in their profile. Use the Users.RolesAvailable SSL function for verification.

10.3. Implement additional user rights by checking for a role (or access right) and avoid using other mechanisms.

11. External user rights

Assign roles to grant access rights to external users (for example, from Employees, Partners, or Individuals catalogs) using a designated prefix.
For example, you can use the SelfServiceWorkplace prefix for customer self-service access in a trade management application:

SelfServiceWorkplaceCreateCustomerComplaints (Self-service: customer complaints).
SelfServiceWorkplaceViewOrderStateReport (Self-service: view the "Order state" report).
SelfServiceWorkplaceAddEditCounterparties (Self-service: add and edit counterparties).

12. Rights for accessing obsolete objects

Remove obsolete metadata objects with the Obsolete prefix from all roles except for FullAccess and SystemAdministrator.

See also: