[DONE] Entity-level permissions

[Chr1sG]

@Yuri_BC

That is amazing, looking forward to that!

The extend capability already exists in the (experimental) entity permissions, but for the default access levels, it only applies to one level down.

@Yuri_BC

can it extend unlimited in a hierarchical relationship tree?

When we roll out custom access templates, they will allow propagation to multiple (but not unlimited) levels.

[Jonathan_Oaklyn]

We often need to share individual entities in Fibery with our clients. We are a custom dev shop and want to, for example, create a checklist for our clients to be able to complete themselves without having to add full user seats for every person working for the client.

Being able to either add guests that can edit only certain documents, or create public links that allow editing would be super helpful.

[Yuri_BC]

@Chr1sG

When we roll out custom access templates, they will allow propagation to multiple (but not unlimited) levels.

I think that people are generally accustomed to the idea of folders and that everything in a restricted team folder is therefore also restricted to team members only. This applies to any content type in the folder, including subfolders.

With the ‘not unlimited access propagation’ in hierarchical relations, this becomes less clear why there is a limitation, since there is not structural logic for that, other than the potential performance logic of the developers.

If the levels of propagation is limited, then I think users need to be warned that if they create child relations beyond that, it will not inherit the access restrictions. How would they be warned?

How do the fibery designers solve the common expectation about access propagation, when users create nested strudtures like:
Company > Department > Group > Team > Project > Milestone > Task > Dependent Task > Action > Note etc…
?

[Chr1sG]

@Yuri_BC

If the levels of propagation is limited, then I think users need to be warned that if they create child relations beyond that, it will not inherit the access restrictions. How would they be warned?

Access is managed through overloading of granted (positive) permissions, not through restrictions.
So if levels are added beyond the limitations of an access template, these levels will be inaccessible by default.

@Yuri_BC

this becomes less clear why there is a limitation, since there is not structural logic for that, other than the potential performance logic of the developers.

Fibery structure is not limited to simple one-to-many pyramid hierarchies, so although access might be simple to apply in that specific case, the permissions model needs to accommodate all the possible (crazy) structures that users might come up with, and not break or get too slow.

@Yuri_BC

How do the fibery designers solve the common expectation about access propagation, when users create nested strudtures like:
Company > Department > Group > Team > Project > Milestone > Task > Dependent Task > Action > Note etc…

In that example, I would imagine that users would have access to the project(s) they are working on and with propagation, to all the ‘downstream’ items (milestones, tasks, actions and notes). Access to departments, groups and teams would be governed by their membership of a team, and through lookups, their implied membership of a group and a department (not via access template propagation) This would probably be something similar to the current ‘contributor’ level.

We haven’t so far heard of a lot of use cases that aren’t covered by access propagation which is limited in the number of possible levels.

[Yuri_BC]

Related:

Exploring solutions for a controlled relationship structure

I don’t think field level permissions is actually the solution to this. A relationship is actually two fields (one at each end) so it begs the question which field governs the permissions. I think a more plausible solution is that the capabilities available in custom access templates get expanded so that the current ‘Edit’ capability (which encompasses the ability to link/unlink items) is split into a limited ‘Edit’ and a separate ‘Link/Unlink’ capability. No idea of if/when this will happen t…

[interr0bangr]

Is there a plan to increase the level of granularity on permissions?

Specifically for the “Update” permission, as in it’s current form it’s pretty wide ranging.

My suggestions:

• Create new entities in related databases
• Link to existing entities in related databases
• Unlink entities in related databases
• Edit “basic” fields
• Create & modify “basic” fields
• Delete “basic” fields
• Create & modify “advanced” fields
• Delete “advanced” fields
• Create & modify views
• Delete views
• Toggle visibility of fields
• Click buttons

[Chr1sG]

@interr0bangr

Create new entities in related databases

This is a permission for the related db, not the entity itself.

@interr0bangr

Create & modify “basic” fields
Delete “basic” fields
Create & modify “advanced” fields
Delete “advanced” fields
Toggle visibility of fields

These are all part of ‘Creator’ access for the database, and I don’t think we will offer more granularity than that any time soon.

@interr0bangr

Edit “basic” fields

Not sure if you mean edit=configure fields or if you mean edit=update field values. If the former, then this too will remain under Creator level for the db.

If you mean that you want to split the current ‘entity update’ permission into the following:

@interr0bangr

Link to existing entities in related databases
Unlink entities in related databases
Edit (=update) “basic” fields
Click buttons

then there may be a small chance a greater level of granularity may arrive somewhere down the line, but please tell us your use cases, so we know what’s in your mind.

@interr0bangr

Create & modify views
Delete views

Permissions for space views are independent of databases/entities (except in as far as you can’t expect to be able to create a data view for dbs/entities that you don’t have view access for!)
The view-specific settings (columns, filters, sort etc.) are in the hands of space ‘creators’.

Relation views are a whole other story, but let’s not go there

[antoniokov]

@interr0bangr

Is there a plan to increase the level of granularity on permissions?

Based on recurring use cases, we might split a capability into two or three, but not more. We are balancing flexibility and complexity here.

Actually, we started with a more granular set but collapsed it after noticing how intimidating it looked.

[YvetteLans]

@antoniokov is there a real-rough-not-to-pin-you-guys-on-it estimation when the following use case is possible:

a user has only access when assigned to the entity or when he/she created the entity

We currently need to decide if we create a more or less ‘separate team space’ for our customers where their team members can only see their own tasks, projects, appointments, notes etc. (still not waterproof since they can use search/link as well, but it’s at least something).

If this feature is quite nearby, we will not do that since it’s a lot of work that’s not needed after this is implemented.

[antoniokov]

@YvetteLans

a user has only access when assigned to the entity or when he/she created the entity

Likely to happen by the end of Q1, veeery likely to happen by the end of Q2. I’ll have a better estimate as soon as we start the development.

[YvetteLans]

Thanks for the update! We’ll keep our fingers crossed

[Illusory]

@YvetteLans

a user has only access when assigned to the entity or when he/she created the entity

We certainly need this as well! Hoping this is coming soon.

[Lee_Denny]

Is this still planned?

[mdubakov]

It is implemented in fact

https://the.fibery.io/@public/User_Guide/Guide/Share-Entity-233