Add permission to control access to role field into edit operation

@CRZDEV thanks. I think instead it would make sense to use the field_permission module?

https://www.drupal.org/project/field_permissions →

(but I'm not generally against adding this permission - still it might conflict with that module if already in use)

To not make a breaking change, this would need an update hook to give the permission to at least inform users about the change.

Thanks @Anybody for reply. I'm working with CRZDEV in the same project. While field_permission would work we think is better to have this option in the module because it seems like a usual case: it makes sense that users that are provided access by this module are not able to revoke access by themselves by modifying the "Role access" field.

Your concerns about other access mechanisms is totally legit. The problem is this fix is final on accessing the role field. What I mean is with this fix users would be able to access the role field or not taking only the permission into account (I mean the permission that the fix adds, edit_role_field entity_access_by_role_field permissions). Thus, it won't possible to add more complex logic: you either have access to the field or you don't have access depending on you having or not the permission.

This can be fixed adding a new configuration in the field, something like "Block access to the role field on editing operations to avoid users revoking access by themselves accidentally". When this check is false (so no blocking access to role field) we should return Neutral, allowing complex logic using field permission or other modules. When the check is true, we would return access granted or forbidden depending on the permission (if bypass permission is on user has access). This would imply changing the configuration schema and creating and upgrade path where:

• Bypass permission is not granted to any role.
• The setting to block access to role field is set to false.

I think those changes would be enough to provide the functionality while preserving current behavior.

Would agree on this approach?

Thanks @tunic - I agree in many points. But adding another setting / config would make things even more complex, so I'm not a fan of that.

@Grevil what do you think?