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.
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.
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).
@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.
If that’s like a JOIN, that would be FABULOUS
– i.e., if we could treat/use a linked entity’s fields as we can the main entity –
and it would answer a big part of the need for some kind of polymorphism, and allow for much better DB normalization.
Also, I’m not fully sure what is meant by the extend button. What does it do? Can’t figure it out from the video. It looks like it just shows which other databases that specific user has access to, but not sure what the added value is in showing that there.
For example, you have Product and inside you have Features and Tasks. When you just share Product A with some person, all related Features and Tasks are not shared (so far). When you click Extend button, only then all features and tasks are shared