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 
1 Like
Awesome! 
It’s looking great! 
Thanks for the update!
Awesome!
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 
1 Like
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.
2 Likes
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.
1 Like
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. 
3 Likes
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.
5 Likes
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.
4 Likes
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).
3 Likes
Ah, fair enough then! I still want multiple layouts per DB/entity type, but what you describe also sounds very useful.
2 Likes
@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.
3 Likes
This is true, but it is orthogonal to permissions. Entity Views is something we do want to dig into eventually.
4 Likes
This sounds very helpful for GPDR use cases!
1 Like
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.
6 Likes
This looks amazing.
This is great, really looking forward to using it!
I assume entity level permissions will be inherited from the database level by default? Something like Notion has by using “based on”:
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.
1 Like
Can you clarify this a bit?
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
Ah so it’s only regarding relations? Seems like a good one.
Sorry I meant “space” instead of “database”.
So since sharing is determined on the space level, will that propagate to it’s child databases / entities automatically? I would assume yes, just wanted to know if that’s the case.
1 Like
When you share a Space, you share all databases and all entities in this space. It works this way now.
This looks awesome!
I don’t think it was mentioned in the video but would this be able to support something like adding view permissions to a third party client (I’m thinking agency-client context).
In some cases I may not need a client to become a full blown member of the Fibery space, but would still like to give them access to a client specific board or document where they can see progress of tasks on a board and also comment.