Scope: managed applications, ordinary applications.
Applies to 1C:ERP, 1C:Trade Management 11, and their libraries.
Recommended for use in other configurations.
Contains clarifications of requirements of other standards.
1. General provisions
1.1. Roles are created as atomic, that is, giving access rights to elementary application functions. User profiles are created from these elementary roles. The user profiles are then assigned to users using SSL. Access rights to objects must be divided between functions so that there is no need to create new roles upon standard deployment.
Exception: for roles assigned to external users, an exhaustive set of access rights to required objects is specified.
For example, in 1C:ERP, this is the PartnerSelfService role.
1.2. FullAccess role with the SystemAdministratorrole provides unlimited access (without RLS) to all objects. See standard roles.
- After creating a new object, enter the FullAccess role and disable the right of interactive deletion of reference objects.
1.6. If an access right can be used by system administrators only (for example, to a report or data processor), it is enough that this is granted by one of the two roles: FullAccess or SystemAdministrator. Creating separate roles is not required in this case.
1.7. All documents that require posting must have the "Privileged mode for posting" and "Privileged mode for unposting" check boxes selected. Therefore it is not necessary to create roles that grant rights to change registers subordinate to recorders.
Exception: documents intended for direct adjustment of register records can be posted with access right verification, but in this case, it is necessary to include roles that grant rights to change registers.
Exception: a configuration can include parameterized functional options, for which developers provide for differences in values obtained by users with different rights.
Example: There is a parameterized functional option UseCurrencyUponSettlementsWithPersonnel, which is parameterized by the company. If a user receives its value in the context of their rights, they will not see the Currency field in the document if they do not have a company where currency accounting is applied.
1.9. There must not be any roles except for standard SSL roles that grant common rights (such as Administration, ThinClient, and other).
- When creating a new role, make sure these rights are disabled.
1.10. In some cases, for non-confidential data and public functions, it is not necessary to create a separate role for reading (as well as viewing and entering by string for reference data), but you should include these rights in the roles BasicAccess<LibraryName>> and BasicAccessExternalUser<LibraryName> (this role is required only if a configuration supports operations with external users). For example, these are constants, national classifiers, common period selection forms, contact information input forms, and other.
1.11. It is not allowed that one role grants access to objects that belong to other subsystems.
For example, in the 1C:ERP storage, a single role cannot grant rights to objects that appear in 1C:Trade Management 11 and to objects that do not appear in 1C:Trade Management 11. See also: Developing roles in libraries.
2. Rules for creating roles for elementary functions
There is the "Sales order" document and the "Sales orders" accumulation register related to it, which stores balance of unshipped goods and unpaid amounts. This register reflects the current state of the order tabular section. If a user has rights to the document, it will be strange that they will not have rights to the register. The "Sales order" document and the "Sales orders" accumulation register can be combined into a single elementary function. If there is a report that conveniently displays the "Sales orders" register balance, it makes sense to include it in this function too.
There is the "Sales of goods and services" document acting as a goods shipment reference. Balance for goods shipment references is kept by the "Goods for shipment" accumulation register. Combining the "Sales of goods and services" document and the "Goods for shipment" register within a single function would not be correct because, for example, a warehouse supervisor might well have rights to read the "Goods for shipment" register but might not have rights to read the "Sales of goods and services" document.
3. Reference objects and registers
- Read<FunctionName> $$$
- InsertUpdate<FunctionName> (or Update<FunctionName>) if insert is executed automatically or by administrators only).
Roles must contain the following rights (when a metadata object has them):
Read<FunctionName> contains the following rights:
Read, View, and Input by string.
Update<FunctionName> contains the same rights as the Read<FunctionName> role, as well as:
Update and Edit.
Posting, Cancel posting, Interactive posting, Interactive posting cancellation, and Interactive change of posted document.
Totals management (for registers).
InsertUpdate<FunctionName> contains the same rights as the Update<FunctionName> role, as well as:
Insert and Interactive insert.
Interactive deletion mark and Interactive clearing of deletion mark.
4. Document journals
4.1. If all the documents from the journal are assigned to a single elementary function, include the journal in this function. Otherwise, include the journal in another elementary function, for which you need to create a separate role.
5.1. If you want a constant to be changed by system administrators only, only one of the following roles must have change and edit rights: FullAccess or SystemAdministrator. These roles must also include rights to read and view constants.
5.2. If you want a constant to be changed by users, include rights to read, view, change, and edit in the existing settings role or create a separate Update<ConstName> role that grants rights to read, view, change, and edit this constant.
5.3. In most cases, a constant is used to store non-confidential information. Therefore, rights to read and view the constant must be assigned to the BasicAccess <LibraryName> and BasicAccessExternalUser<LibraryName> roles. It allows you to avoid unreasonable setting of privileged mode when reading a constant value from code.
5.4. In rare cases, when a constant is used to store confidential information, it is necessary to create the Read<ConstName> role . However, if the value must be available to administrators only, there is no need to create a separate role for reading.
For example, you do not need to create a separate role for reading for the IBAdministrationParameters constant. It is enough to include read and view rights in the SystemAdministrator role.
6. Subsystems displayed in the main command interface
6.2. If a subsystem interface is arranged so that some settings and catalogs are displayed in a separate form, a role that grants the access right to the subsystem must include rights to view this form. For example, in 1C:ERP, some catalogs are not included in command interface sections and are displayed in a form called by the "Settings and catalogs" command.
A sales order fulfillment report is completely based on data of the SalesOrders accumulation register, so the rights to the report must be included in a role that grants the right to read the register.
7.2. If there are tasks of a single setting of rights to a report that is based on data included in a single elementary function upon deployment, create a separate ViewReport<NameOfReport> role that gives usage and view rights.
Although a contact information report displays data included in a elementary function of customer information, upon deployment, it might be necessary to restrict access to the report, which allows you to display information on all the customers at once.
A sales plan fulfillment report is based on data about plans and sales data. Rights to read this data are granted by roles assigned to different elementary functions. To ensure access to the report, create a separate role.
- Reports are not included in other elementary functions (see cl. 7.1).
- Upon deployment, tasks of various settings for access rights to these reports cannot arise.
8. Data processors
Do not combine access rights to different data processors, which are workplaces, in a single role.
- Auxiliary data processors that cannot be called from the global command interface but can be opened only from other objects.
- Data processors that store the code of common print forms.
- Data processors that grant access to overall functionality.
must be assigned in the BasicAccess<LibraryName> role.
In 1C:Trade Management 11, rights to the PickGoods and SearchObjectsByBarcode data processors are assigned to the BasicTMRights role.
- Since the role that grants the right to change the object also grants the right to read the object. Do not forget to include rights to the command in roles with the read right and in roles with the edit right.
- Rights to print commands located in data processores (these are print forms that are printed from multiple objects) must be assigned to the BasicAccess<LibraryName> role.
10. Rights not related to access to objects
10.1. If you need to grant users some additional rights not related to access to objects, create the <DescriptionOfTheRight> role, which does not grant access to any object. Do not use the word "Right" in the description.
10.2. In the configuration code, check whether a user has this role. A user with the FullAccess role must be checked without the need to include this role in their profile. To check, use the Users.RolesAvailable SSL function.
11. Name roles that are used exclusively to grant access rights to external users (represented in the application by one of the objects, for example, items of the Employees, Partners, and Individuals catalogs, and other) using a certain prefix.
For example, the SelfService prefix to access a customer self-service workplace in a trade management application:
- SelfServiceClaimsProcessing, synonym SelfService: processing claims.
- SelfServiceViewReportOrderFulfillmentState, synonym SelfService: viewing the "Order fulfillment state" report.
- SelfServiceInsertUpdateCounterparties, synonym SelfService: adding and changing counterparties.
12. Obsolete metadata objects with the Delete prefix must be excluded from all roles except for the FullAccess and SystemAdministrator roles.