Specifying customs user access rights at metadata level: Examples

Question: 1C:Drive comes with standart access group profiles such as CRM, Purcases, Sales, Warehouse etc. However, I still need to create my own access group profiles and define custom roles and interfaces for them. How can I achieve this?

 

Answer:

Basic definitions: Let’s begin with basic definitions. A “Right” and a “Data access restriction” are the smallest building blocks of the user access rights system. A right gives access at metadata level (for example giving the right to view all Purchase order documents in the database), whereas a data access restriction restricts access at record level (for example restricting the viewable Purchase order documents to those whose supplier attribute satisfies certain criteria). Our examples here will cover the access at metadata level only.  

A “right” is the basic building block. Metadata object classes like catalogs, documents, subsystems, reports, registers have their own applicable set of  rights such as to read, insert, view, edit etc. Those reside in the 1C: Enterprise Platform, a 1C:Enterprise developer cannot add, remove or modify the rights, he/she creates or modifies “roles” instead in the configuration, then he/she includes in this role  a set of metadata objects (Documents.PurchaseOrder, Catalogs.Products etc.) and sets the rights for the included metadata objects. Rights can be assigned to metadata objects as a whole and/or by attributes of the metadata object. Roles themselves are are metadata objects too, so that they can be created or modified only from the designer, the users cannot modify the roles from the enterprise regime, they can only see the roles that already exist in the configuration.

1C:Drive has the AccessGroupProfiles catalog at the user level, the user can add elements to this catalog in the enterprise regime, then assign a choice of roles (which had been created in the designer) to the new access group profile. Afterwards, in the enterprise regime, one or many access group profiles are assigned to each database user. That’s how a database user gets its access rights in a 1C:Drive database. 1C:Drive by default comes with several standard access group profiles suitable for various user work definitions.

 

 

First example:

Our company has an employee, which can create Supply order document only. So we want to create a role which allows a user to create and use Supply order documents only, moreover, we want the user to see nothing more than the Supplier order document in the enterprise regime interface.

First, we create our own access group profile, which is basicly a set of roles. Since the choice of roles must be consistent with each other for the system to work without any errors, it is much easier and safer to create the new access group profile by copying a default access group profile (because it already has a tested, consistent selection of roles) first, and then adding or removing roles to it as needed, than creating the new access group profile from scratch.

As an example, below is an error we receive when we create our own access group profile from scratch and fail to assign a consistent set of roles to it. Purchase order document read and edit role is included in the access group profile but when we actually want to open the list form of the document, we get an error stating that OrderStatus attribute of Purchase order document was not found.   

When we check from the designer, we see that at least ReadCatalogPurchaseOrderStatuses role is needed for the system to be able to read (for the system to read and and for the user to view) the PurchaseOrderStatuses catalog, which is referenced from the OrderStatus attribute of Purchase order document. We did not know beforehand that we had to include this ReadCatalogPurchaseOrderStatuses role in our access group profile, hence the error.   

So, firstly we create our My_Purchases access group profile by copying the default Purchases access group profile. Then begin adding or removing the roles.

We  want only the the Purchase order document to be created and edited, and all other documents and catalogs to be read only by the system so that we won’t get any errors about some attriubute of some object wasn’t found. We do not touch any registers since they are by default can be changed by documents only and if the user cannot see the document, he\she won’t see the register too. Information registers whose write mode is Independent are an exception since the information is written to them not by a document, but via a form. We can modify the availability of reports and data processors to our liking.

We start modifying our My_Purchases access group profile by finding roles which contain the text “Add and edit catalog” and “Add and edit documents”, unticking these roles, and tick the corresponding “Read catalog” and “Read documents” roles instead. Not all catalogs and documents have both “Add and edit” and “Read” roles, when this is the case, just leave the role untouched.

We want the user see only the Purchase order document in the interface. Standard “Read catalog” and “Read documents” roles in 1C:Drive include not only “read” (this means the system can read the metadata object, say when executing a query) right, but also the “view” (this implies that the user can view the object in the enterprise regime) right. In order to prevent the user from viewing the unneeded catalogs and documents we could create new roles in the designer which would mimic the “read” roles except excluding the “view” right, then use these new roles in the My_Purchases access group profile instead of the ones with “Read catalog” and “Read documents” names. But then the Purchase order document has several links in it to other catalogs and documents which are included in the Purchases subsystem, if we cancel the read right for such documents and catalogs, the user won’t be able to fill in the Purchase order document with needed data.

Our goal is to have only the Purchase order document be seen in the interface, while not interfering with the viewability of other catalogs and documents which are linked in the Purchase order document. In order to achieve this,  we create our own subsytem in the extension, name it My_Ext_PurchasesLite, and include only the Purchase order document in it. Then we create a new role called My_Ext_SubsystemPurchasesLite and include in this role the right to view the My_Ext_PurchasesLite subsystem. For the new subsystem to appear in the interface, we open the configuration command interface of the extension in which we have created the subsystem (My_Extension) and put a solid tick under the the Visibility by roles column, where our role My_Ext_SubsystemPurchasesLite and our subsystem My_Ext_PurchasesLite intersect.

Afterwards, in the enterprise regime, for our My_Purchases access group profile we unselect the “Subsystem Purchases” role and select the “(MyExt) Subsystem Purchases Lite” role instead. Lastly, we assign  My_Purchases access group profile to our user Jane Doe as her one and only access group profile.

Upon logging in with Jane Doe user, we see that the Purchases section is still visible, with some objects in it. We had excluded the “Subsystem Purchases” role from our My_Purchases access group profile, so why do we see it now? Let’s search from the designer and find out. We search for all roles which give view right for SubcontractingServicesReceived subsystem and either just exclude these roles from My_Purchases access group, or create similar role in the extension and then exclude the view right of  SubcontractingServicesReceived subsystem from the role, afterwards adding this modified role to the My_Purchases access group profile in place of the original one. Then for the Catalogs too similar search and change.

 

 

Second example: Our warehouse workers use the standard access group profile “Warehouse”. Certain warehouse documents such as Goods receipt document has Order, Supplier invoice and Basis document attributes, whose data types are Purchase order and Supplier invoice documents. When the warehouse workers are selecting the appropriate Purchase order of Supplier invoice document from within the Goods receipt document, they can see the amounts of these documents in their choice forms, this is a problem for us, warehouse workers do not need to see the document amounts.

For this task, we first need to create our custom role MyExt_ViewPurchaseOrderWithoutSums in the designer.

Create My_Warehouse access group profile by copying the standard Warehouse access group profile, then for the My_Warehouse access group profile untick the “Read documents Purchase order” role and tick the newly created in the designer “(MyExt) View purchase order without sums” role and save. Assign the My_Warehouse access group profile to user John Doe as his one and only  access group profile and save.

Afterwards, login with the John Doe user, open any invoiced Goods receipt document, open the choice form of the Purchase order document from the Order attribute of the Goods receipt document. You’ll notice that “Amount excl. tax”,  “Tax” and “Total” fields are not shown anymore. And if you try to open the Purchase document by clicking the open button of the Order attribute, you’ll receive an error about part of the document cannot be read (because in our MyExt_ViewPurchaseOrderWithoutSums  role, we did not give any rights for viewing the tabular sections of the Purchase order document), so the document won’t open.