New permissions model: Groups

News & Announcements
1

We are releasing Groups today, here is the in-depth article on how we approaching access management in Fibery

6 Likes
2

While I donā€™t really have use myself for such powerful permission management, I do love that you are taking this approach! It is very much in line with the Fibery philosophy thus far, and continues to demonstrate (to me, at least) the benefits of that approach.

That said, it does seem of most benefit to larger orgs. Thatā€™s where the money for Fibery is, no doubt. So I get the priority here. But I think ā€œdashboardsā€, embeds, and a number of other things will also benefit them, and everyone, so I hope to see them focused next/soon. :smiley:

1 Like
3

Love it! :sparkling_heart:

Will it be possible to apply this approach not only to entire apps, but also to entities, based on field/relation values of the entity?

E.g., I will have a ā€œCustomerā€ Type, and a ā€œCustomersā€ class of Users, where each Customer User is related to a specific Customer entity. I want to limit the ā€œCustomersā€ users to only access entities (e.g. Project and Task entities) that are related to a the same Customer.

4

Yes, this is exactly what we will implement in Per-entity permissions. However, itā€™s hard to forecast when it will be done, most likely it will take 3+ months. But what we can promise is that we will have a team dedicated to permissions this this problem will be solved.

2 Likes
5

100 Internet Pointsā„¢ for doing it right :trophy:

1 Like
6

:clap:

Is it possible to implement a dynamic permissions system?

I currently have defined a Role type, and I use a ā€˜helperā€™ type (Assignment) that allows users to be assigned to a role with a start date and an end date, i.e.

Role 1:n Assignment
User 1:n Assignment

I use a formula in the Assignment type to determine if it is current (start < today < end) and a formula in the Role type to filter for all related Assignments that are current. I can then have a lookup in the Role type to find all Users who are currently assigned.
This means that the Role type does have a relationship to the User type, but it is a calculated, read-only relationship, and I canā€™t enable the ā€˜Use Roles to manage accessā€™.

Any suggestions?

2 Likes
7

This looks very promising and seems to be a great approach. In light of the approach and some of the examples mentioned with use nested hierarchy, I was wondering if more thought has been given to nested hierarchies. I think those are somewhat important to this feature, especially if you are able to handle inheritance from parents (which might be the solution to an entity having two parents, ie one is the actual parent, the other inherited)

8

Thatā€™s quite an interesting case and (funny enough) weā€™ve just discussed a similar one today.
So far the workaround is to use automation rules + relation instead of the lookup, which is less reliable but unlocks Groups.
Weā€™ll try to brainstorm a native solution though.

1 Like
9

Could you please provide an example in the context of group permissions?
Are you thinking about Department ā†’ Team group membership inheritance or Project ā†’ Task access inheritance?

1 Like
10

Yes, I did think of either using automations or auto-relations to achieve the functionality I needed, but I couldnā€™t fathom a way of doing it.
The automations canā€™t be set to trigger when a collections field is updated, and I didnā€™t manage to find a rule that would allow to auto-relate Roles and Usersā€¦

What did you have in mind for a workaround?

1 Like
11

Letā€™s take a pause with workarounds for a couple of days: we might have a highly experimental but native solution :crossed_fingers:.
Iā€™ll get back to you via Intercom, once we are ready.

If someone else is interested in using calculated Users collection as a Group, please ping us via Intercom. If experiment succeeds, weā€™ll make the feature public but so far weā€™d like to keep it secret :slight_smile:

1 Like
12

:+1:
Highly experimental is fine :slightly_smiling_face:

13

I was thinking more along the line of department to team inheritance.

The reason I linked to the nested relationship thread was that for sufficiently complex organizations, they may have an arbitrary/varied level of nesting so the ā€œorganizational unitā€ concept rather than company/department/team model might be needed. It would be great to be able assign broad permissions at higher levels and have those cascade down and be supplemented by other more specific permissions.

2 Likes
14

Hi @antoniokov, I have the same need.

I have an Employee type that have multiples fields (address, phone number, start date, etc). Each Employee is linked to several types:

  • User type (one-to-one relationship): if the Employee is User
  • 1:1 Meetings type (one to many)
  • Team type: hierarchical team
  • Squad: for cross functional teams
    etc

I would like to use Team and Squad for permissions, but I cannot since they are linked to Employee and not User directly. So a way to ā€œpropagateā€ the connection to User would be helpful.

Alternatively, I wonder now if I need the Employee type. I thought that it was not possible to add fields to User (but I was wrong). And for the Employee that will not be Fibery users (or at least not initially) Ć©i could still create them as User and deactivate them.
Do you recommend to use User and customize it instead of my Employee type?

In any case we will still need to have a solution to allow types that are indirectly linked to Users to be used as group. The simples example is having a the following types and relationship
Department ā†’ Team ā†’ User
It is natural to be able to assign permissions at the Department level.

15

Iā€™m not sure that is a solution, since you canā€™t really do anything with deactivated users (link to them, assign to them, etc)

1 Like
16

Got you, makes a ton of sense.
So here is a way to model this in Fibery:

  1. Create Unit Type with one-to-many relation to itself (Parent Unit ā†’ Units).
  2. Visualize Units via a Hierarchical List to build the nested hierarchy.
  3. Add a many-to-many relation from Unit to User and mark it as group membership.
  4. Link Users directly to their lowest level Units.
  5. Manage App access via Units.
  6. :pray: Automatically inherit access: if a User is a member of Unit iOS Developers and either parent Unit Mobile Developers or its parent Developers have Editor access to an App, then the User should have the Editor access as well.

At the moment, we are missing the #6.
Here is a question: do you have people that do not belong to any lowest-level Unit (like iOS Developers or Android Developers) and are assigned directly to some higher-level Unit (ex. Developers)? If yes, who are these folks?

2 Likes
17

I donā€™t ā€” at least at the moment. As @Chr1sG pointed out, deactivated Users arenā€™t designed for this use case. There is a chance weā€™ll change that but not sure about the ETA.

Instead, letā€™s try the same experimental solution Iā€™ve mentioned above. Iā€™ll come knocking in Intercom (;

18

Implemented in latest release CHANGELOG: July 22 / Action Buttons in Table View, Improvements and bug fixes