Hey! Any update on this? This could allow for more public-facing apps, as well as inviting clients/investors/external people to your workspace without exposing all your team’s emails.
ETA is the end of the year, but we are working on it now, database-level access should be release this week (or next, who knows…) and then we will go for Configure Access to Users, here is the excerpt from our monthly internal update:
Hi!
Use cases about are solved with new User type, who doesn’t have access to user emails Here you may check how it works
Please, let me know, whether it solves your use case
This does not solve our use case. We might be able to misappropriate this structure by treating every employee as a separate client or freelancer, but that would require a nearly complete manual rebuilding of our existing workspace, would require immense manual maintenance load on workspace admins, and would substantially limit much of Fibery’s actual usefulness due to the proposed structure.
I believe 100% of what we need would be served by making the “People” system space hidden from space members and only visible to admins.
(This would also be helped by adding permissions to view/hide columns as opposed to entities, but I have not yet checked to see if that feature is being requested or tracked elsewhere. )
It sounded like your the original request was for external users (clients/freelancers) to not see each other’s emails.
which is how Fibery works if the external users only have guest accounts.
But maybe you need that no user (guest or otherwise) is able to see any other user in the workspace, is that right?
Do you want to restrict your colleagues from being able to see each other’s user details?
It would be ideal if we could choose which information about users was hidden, but if only username and profile picture were visible to non-admins, that would serve our purpose.
Also note that I’m not the original requester, so even though my use case is not identical to theirs, the feature being requested is the same.
Although, also note that OP mentioned this use case, as well.
Unfortunately, we went with another tool because of this issue, so I don’t know how things are today, but I think “guest” accounts were too restrictive. We are a design agency, and each company we work with would need to have their own space where they can create entities (tasks for us) and update or delete them. I think that was not possible with ‘guest’ accounts. And members were exposed to everybody, which was also not an option. Is this resolved by now?
First of all, you’ll decide who can see all users and who all users can see. These are the options:
Everyone including Guests
Everyone but Guests (default)
Everyone with your @company.com email domain
Only Admins
Additionally, you’ll be able to choose if:
Users with the same email domain can see each other;
Users within the same User Group can see each other.
This would be proper permissions to User entities, not just hiding Users from the fake People “Space”, but also restricting access through search, assignments, history, or even API.
I’d imagine your setup looking like this:
Everyone with your @company.com email domain can see all users and all users can see those with @company.com email domain.
Users with the same email domain can see each other.
Would this work for you?
P.S. The fake People “Space” will be gone even sooner than we introduce the proper permissions. There is no good reason for it to be so visible for everyone, regardless of the access level.
We are not set up like a company, but rather something more like a non-profit (We are a community project). We are on-boarding and off-boarding new people relatively frequently. We do not provide people with email addresses, instead having everyone use their own email for sign in.
We want everyone to be able see and interact with everyone within Fibery, but without the privacy concerns of exposing one’s email address to what is otherwise a potentially large group of strangers.
I think that with Users becoming more like a real database, there might by some workaround like automatically creating a “Profile” every time a “User (system)” entity is created. It’s linked, maybe has some lookups for the name and profile pic, but not for the email. Then in the access templates, just not allowing access to the related people fields. BUT This would mean Fibery would need to expose the system relations (Created by field). To restrict the view to that. But auto link the “Profile” based on email of the “created by” and thats the one people have access to. Could work quite nicely! (Only down side is that comments, and in turn, “Thread view” would not be functional until comments are converted to real entities or Allow any entity to be used as a comment for thread view.)
Most of our other work tools don’t have this problem.
In fact, Fibery used to not have this problem, but then oauth was moved to a higher paying tier late last year, and we had no choice but to convert everyone to email based sign in. To be honest, putting that back would solve our problem, too, but I suspect that change was financially motivated and is unlikely to be reversed.
