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
Yes. Unfortunately, that is the case.
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?
Absolutely not these are different customers and they must not see products of competitors.
It is a so common case that I wonder why it is not supported from the beginning: as a software house I have several customers each one with its Scrum. I manage all the scrum but the customers stakeholder can create stories and see development progress. They cannot see stories of a different customer.
Then you would have to use separate apps for each customer.
I assume this limitation will be addressed by the planned per-entity permission model?
That’s the plan
Is there even a vague estimate of when Entity-Level Permissions might be implemented?
It is a necessary feature for my use case (and many others).
If our goal is to limit “Customer” user access (today) to specific “Product” entities, is this a viable workaround:
- Create a separate “Customer Xyz” App for each customer, which we will try to use to allow specific user (Customer) access to only specific Products.
- Customers have no permission to access to the Products App, which contains the real Products Type.
- Create a separate “Customer Xyz Product” Type in the “Customer Xyz” App. Customer Xyz can access this App, so they can see these entities - but what are they?? We want to somehow link them to our “real” Product entities…
- For each “real” Product entity that we want to grant access to Customer Xyz, we create a “mirror” or “shadow” entity of “Customer Xyz Product” Type, in “Customer Xyz” App, and it must somehow reference the actual Product entity.
- Hopefully Customer Xyz still cannot see the “real” Product entity; but can they see its fields via a Lookup field in “Customer Xyz Product” Type? How about Formula fields - can they see a Formula field in “Customer Xyz Product” Type that references data of the forbidden Product Type?
It certainly is a viable workaround, and it might even be possible to make it less labour intensive with some automations (like, create a ‘shadow product’ every time a product is assigned to a particular customer).
However, assuming that your intention was merely to create a read-only version, then depending on how many entities you need to share, it might be just as easy to provide sharing links for the customer.
Still too early for any estimates but we are working on the unified model of permissions (including Entity-level) right now. We’ll share a very long and boring doc in the upcoming weeks.
I would like to inquire about the status of this, as this is basically breaking our use case for Fibery.
- I can’t share my meeting notes of a meeting without sharing the notes of all meetings
- I can’t assign someone to see and review an entity without him being able to see all entities of said type.
- … (in an efficient and convenient way, I know I could create many spaces, but that kind of defeats the purpose)
Being able to share a view of a space without sharing the space itself would seemingly solve this problem:
If I could:
- create a view, filter it for employee XY, choose which fields are visible
- then FIX that view such that it cannot be changed by whoever it is shared with
- then assign groups or people to that particular view with access and edit rights ON A FIELD BASIS (e.g. Person A can edit field nr. 4, or even better, Person A can change field nr. 4 from A to B, but not from A to C)
- at last, hide that view from my own dashboard i.e. like you can hide and show fields within entitites
That would bring Fibery to a whole different dimension my opinion, where views could act as apps, especially considering Fibery is working on multiple views being able to be embedded into a single view (if I understand correctly).
I also like your idea of permission dimension for Button pressing.
Of course I don’t know about the technical limitations of all this… it would be good to know whether this is possible and planned in the near future. As powerful as Fibery is, you simply cannot use it if there are confidentiality problems that come with it.
In a nutshell, the problem goes beyond entity level permissions, because currently it comes with view permission for everything, which is not very practical.
you can set permissions for some users to be able view (but not configure) a particular space (and thus its views), and for some users to configure a space (and its views), but configuration at the field level is not possible. I do not anticipate field level access control will be coming any time soon.
if you’re an Admin, nothing can be hidden from you(!)
Not sure what you mean by dashboard. We are working on ‘My Space’ which would allow users to create views that only they can see (but this would probably conflict with the access permissions model for #3).
Otherwise, for normal users, a space (and therefore its views) can be totally hidden if that is necessary.
Thanks for your reply.
Point 3 is not a necessity, but 1 and 2 are only possible on the condition that whoever you share the view with can see ALL the information within the same space, right?
Being able to share and give access to specific things without giving view-rights to the whole space is a necessity in my opinion…
For example, in Space A, Database of Projects, I want to assign Project A to Person A, Project B to Person B, without Person A knowing Project B exists and vice versa.
Another example: I can do contract management including filing on Fibery. However, if I want to assign specific contracts to specific people for them to be able to see the status etc., currently, I would need to give them view rights to all contracts.
I really would need to know whether this will be addressed in the near future.
To 4.: I mean the left sidepanel, where all the spaces and views are listed. If I create a fixed “view” as part of a process workflow for other people that I personally don’t need in that exact view, I might want it hidden from my view, maybe within a “hidden views” folder or just have a “show hidden views” slider or something. I hope it’s understandable what I mean.
I’m searching for a functionality like this too. I think it’s really important for finance or 1:1 meetings.
Are there already some implementation plans?
Do you’ve got a workaround for this?
This is in plans and we call it Entity-level permissions. We are going to start implementation soon. You can check some details here.
Hi, what you mean by soon ?
We are close to starting, tech research is almost over! This is the hardest thing we ever planned, so no promises anymore
Hi Mikhail , permissions to view entities is crucial for teams bigger than small companies.
I am trying now to implement HR system prototype on fibery. With view permissions on entity level could make fibery a permanent solution with many users. Without it i’ll have to look for dedicated solution. Can you please provide rough estimation when it may be available ?
I did that several times in the past and always failed, so I am not gonna repeat this mistake again. My best guess is 2023 so far, when we will have less uncertainty I will post more details here.