[DONE] Entity-level permissions

Ideas & Features
,
81

This is definitely a use case in scope

1 Like
82

Will Entity-level permissions feature be released as one feature, or in multiple stages or multiple feature implementations? Any estimation of the first experimental feature of that? Thanks!

83

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)

4 Likes
84

Wow, that would be awesome! Is that on field level then? Or database level?

85

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.

7 Likes
86

Thanks! Awesome!

Given the new entity permission model, what would be your advised structure when you want to hide salary when salary is a number field that currently lives on entity employee?

Would you then create a separate database for that field only or is there another smart way/workaround?

87

This is probably the best option, and for reasons other than access as well. For example if salary changes over time, you might want to link a person to more than one salary (each with a start date and end date).

2 Likes
88
7 Likes
89

wow, I must admire that UI 's really impressive

1 Like
90

Is it just me, or is that video too low-res to understand what’s happening?

91

Hmm, unfortunate recompression of the embedded Tweet. If you reference the original on Twitter it’s legible: https://twitter.com/fibery_io/status/1722980967927689245

3 Likes
92

Can’t wait to test the new entity-level permissions feature !

2 Likes
93

The first experimental release is here:

Please let us know if it brings any value to your team and what’s missing if it doesn’t :face_with_peeking_eye:

6 Likes
94

Being able to control access by a User Group will be a huge additional benefit :+1:

4 Likes
95

User groups would be so helpful - we use them in google workspace to manage our teams there

3 Likes
96

Welcome @Lee_Denny to the Fibery Community! :smile:

1 Like
97

For the common scenario of users needing access rights to organic groups and organic group content , where the term group is not the permission groups in the admin section, but groups that can be created by users without admin intervention:
If we have the same database ‘Task’ that is used across 100 organic groups,
If organic group membership means that an organic group manager can approve individual membership requests
I assume that:

  • There is a way to set permissions for each organic group enitity such that the tasks related to that entity can not be accessed when a user is not member of that group.
    ?
98

Also, if permissions can be depedent on an entity level relationship, then a feature/setting ‘required relationship’ is needed in the database field setting, to make sure that people do not forget to assign it to a group/project if that enables the permissions.

99

Based on my understanding of what you are describing, this is possible with the new permissions model, using the ‘extend’ capability.
That is to say, if a Team is linked to Tasks (one-to-many) it is possible to configure the permissions so that access to the Team automatically implies access to its Tasks.
Eventually, it will be possible to automatically grant Project access based on a User relation to the Project (i.e. any User linked via the Member field has the permissions needed).

1 Like
100

That is amazing, looking forward to that!
Would the ‘extend’ capability apply to the first level relationship, or can it extend unlimited in a hierarchical relationship tree? I’m thinking of for example top-down lockdown of:
Company > Department > Group > Team > Project > Milestone > Task > Dependent Task > Action > Note etc…