Here is how the permissions are set. The user role has view access to the object, but view and edit access to 5 fields for this object. However, they cannot edit the fields inline in a view.
Should they not be able to edit those specific fields? If not, how does field level permissions work?
Which Rollbase version are you on?
You should be able to edit fields on record edit page, inline edit from record details page and inline edit from list view page if field has edit permissions for user role. I'm able to inline edit such fields from list view on latest version.
Can you please check whether you are able to edit those fields from record edit page or inline edit from records view page?
One more clarification : When you say - 'user role has view access to the object'. Does this mean User has No Edit Permissions for that object?
On Roles - Permission page we have four permissions corresponding each object. View, Create, Edit and Delete.
We validate permissions in hierarchy.
1. If User does not have edit permissions on object. We don't check for any other finer level permissions and mark record including all fields as in-editable.
2. We check for Field Level 'Edit' Permissions only if User has 'Edit' Permissions on Object.
My earlier reply to you was assuming Role has both 'View'/'Edit' Permissions and you are facing problems only in field level permission.
Here is what we are trying to do. The object has 107 fields on it. We want users of a particular role to be able to edit 5 of those fields. So it sounds like I have to turn check the Edit permission for the object and then turn off the edit permission on 102 of the fields.
This just does not seem very user friendly. I am using the public cloud and the version is 126.96.36.199.
Thanks for your quick reply. Right Now, we do not have bulk permission select/de-select facility for role-field mappings. So, as you already mention, this is the way we will have to proceed : Giving the Object 'View' and 'Edit' Permissions and then manually un-checking 'Edit' permissions for each of the other 102 fields for some Role 'X'.
I also see the same problem in case we later add a new role, and then need to restrict edit permissions on majority of fields.
However, the current implementation was assuming that application would be designed in such a way where majority of fields will be editable and No/Conditional permissions will need to be applied only on some select fields.