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
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.
We are planning to work on permissions for the next 6 months, so more and more features will follow.
First release may happen in ~2 weeks. It will have many limitations, but might work for some use cases like hiding important information from most users (1:1 interviews, salary, etc) and give access to specific part of hierarchy (everything related to Product A or Team X)
It is on Entity level. For example, you have One-on-One database in Employees Space and it is connected to Employee database. You don’t want to share sensitive info to all users, so you restrict access to this space and only top managers have it by default.
Let’s say you have Teddy as employee. So you can give access to human Teddy to an entity employee Teddy, and Teddy will have access to his employee record, all 1-1 meetings, and other connected entities, BUT Teddy will not have access to all other employees.