Setting field/UI properties based on conditions

Ideas & Features
1

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.

2

Big ask no kidding!!! It’s a killer idea.

3

+1

Would be awesome if we can somehow easily block sensitive data!

The workaround I have right now is the following

  • Create a ‘mirror database’
  • When an entity is created in the original database, then also create it in the mirror database
  • Then retrieve all non-sensitive information via formulas
  • Only give access to the mirror database

So original database is ‘Contact’
Mirror database is also ‘Contact’ → but then in a different space.

All information in the mirror view is retrieved by formulas → the contact itself can’t be opened

image
image1102×278 16.2 KB

This workaround is helpful if you just want to share some data and block everything else. So example: create a view so that your assistant has access to all addresses to send a Christmas present, but not to all other data in the contact.

It’s a bit ugly, but it works :slight_smile:

2 Likes
4

While we are keen on ridiculous levels of flexibility here at Fibery, at this point I don’t see a UX with reasonable complexity that allows for workspace-wide Field-level conditional logic.

Field visibility and editability are not exclusive to a certain screen but should be enforced across all the APIs and visualizations. Unfortunately, it’s very tricky to devise a good solution that doesn’t bring the performance of the app down.

Yvette’s workaround (or variations of it) is the best we can do for a while. We have a few ideas on how to make the workaround more accessible but have invented no major breakthroughs yet.