How to create a users role to manage internal users?

Hello Mohamed,

Here is an example of how to permit or deny modifying the user page (UserPageV2) of system users that are system administrators (the one on the screenshot below):

To do this you need to create a replacing view model for "Edit page - User" (UserPageV2) with the code similar to the one below:

define("UserPageV2", ["RightUtilities"],
	function(RightUtilities) {
		return {
			entitySchemaName: "VwSysAdminUnit",
			attributes: {
              CanEditSystemAdministrator:{
                dataValueType: this.Terrasoft.DataValueType.BOOLEAN,
                type: this.Terrasoft.ViewModelColumnType.VIRTUAL_COLUMN,
                value: true
              }
            },
			properties: {},
			mixins: {},
			diff: /**SCHEMA_DIFF*/[
              {
					"operation": "merge",
					"name": "Name",
					"parentName": "FormAuthGridLayout",
					"propertyName": "items",
					"values": {
						"enabled":{bindTo:"CanEditSystemAdministrator"}
					}
				},
              {
					"operation": "merge",
					"name": "UserPassword",
					"parentName": "FormAuthGridLayout",
					"propertyName": "items",
					"values": {
						"enabled":{bindTo:"CanEditSystemAdministrator"}
					}
				}
            ],
			methods: {
              checkIfTheUserIsASystemAdministrator: function (){
                var esq = Ext.create("Terrasoft.EntitySchemaQuery", { rootSchemaName: "SysAdminUnitInRole" });
					esq.addColumn("SysAdminUnit");
                	esq.addColumn("SysAdminUnitRoleId");
					esq.filters.addItem(esq.createColumnFilterWithParameter(3, "SysAdminUnit", this.get("PrimaryColumnValue")));
                	esq.filters.addItem(esq.createColumnFilterWithParameter(3, "SysAdminUnitRoleId", "83A43EBC-F36B-1410-298D-001E8C82BCAD"));
                	this.console.log("The Id is: "+this.get("PrimaryColumnValue"));
					esq.getEntityCollection(function (result) {
						if (result.success && result.collection.getCount() > 0) {
							result.collection.collection.each(function(item) {
                              	var collectionValue = result.collection.getByIndex(0);
                              	var actualId = collectionValue.get("Id");
								this.console.log("ESQ result: "+actualId);
                              	this.canEditRecordOperation();
                            }, this);
						}
				}, this);
              },
              init: function(){
                this.callParent(arguments);
                this.checkIfTheUserIsASystemAdministrator();
              },
              canEditRecordOperation: function(){
                var operationsToRequest = [];
                operationsToRequest.push("CanEditSystemAdministrator");
                RightUtilities.checkCanExecuteOperations(operationsToRequest, function(result) {
                    if (result) {
                        this.set("CanEditSystemAdministrator", result.CanEditSystemAdministrator);
                        console.log("Can user edit record? "+ result.CanEditSystemAdministrator);
                    }
                }, this);
              }
            }
		};
	});

You will also need to add all the fields to the schema diff to include all other fields (in my example "Username" and "Password" fields are included into the logic). Also you need to create an operation permission with the "CanEditSystemAdministrator" code. As a result each time the page is opened an ESQ query is executed to check if the system user whose page was opened is a system administrator or not (included into "System administrators" role or not).

As a result even if the Supervisor user is not added to the list of users in the "CanEditSystemAdministrator" system operation this user won't be able to edit "Username" or "Password" columns:

As for visibility of system administrators in the detail you mentioned or in the section grid - I believe its a complicated task and applying the method above will restrict users from editing existing records so they won't be able to do anything with system administrators records (or will be able to do that in case they are added to the system operation users list).

Best regards,

Oscar

Oscar Dylan,

I got the main idea here.

It's a UI disabling strategy to prevent field updates based on a newly created Operation Permission.

I'm concerned about a user who can hack his way with the DataService API to edit the user password and bypass the UI limitation.



What do you think?

Thank you

Mohamed

Mohamed Ouederni,

Then you need to restrict the endpoint of such a dataservice for users that shouldn't modify system users (something I've described here). Because restricting access on the application level will be a hard task (if it's even possible).

Best regards,

Oscar

Ok, I will look at this:

Oscar Dylan writes:

Then you need to restrict the endpoint of such a dataservice for users that shouldn't modify system users (something I've described here).

I don't know why it's impossible to achieve this using Creatio Access Rights System.

I thought a combination of Operation / Object / Record Permissions will solve the task.

Oscar Dylan writes:

Because restricting access on the application level will be a hard task (if it's even possible).

Mohamed Ouederni,

It's because in the base UserPageV2 the "Actions" button is removed (this code on the UserPageV2):

{
					"operation": "remove",
					"name": "actions"
				},

Also the SysAdminUnit object has no SysAaminUnitRight table (and we remember that record access rights are stored in the SysEntityNameRight table that is created upon activating records access rights). So that's why I've proposed to create a JS logic on the page that will lock all the fields and will use a system operation to manage access.

Best regards,

Oscar