With the excitement and discussions around [IN DEV] Entity-level permissions I have been thinking about field level permissions. I know that the Fibery team has said that field level permissions are not on the roadmap and unlikely in the near term (see below from recent posts as well as Field-level permissions request):
There has also been some discussion that maybe view permissions and multi entity views might make this not as a big deal:
However, I was thinking that there might be another approach to this. I think fibery’s approach to conditions used for view filter, colour/styling, and relation field filters is a pretty powerful model. And I feel it could actually be a very flexible (and possibly easier) way of addressing the field level permission issue and getting a bunch of other nice side benefits out of it as well in terms of the front-end UI.
I think that it would be great if a number of front-end properties could be controlled using conditions. These include:
Field Visibility: allowing conditions to be set that control if the field is visible (this has been previously proposed by others). If the creator is able to access the current user’s permission data (i.e. group membership) as part of the conditional statement, this effectively can allow the admin to specify field-level permissions. However, the benefits are not limited to permission controls. Admins are also able to use conditions to show/hide fields based on values of other fields, workflow status, etc. .
Field Editability: allowing conditions to be set that control if a visible field is view-only or can be edited. This would again help with permissions by allowing a very flexible model on what users can edit and when. There can be a default state for users who belong only to Viewer groups, but for users with other memberships, the field editability condition would dictate how the user will interact with the UI. This can also be helpful in other situations where admins would like to limit changes once an entity is within a certain stage of a workflow or generally based on value from another field.
Field Styling: allows conditions to be set that control some aspects of UI style. This includes background colour, border colour or thickness, text colour, etc. While this doesn’t have a direct relationship with permissions, having the ability to change the styling based on permission or group membership can have interesting applications (e.g. drawing attention of particular users to fields based on their group membership). The most obvious use of this to change the style based on the field’s value and/or other field values (e.g. highlight fields that are blank, show negative numbers as red, draw user attention to another input field when another drop-down value is chosen in conjunction with setting visibility, …)
One of the pre-requisites for this model to work well is to extend the condition logic to accept formulas, which would also have many benefits for how views work (and reduce having to make all sorts of helper fields).
I realize this is a big ask and it may never be feasible. But on the surface at least, it seems to tick so many boxes at the same time as being a more flexible approach to just having field level permissions.