I just found out that user that is invited to Workspace as Observer can mention anybody inside workspace so everybody can actually see everybody. This is major permission issue.
Debugging: User is added as observer to single Entity. Then he can mention anybody even if the person is also observer and not added to the same entity. Basically user is able to mention anyone inside Workspace so he can see members, clients, everybody.
It is not a bug. It is the current implementation.
The use case for Observers is that they are typically stakeholders that need to see whatâs happening in Fibery but donât need to create new records or make any edits.
Itâs possible that your use case can currently be solved by using Guests.
We do have plans to allow granular access control for Users, but it likely wonât happen til later in the year.
Guests are not invited to the workspace as a whole.
You share specific entities (and optionally their related entities) with Guests.
Check out the user guide.
Now I understand it. Guests and Observers are quite similiar. Both roles can be used for clients outside company. But the difference is:
Guests - only invited via entity, donât have left menu per se, only use Shared with me.
Observers - can be invited via link or users database, can use left menu perfectly, can see all other users inside whole workspace, can see all the threads that were created even if they are not assigned to specific entity.
Not sure why there are Guests and Observers and not only polished Observers but at least now I understand problems.
Actually, it is uncommon for an Observer to be used for clients outside the company. You typically want to limit clients to specific records, which is exactly what Guests excel at. And you can always control what Guests can do (limiting them to view/comment only if needed).
Note: the ability to see threads that belong to entities that the user doesnât have access to is true for Members and Observers, and is just a problem related to threads that needs fixing before it comes out of experimental
They basically exist for two different use cases:
Observers - when you want a stakeholder to be able to follow whatâs happening all over the Fibery workspace, but you donât want to pay for a licence, because they arenât creating/updating records.
Guests - when you want to allow a person to follow and contribute to a specific part of whatâs happening in Fibery (possibly including making edits) but you donât want/need them to see the bigger picture (and you donât want to pay for someone with such limited access).
If Observers could edit/update, then they would be no different from Members.
If Guests could access all parts of the workspace, they would be no different from Members
If you add observer and assign only specific record and extend it then observer have access similiar to guest but also can see all members and threads.
If you add guest then he only sees specific records inside shared with me and empty workspace tab. This is confusing for clients at first. Also guest cannot see threads at all.
Observer is much better for client because they can see content inside smart folders and threads. If I add client as observer it feels much better for them because they can actually use navigation. The only problem with observer is abillity to see more than is assigned to them.
If observer permission related to threads and users is fixed then guests would be redundant or maybe having workspace items for guest is better. Not sure but in my point of view these two overlap and the only decision now is:
Do I want client to feel comfortable inside fibery and accept that he can see all the other clients and threads or 2. do I want client to see only assigned items but with confusing navigation and without threads?
I know Shared with me is typical for most systems like Clickup but still have no idea why guest cannot see the structure for example - projects, task, documentation and be more comfortable.
Youâre right to point out that the navigation experience for Guests is sub-optimal (thus making Observers better) and this is something we are thinking about how to improve.
Ironically, if we allowed Guests to see more things in the default space (top level of the sidebar) then they would experience the same issue with Threads as Observers (seeing authors/timestamps of comments, but no content). But this is a tangential issue.
Itâs actually a side-effect of the way permissions are managed under the hood - Guests are specifically limited to only seeing entities. Any other âstructureâ (folders, views, smart folders, documents etc.) belongs to a Space, and cannot therefore be accessed by a Guest, per definition.
But we recognise that this makes the sidebar experience a little weird for Guests.
You are probably right that when we eventually roll out the ability to control which Users are visible to other Users, then the choice between making someone an Observer vs a Guest without edit permissions becomes clearly in favour of the former.
However, we do need to figure out what this means for the case of a user who needs (limited) edit access: if a Guest can see the Fibery âstructureâ, whatâs the difference between a Guest and a Member?
We know that people like to have (zero cost) Guests for people who are not âfully fledgedâ users but who do need to make changes. If Guests becomes able to see (and do) more and more e.g. interact with all the non-entity things in the sidebar, at what point does it become appropriate for them to be chargeable as normal Members?
Appreciate the discussion - it will feed into our thinking going forward.
Pointing out that moving in the direction where guests see the structure gives us the abillity to use fibery with more users for free is correct but still we can use observers to overcome this obstacle if accepting the fact they see users.
With introducing observers you actually gave the abillity to have more users for free within company. Now we can invite whole company for free and let them see anything they want as regular members but without the abillity to create task which can be done in a different ways.
I originaly thought that observer is client account which can be used to track tasks without the abillity to create new (this can be done using API anyway) and replace guests.
With going deeper within this thread I actually donât understand need for observer and guest because observer is member with weird permission and guest is client with really bad navigation.
For me would be better to have proper roles with limitation for certain roles. I usually work with client for specific period of time and then they can use Fibery once in a while (few times a year) and these users could be for free but inviting client inside Fibery as guest is not user friendly and needs proper explanation (without mobile app it is hard to persuade client to use fibery).
Not sure how to solve the problem where Fibery needs money for users and customer needs free client who only uses Fibery few times a year.
However I truly appriciate this discussion. I feel like moving to Fibery was the best decision made even more
One more quick observation - if used sharing per entity with extended access the only difference between guest and observer is the ability to see users and have proper navigation but basically they are the same.
Not quite, i tested this when i read some stuff above, its only for commenting and viewing. You canât giver observers editing / sharing access. Other than that, yeah its the same.
(Iâm actually now considering making some guests that only need view and edit access into observers⌠hmmmm⌠I see your point. And then observers also get the âAutomatically give access via fieldâ working then? Which is another thing that doesnât work for guests.)
You cannot change guest to observer and vice versa. You have to delete them. Or maybe change to Member and then to observer. Never tried. Also not sure about sharing via field. I never tested it properly since Observer can see all the members inside workspace and guest is too limited in the sidebar. Not sure where to go now.
You can do the following Guest â Member â Observer, but itâs true that you canât do Guest â Observer directly.
You canât change an Member/Observer into a Guest.
Yeah, I think your use case is stuck til we implement control of what users can see each other.