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

 Dear Julio,



Unfortunately, it is not possible to implement this logic through Business rules as we cannot create business rule for contacts in accounts.



The solution here will be to build the described filter using EntitySchemaQuery.

Here is the article - https://academy.creatio.com/docs/developer/back-end_development/working…



Best Regards,

Ivanna

Thanks Ivanna

I get this often with the Excel reports builder package. Usually after logging out and back in (sometimes after a couple of times) it usually lets me add it to the workplace eventually. Not sure why this happens, but it only ever seems to happen for me with this package (and happens often with this one)

Ryan

In the mean time, you can still navigate to the Excel reports section by entering the url

/0/Nui/ViewModule.aspx#SectionModuleV2/IntExcelReportSection/

Ryan

Thank yo very much Ryan.

 

Hi Stefano,

To apply the changes, we recommend logging out and logging back into the application again (just like Ryan says above). If the issue persists, try adding any basic section to the workplace first, and after that add the 'Excel reports' section.

Hope this helps.

Thank you very much Svetlana!

The second trick has worked!

Hi Stefano,

Try to follow this article on how to add field validation:

https://academy.creatio.com/docs/developer/front-end_development/creati…

Regards,

Dean

Hello Stefano,

The * sign indicates that the package or scheme was changed. This parameter is set in the SysPackage or SysSchema table and the column name is "IsChanged".

Best regards,

Bogdan S.

Thank you Bogdan,

a clarification,

how could this have happened? I have configured a new custom package and set it as the default

Stefano Bassoli,

I suppose you did some changes in the website configuration that caused such behavior. Please note that this is not an error but regular OOB system logic.

Best regards,

Bogdan S.

In custom package appear Account

Is it possible to sanitize the issue?

Stefano Bassoli,

You can remove the object from Custom package but make sure that this object does not contain any valuable changes that must not be erased. 

Best regards,

Angela

Thank you Angela

I try what you suggest

Dear Stefano,

In order to change the dollar sign to the euro please navigate to the metric dashboard settings, click on the "How to display" tab:

After that please press the "Format" record and insert the euro sign in front of the {} brackets (so when you save it would look like this: €{0}).

You may see the result in the screenshot below.

Regards,

Danyil

Thank you Danyil!

Hello Kevin,

It is necessary to go to the section Page Setup, scroll down to New button, select Embedded detail option, add your detail and hit New column to add required fields. You can also the fields them in the required order there. 

Regards,

Dean

Hi Stefano,

You can do it as usual - perform an import and when mapping columns just map your custom column to the column from the file.

Best regards,

Oscar

Oscar Dylan,

Hi Oscar

I added a new field on AddressAccount entity named region.

This new field don't appear when setting the import, see the screenshot

What Am I doing wrong ?

Stefano Bassoli,

Hello,

Please check if the column is present in this list:

and

and select the column. In case the column is not present then either the AccountAddress object should be published or the parent object for the replaced AccountAddress object was chosen incorectly. Please check if your parent object is the same as mine:

If it is not please remove the replaced object and replace the AccountAddress object from scratch.

Best regards,

Oscar

Oscar Dylan,

Thank you Oscar,

It works

Hello Stefano,

Please check my screenshot below. This is the way you can build your filer on boolean field:

Best regards,

Bogdan S

Thank you!

Dear Amandine,

Usually, this error means that IIS user does not have access to all paths Creatio needs to compile the application. Try to provide full access to IIS user and check if it helps by performing full compilation. 

Best regards,

Angela

Angela Reyes,

Hi Angela, it was indeed a permission issue, got solved the same day :) Thanks for answering !