Yes to this. As of 24 Aug 2019 the permissions are app level only. That means, I can assign users to either see or not see an app. What I need is, for instance, if I make a folder in the wiki, I want to make that read only for most of the team, except for a couple people. I would use this for documents that should not be edited by just anyone, that the company is legally required to maintain and make available, like “rules of employment”.
4 Likes
@mdubakov, Interested in how close the implementation of this feature is planned in the roadmap? It is very important feature for our team. It is second priority after UI feedback speed for our needs.
By the way, where can I see the current roadmap?
Maybe you should consider writing a roadmap on a published Fibery board?
1 Like
We don’t have a roadmap right now, since public release will definitely affect it and change all the plans. Most likely it will appear near Jan. It means Entity-level permissions schedule is unclear at this moment.
2 Likes
+1 here. Would need entity level permissions to map sensitive processes like 1:1s, performance and salary reviews.
2 Likes
Updates on this?? It’s a big reason my team is skeptical.
3 Likes
Hey Guys, I don’t mean to pile on but since we have some activity here from @julian, I would like to add my vote. I would be happy with Type-level permissions if that was easier. Ultimately, Entity-level is superior.
Just for some context, I really like apps like Wrike, Asana, ClickUp, and some others that will add you as a share/viewer when you comment @ a particular user.
I would also love to see this feature come along at a similar time:
Thanks guys and keep up the great work!
2 Likes
+1 on this.
My use case is as a product lead for many products (aka sites) of our web agency. I’d like to create “spaces” for each product utilizing the same setup of entities. Whenever I try to create entity relations it should only show entities within the “space”. I tried to implement a setup like this and almost made but it failed on the fact that I can’t filter available entities during lookup when creating a relationship.
4 Likes
I just thought I would add in my use case for entity permissions and that is a role-based implementation, i.e. a user has one or more roles, and it is the roles that determine the access levels on an entity (or at least app-level) basis. I don’t need to figure out which apps a user should have access to, I just assign them to the necessary roles.
It’s obviously very analogous to traditional file permissions based on user groups.
[I think I’ve mentioned it to the fibery team directly, but I’m adding it here to open up the discussion]
@mikael Your need seems to maybe relate to filtering and views combined. Were you aware that you can use filters in formula fields to return linked entities based on the filter criteria? I think combining suitable lookups/filters with the various views available in fibery, you might be able to achieve what you have in mind (assuming I’ve correctly understood where you’re coming from).
It’s not clear to me whether permissions is really what you need…
3 Likes
We are working on permissions and will not stop till entity-level permissions are implemented. However, it might take 4-6 months to get there.
3 Likes
Great to know the time horizon. Rome wasn’t built in a day! 
3 Likes
Michael, it was good to hear from you re: permissions, would be curious if you could shed any light on whether you guys will also be looking at Type-level:
Many of the tools I’ve used have nice ways to handle these levels of permissions. One of my favorite, which is central in Wrike, and Asana, and ClickUp - who I might loosely consider a similar “triumvirate” of “Task Managers” like Airtable/Coda/Notion is within the “nocode” sub-space, all do this:
-
If you @mention a user within a comment stream, they get added just to that particular task
-
You can “share” lists/folders/projects to a particular group.
So in the case of Fibery, I think you have a great chance with your existing hierarchy to do a similar approach that would be very familiar to those coming in from these tools - and perhaps others who handle things similarly like Hive, Monday, Teamwork Projects, etc.
So in Fibery this would work out as:
-
You can access particular users to a Type, much as you do now with a whole App
-
via mentioning a user, they get access to an individual Entity only.
The addition of the Type-level permission makes it easier to break down groups of Entities within an App. I have this need in Task Management I am running in Fibery, where I have groups of Tasks in Types that I’d like to have only certain users see, and not the whole App’s worth of Types.
Hope that’s useful and curious to see how you guys will solve this!
1 Like
Any updates on this topic. We are still longing for a solution on the use case of inviting a user to a specific entity and the user will then have access and be able to collaborate on all related children entites in an parent-child relationship.
Entity-level permissions the #1 customer request for us so we are committed to delivering a solution. The problem is quite challenging, both in terms of UX and technical solution — we are still in the preliminary design phase.
Once we have something “feedbackable”, I’ll be happy to share it with the community. In the best-case scenario, the beta will start the upcoming winter.
4 Likes
Hey! Just wanna know if there is any advancement on this? I have a client who is waiting for that. 
Unfortunately implementation is not started yet, but we hope to start it in April.
1 Like
What is the ETA on this? This is the only functionality stopping us from moving to Fibery from coda / notion / clickup / airtable.
Still not started. Still want to start it in 1-2 weeks.
1 Like
Permission rules as they are realized at GRIST are the most expected realization for me
https://support.getgrist.com/access-rules/
Have you considered view level permissions as well? For instance if i share only a specific view with someone who has no access to the parent app, could only have view or edit rights to the entities visible on that shared view and this method could also limit the available fields (to view or edit) that are visible on the shared view.
Also for entity level permissions it would be great if someone could automatically get permissions for an entity that is related to his/her user entity. This way everybody could edit their but only their time log entries for instance. So there is a Type that everybody can create new instances of, but can only see and edit their own entities
This can be the next step, entity-level permissions should work to do it. Technically View will be a container so it might be possible to define what entities it contains. Note that this is quite challenging anyway, since you can change Filters and all entities visible on a View can change dramatically. However, it’s seems possible to implement in future.
Field level permissions will never be implemented though.
This will work out of the box.
1 Like