[IN DEV] Entity-level permissions

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 :grinning:

4 Likes

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.

4 Likes

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:

1 Like

Awesome! :muscle: It’s looking great! :heart_eyes:

Thanks for the update!

Awesome! :heart_eyes:

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 :partying_face::partying_face:

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. :thinking:

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 :star_struck:
– 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