At the moment, it seems like the current permission levels could be represented as follows:
Level
View entities
Edit entities assigned to me
Edit entities
Configure views
Configure types
No access
Viewer
Y
Contributor
Y
Y
Editor
Y
Y
Y
Creator
Y
Y
Y
Y
Y
I think there may be a need for other combinations, e.g.
a user who can edit entities assigned to him/her but cannot view any other entities
a user who can configure the app but not create/edit the content (a.k.a. entities)
a user who can view entities (but not edit them) and can configure the setup of a view (e.g. change table sort order, apply filters, choose which fields/columns are visible)*
To do this, I wonder if it might be useful to consider permissions along separate dimensions, namely:
Entity viewing
Entity editing
View configuring
App/type configuring
and allowing for the permission level in one of these dimensions not to be uniquely tied to a specific permission level in another dimension.
Another follow on comment:
Perhaps there ought to also be a permission dimension for âButton pressingâ since it can be useful to allow a user to trigger certain things, without necessarily allowing them to have other permissions (editing, configuring)
Entity-level permissions are comingâŚsome day!
Here weâve got a ton of feedback and a few great use cases. Now itâs a question of solving a tough technical challenge.
To be honest, Iâm skeptical that a person can set up a structure for an App or even a View without seeing it in action. I havenât seen great tools where access to metadata is granted without granting access to data. Perhaps, youâve got an example you were inspired by?
Before we dig deeper into custom access levels: do you have specific scenarios in mind that are blocked by the current permission model?
Usually, each Button has its own limitations on who can press it: think Approve Requirements vs. Deploy to Production. When building a Button, you are free to check if the person pressing it is the right one and stop the execution if not.
In scripted Buttons I recommend throwing an error to notify the user:
// figure out if the User has the right access
if (!hasAccess) {
throw new Error(`Sorry, only đ Chris can approve requirements.`);
}
I think a similar approach will be possible in the no-code Buttons as well.
It does sound a bit crazy I know, but if I am setting up the HR App, I would like to be able to define, for example that each employee has a salary field, a relationship to a manager, and the employee type has the Files extension enabled (so that a CV and/or job contract can be attached) but I donât actually want anybody except the authorised HR manager (who isnât me) to be able to see the information about my fellow employees.
I can think of a few examples of other situations where it is useful to limit a userâs view of entities not assigned to him/her whilst still being able to retain the ability to edit the ones that are assigned to him/her. For example, If a company maintains a list of clients, with notes about the relationship, it might be appropriate for members of the sales team to not be allowed to see client information for those clients he/she is not responsible for.
I donât personally have this situation, but I guess in some businesses, there might be good reasons why you donât want the sales team in the US to know what the sales team in Europe is discussing with itâs customers. Plus, with some GDPR issues, you might need to restrict what information is disclosed to whom.
I was actually thinking of the situation the other way around. At the moment, Contributors cannot see the buttons at all, but it might be useful for them to be able to perform some limited actions, even if they donât have full edit permissions.
One example I could think of is allowing some people to move an entity through different states of the workflow, without changing it, e.g. if I am a reviewer, I want to be able to move the item to the âreview completedâ stage (or reject and send it back to the âdraftâ stage) but the original âownerâ doesnât want me to be able to edit it.
So, you grant permissions for these entities, not to the entire âSales Teamâ group, but only to the individual team member(s) associated with that account.
So we need to grant permissions for a particular button/Action to users/groups that do not necessarily have âedit/updateâ permission for the entity. And this would allow the script/Action to edit/update the entity in a limited, predetermined fashion on behalf of that unprivileged user/group.
Well, at the moment, I canât grant edit permissions to some entities of a given type and not simultaneously grant view permissions to other entities of the same type.
Even that wouldnât fix it. The problem is that any person/group with permission to edit entities assigned to them is automatically given view permissions to entities not assigned to them (of the same type).
Just to be clear on this: Contributors can see Buttons and click Buttons on the Entities they are assigned to. If a User has only read access, the Buttons wonât appear.
Itâll be interesting to explore some middle ground, not sure how to incorporate this into the permissions model though.
Yes, thatâs the current best workaround: separate apps for different customers.
Itâs not ideal, but the permissions model is being worked on, and this issue will get addressed.
How can I vote for this feature?
I am trying to separate apps but it is not pratical: my software development is linked to okr, product and so on, the copy is not linked and so I lose fibery advantages.
Yes. Unfortunately, that is the case.
It is not currently possible to restrict a user from seeing entities that are the same type as the ones he/she is contributor/assigned to without siloing the information, and that loses the advantages of connectivity
But soon it will be possible
Thanks again for reply, but this is actually my worst nightmare.
I am discovering other problems:
I am not able to create multiple copies of my application, perhaps I am stupid but going in new app/templates it shows the âgoto appâ button and it sends me to the existing one
now people will have to look in two (or three) different places to see their tasks and I cannot anymore calculate capacity in an easy way.
You can still create views that display entities that come from multiple different apps.
If the data is siloâed in different apps, then any aggregation will require that the same types from each app are all linked to the aggregation type.
Itâs far from ideal, but until the new permissions model is rolled, out, it is the only way, unless maybe you can live with people having view but not edit access for entities they are not assigned to?
ugh
