Skip to main content

Unfortunately, we couldn't find the answer to the question below in the documentation/community, so we're asking it here.

When migrating an existing application to the SF environment, all roles, etc. are also migrated.
It turns out that sometimes different roles set permissions on the same objects (tables/fields).
Unfortunately, it appears that some (also migrated) user groups contain multiple of these roles, leading to "rights conflicts".

Example:
role seller has read-only rights to a field in table A
role controller has write permissions on that field in table A
User group "Special employees" contains both roles

Is our conclusion correct that this means that for users with the user group "Special employees" they can only read the field in table A?

Are the lowest rights assumed by default?
Is this a setting that can be set at the application level?
Can we provide insight into these types of "conflicting rights" somewhere?

 

FYI: We use the Windows GUI

Hi Marc,

I'm also not able to find it but the principle is that the highest rights are applied. So if you have a role that grants editable rights to a column and a role that grants read-only rights, the editable rights are granted to the user. The Explain task can help explain why certains rights are granted.

The principle cannot be changed, highest rights are always granted to users.

Hello Mark

Thank you for the reply. I also expected "the highest mutation rights apply."
Yet it seems that this is not the case.

Situation:
- in IAM I go to [User groups] and select the relevant application under [Authorization].
- on the [Roles] screen section, 3 roles are active (1 with Edit rights, 2 with read-only rights).
- with 2 roles I choose 'Revoke role', so that only the role remains active with the "Edit rights"
- on the [Effective group rights] tab I select the relevant application, select the relevant table under [Rights table] and go to [Rights column]
* there I see that the field in question is Editable

# if I then reassign one of the revoked roles (with read-only rights) and refresh the screen at [Permissions Column], I see that the field now has 'Read Only' rights

# this action is reproducible, so revoking the role with read-only rights ensures that the field in question becomes mutable again

Hi Marc,

It sound like that it could be an issue we resolved in 2024.1: Thinkwise Platform Releases | Thinkwise Documentation (thinkwisesoftware.com)

When you open up the application, is the field Editable or Read-only? 

Hello Mark

This indeed appears to be the case.
The field in question was mutable in the application, but it was not displayed correctly in IAM under 'Effective user rights'.

Thank you for the reply. We will soon switch to the 2024.1 version and until then we now know that this problem exists.

Terms & ConditionsCookie settings