That was not planned. Any use case you have in mind?
actually, that is one of the main things i hope you implement
Contact management is an example where in general i want to give access to all contacts in the database. but sometimes there is a private contact that referred a contact. i want to add that information for myself, but I don’t need everyone to get these private phone numbers and email for example.
also emails that I sync to fibery would be a good example. my company account gets synced and in general all these emails are good to be read by everyone. but sometimes there is a conversation i want to set private.
i guess there are a lot of examples where a database is shared in general and only some entities need privacy where this “set as private” setting would make sense instead of the other way round …
thanks for asking!
I am hoping that the Entity Locking feature will be part of this permissions implementation with automation rules?
The idea is that a lot of content in an organization is time-sensitive, e.g. financial entries or meeting minutes, or other reasons why editability is rule-based.
Thank you for the clarity!
It is taking shape
The new permissions model looks great!
If this can eventually also be applied to Views then we would have 80% of “field-based permissions”, since we could expose our sensitive DB fields only in certain Views, which could then be permissions-restricted.
Multiple entity views would complete the picture
We do have plans to Share Views (via new permission model), but not this year for sure. However, in this shared view a visitor still can open some entity and see more fields, so it is not enough to just have that, we should add Entity Views to make it work for your case.
My thought was that any “sensitive” fields could simply be hidden in entity view.
But it’s even better to make the entire entity view subject to permissions as well
Awesome! It’s looking great!
Thanks for the update!
We also have several GDPR use cases on contact level that are currently a pain in the ass. Would be awesome if this can be fixed in the future via new permissions model
This is really exciting development and looking forward to trying it out.
However, similar to @Matt_Blais & @YvetteLans , I am hoping we are able to get to be able to have some field level controls, even if it is through creative means. I posted Setting field/UI properties based on conditions request with a proposal on this front. It is nothing new that hasn’t been discussed in some form in other posts, but I thought this might be a good time to bring the ideas together again since there is renewed discussion on permissions and how information is presented in the UI.
Unfortunately, we will never implement field-level permissions due to tech. limitations. The only viable workaround that will work — create some additional Database, move all fields you want to hide there, and use 1-1 connection between this database and original database. Thus you will isolate fields, but editing will be not very easy, always extra-clicks…
For example, you may have Employee database and want to hide Salary. In this case you will have to create Salary Database and link it to Employee.
I see a different possibility, though perhaps you don’t intend to implement that either:
If you had multiple layouts for a given database (entity view), and they could have unique security settings per-layout (which I would think is easier to implement than per-field permissions), then you could simply put sensitive fields (ones that not everyone should see) onto a different layout with special permissions. The likely failure case for at least some people would be desire to have fields that are visible but not editable, depending on permissions, which becomes more field-level permissions than unique layouts.
The problem with these sorts of workarounds is that if the permission control is not strict (and relies solely on UI) there are ways that sensitive data can ‘leak’. For example, API access is not affected by view settings. Or if a user has creator access in one space and read-only access to the space containing the ‘sensitive’ field, he/she can create views/formulas that do not have the same limitations (hidden fields) as those created by other people.
That’s a fair and important point. My resulting question would be: assuming there is enough utility in the “individual layouts” feature request, and that implementing permissions per-layout is not hard, would it not be better to have some solution than none? I get that a solution that offers a false sense of data confidentiality is not good, so there would have to be some caveats around that, but I do think people would still get plenty of value out of it.
Possibly. But I suspect we would be more likely to be head down a route where adding a (strictly controlled) linked database is as easy as adding a new field (and where it is possible/easy to edit the linked entity’s properties without having to navigate to it - all subject to permissions of course).
Ah, fair enough then! I still want multiple layouts per DB/entity type, but what you describe also sounds very useful.
@Chr1sG I understand the limitations. As @Oshyan pointed out, I guess the options we are suggesting (either having conditional control over fields and/or multiple layouts) would be half measures from a permission-perspective but they would also have other useful benefits. So they can be suggested as possible workarounds (along with separate dedicated database as @mdubakov indicated) each with their own limitations, so creators can choose based on their needs. For example, in many cases, hiding or locking fields is not so much a matter of security but convenience/user experience.
This is true, but it is orthogonal to permissions. Entity Views is something we do want to dig into eventually.
This sounds very helpful for GPDR use cases!