Permissions - entities vs views

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.

* I realise that this functionality has some connection with discussions regarding ‘personal’ vs ‘global’ views:

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)

1 Like

Great ideas!

Entity-level permissions are coming…some day! :slight_smile:
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?

1 Like

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.

1 Like

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.

Does that not address the need?

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.

Indeed, nicely put :slight_smile:

So you’d need to create a Group for every individual :roll_eyes: ugh

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).


Sounds totally reasonable :slight_smile:
I’ll be looking for more scenarios like this and link them to the same Insight/Problem.

Yep, that’ll be the case before we introduce per-Entity permissions.

Is it possible to send messages to the user without throwing an error?

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.

Previously, a script could return a custom message: apply-project-template/apply-template.js · master · fibery-community / Action Buttons · GitLab. I don’t think it’s working in new Buttons though.

@Sergey_Truhtanov knows better :slight_smile:

1 Like

I add myself to this thread because I have this use case:

  • software development app with different customers, developer from customer A must not see stories of customer B
    So it means:
  • contributor: view AND edit only entities assigned to ME

Meanwhile which workaround can I use? Can I create multiple copies of software development?

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 :frowning:
But soon it will be possible :slightly_smiling_face:

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.

Clone/Duplicate App Type - #3 by Matt_Blais

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?