It's not possible since this message is returned by the GetCanEdit method from RightsService class from this part of code:

if (isNew) {
				bool canAppend = (rightLevels & SchemaOperationRightLevels.CanAppend) == SchemaOperationRightLevels.CanAppend;
				return rightsHelper.GetCanAppendSchemaOperationRight(schemaName)
					? string.Empty
					: (canAppend
						? string.Format(new LocalizableString("Terrasoft.Core", "Entity.Exception.NoRightFor.Insert"), schema.Caption.Value)
						: string.Format(new LocalizableString("Terrasoft.Core", "LicHelper.Exception.LicenceNotFound")));
			}

And the string is formed using the core entity exception.

Hi again,

I slved the first part (revoking edit/delete permissions for VIP contacts) but still struggling with the second part (revoking read access to sensitive fields).

Any help on this would be highly appreciated!

Thanks,

Robert

Hello Robert,

If I understand right, you can refer to this guide: https://academy.creatio.com/documents/administration/7-16/managing-colu…

Regards,

Akira Nguyen

Phuong Akira,

Hello Akira,

thanks for the reply, but this is not solving the issue. The reason is that I have to conditionally restrict access to the field.

Only when the contact is a VIP contact (that is, if it has a certain detail record), the sensitive fields should get accessible only by a certain role.

If I use column permissions, the field (eg the mobile number) will be restricted on every contact, not just VIP contacts.

Thanks,

Robert

Hello Robert,

To solve your issue, I think you can combine some coding + business rule

1. You can code method: if usr with specific role open page, set 1 usrfield = true; else = false

2. Business rule: customer = VIP AND usrfield = true; hide mobile phone field

Sorry, I am not a coder so I cannot guide you on how to code it.



Regards,

Akira Nguyen

If the protections on data are to comply with legal regulations, then client-side hiding or editing restrictions are not enough. I don't know what Robert's requirements for this are, but suggesting client-side logic to hide sensitive data without knowing why its access needs to be restricted is dangerous.

Harvey Adcock,

Hello Harvey,

you are absolutely right and I do not want a solution to hide the data via the UI.

The requirement is not based on legal regulations, but nevertheless, I want a robust solution where the user can't access the data no matter what he/she tries (the user could add the sensitive field in the list for example).

Unfortunately, I haven't found such a solution that is doable with the means of creatio permissions.

Do you have an idea?

Thanks,

Robert

Robert Pordes,

It would be a nice feature, given that Creatio has the ability to do row level security on a per-user basis, but it isn't possible currently.

The closest thing I could think of would be to have an extension table holding the sensitive data, which has its row level security applied by the Business Process you mentioned, but from what I can tell Creatio doesn't support extension tables either, so it would be a very code-intensive process of building that functionality in Creatio first...

Sorry I can't be of more help, hopefully others have some better ideas.

Dear Jordy,

If we are talking about the record permissions, then the users will not be able to see/edit/delete records if the role is deleted.

For example, I have a default Finance organizational role. The users who belong to it can see the contacts. If I delete Finance role, the correspondent role records from SysContactRight table will be also removed and as the result my users will not be able to see the contacts.

I'd suggest to create the new role firs, assign it to these users, update the records permissions after assigning the required rights and only then remove the old organizational role. It will prevent the users from loosing the ability to see/edit/delete the records.

Apart from that, you can test such actions on the website copy prior making any changes in the production environment.  

Regards,

Dean

Hello Ramnath,

Could you please provide us with screenshots of the business process elements settings for further assistance on this matter?

Thank you in advance! Looking forward to your reply. 

Olga. 

Olga Avis,

Here are the screenshots of elements:-

1. Trigger element - record added

2. Read portal user name (Field name - Borrower)

3. The access rights added

The Role is the name of borrower which was read in 2nd Read Borrower element.

This process is in my local dev environment. I have also created the same process on a trial cloud environment. But the process does not seem to work. 

Is there anything I am missing?

Hello,

It is necessary to grant the rights not to User role but for the Employee  where you should indicate the value of the Borrower field http://prntscr.com/stoezu .  It should be something like this [#Read Borrower.First item of resulting collection.Borrower#]

As for now you try to grant the rights to some role and the system cannot identify it.

Best regards,

Dean

Dean Parrett,

I assigned the access role in process for employee. And the process works now.

But why can't we do for User role.

Even if it works with employee role. The borrower is not an employee. He/She is an end user who will fill the form. Why does it have to be assigned in Employee role.

Can you please elaborate?

Thanks

Ramnath

Hello,

The thing is that your process doesn't read the user role. It would be necessary to find the user's role first using additional read data elements and based on which role is found by, use it in Role parameter instead of Employee.

Regards,

Dean 

Dear Kavian, 



To log changes in object permissions you need to make sure that "Log entity access rights management events" system setting is enabled. It's code is "UseAdminEntitySchemaOperationLog". 

Please note that only changes applied in "Use record permissions" will be logged. 

In order to log changes in column permissions there, you will have to turn on the "UseAdminEntitySchemaColumnLog" system setting. 

As for the Operation Permissions changes, they are not logged in Audit Log. 



Kind regards, 

Roman

Hi,

Link "Object permission" will take you to the new interface, while "Advanced settings" in admin area are still leading to old interface. May be those users used different links? 

Best regards,

Angela

Angela Reyes,

Using the Object permissions link takes me to the page in Advanced settings, not the new UI. This is true for all but one member of my team. The new functionality is not working reliably.

Janine White,

It is likely that internal feature that turns on this functionality is turned on only for that user. Tu turn that on for all users you can run the following SQL script: 

DECLARE @featureCode varchar(max) = 'NewRightsManagementUI',

 @featureId uniqueidentifier;

set @featureId = (select top 1 Id from Feature where Code = @featureCode);

IF @featureId is null

BEGIN

 insert into Feature

  (Name, Code)

 values

  (@featureCode, @featureCode);

 set @featureId = (select top 1 Id from Feature where Code = @featureCode);

END;

delete from AdminUnitFeatureState where FeatureId = @featureId;

insert into AdminUnitFeatureState

 (SysAdminUnitId, FeatureState, FeatureId)

values

 ('A29A3BA5-4B0D-DE11-9A51-005056C00008', 1, @featureId);

Best regards,

Dennis

Dennis Hudson,

How did that get turned on for only one user in our instance?  I thought this was a core feature of bpm'online studio. This is not something that we have set.  If it is being implemented universally for System Administrators, shouldn't there be a setting for it and/or be implemented for all or none based on the System Administrator role automatically?  Will we have to do this every time there is a new System Administrator? This seems like a bug, not a feature, to me.

Janine White,

Unfortunately it is hard to tell how it could get turned on only for only one user as the changes in AdminUnitFeatureState are not logged by default. It may have happened because of some glitch in updating process, also this may have been set with a query in SQL executor. Nevertheless, the script I've sent earlier turns this feature on for All employees organisational role.

Best regards,

Dennis

Dennis Hudson,

Again, this was not set by anyone on my team.  If there was a glitch in the upgrade, what else was missed?  Should we roll back our instance 7.13 and have the 7.14 upgrade reapplied?

Janine White,

Dear Janine,

We've resolved this issue in terms of support incident. As described the issue was in incorrect feature activation. We've reactivated it for your application and it resolved the issue and all users are now able to see new access rights designer. These are SQL-queries that were used while resolving the issue:

delete from AdminUnitFeatureState where id = '0A27067D-5177-401D-9D17-9586B27F9EA8'

insert into AdminUnitFeatureState(FeatureId, SysAdminUnitId, FeatureState) values ((select id from Feature

where Code = 'NewRightsManagementUI'), 'A29A3BA5-4B0D-DE11-9A51-005056C00008', 1)

Best regards,

Oscar

I appreciate the fix.  The interface is working for everyone now. However, as a Quality Engineer, I'm concerned about root cause. As I mentioned above, if the discrepancy was the result of a bad install, then there could be other issues that need to be resolved as well that we haven't realized. For example, the 7.14 upgrade also broke the main menu system.  It is no longer ordered as specified in Workplace setup, rather it only appears alphabetically, which has been reported to support.

Janine White, 

Without gathering logs and investigating the issue on the site it is hard to determine what exactly caused the issue, Please send email to support@bpmonline.com so the issue would be analyzed on your site based on your request as a support case. 

Best regards,

Dennis 

Dennis Hudson,

That's already been done and the fix applied in request #SR-0806825. The root cause provided was, "The reason of the issue was in deactivated feature called 'NewRightsManagementUI," but I'm not sure what that means other than it was a coding issue that was overlooked before publishing to production.