The ability to set permissions on the:
- Comments field (which is essentially just a relation)
- Single select
- Multi select
If I am not mistaken, the technology is already there, but isn’t exposed in UI. This results in very clunky work arounds.
2 Likes
Why you need that?
Use case:
Inviting freelancers to write a piece. Then we want to comment internally about said piece before giving the feedback to the client.
Current work around: Automatically create a “thread” entity (that the freelancers has no permission to) linked to the freelancers work. Then chat in there. But that’s quite hidden and is bad UX.
Ideally I just create a comment field in the work itself and don’t give the freelancer access to it.
Use case 2. Client portal has a status field. I don’t want the clients who are shared in the portal to see this status. Workaround: new database and linked with one to many. Downside: worse UX (bc of the arrow to open), and results in a lot of databases.
If you expose the single and multi select. It essentially gives field permissions (for those types) without much extra dev time.
Lmk if this makes sense. Thanks!
@mdubakov Wondering if this makes sense and could be coming. If I start like this now and it comes later, I can’t really just migrate the comments because they are not like a normal database. So I’d lose data. But if theres a chance for it to be done in the next couple of weeks, I’ll wait for it before starting to use the system as it will improve the usability significantly. Not trying to push, just wanting to make an informed decision. Thanks!
This is very unlikely as of now: both because the technology is not there (comments and selects have their own quirks to cover most popular scenarios) and because it will make an already complex system too complicated.
What you are describing is, essentially, per-Field permissions, and we are not even thinking about them in the next few years.
If there is a considerable demand, we might reconsider in the far future, but so far it’s not that widespread.
Although setting permissions for the single- and multi-select fields is not possible, you can use native databases to achieve single- and multi-select behaviour, and then it becomes possible.
But as Anton says, permissions on Comments won’t arrive any time soon, and there’s no good workaround.
Okay thanks Anton! I’ll leave it as is for now then.
I’ll just note that even though you didn’t necessarily focus on per-field permissions, with the access templates this is what we got! Which is great! That’s why I assumed the tech is there, but maybe theres more to that the eye can see.
Yup! That’s what I’ve been doing. But the thing that bothers is the little arrow to open. I know its small, but for the single and multi select, I dont want the user to open the entity very ofter (just with option+click, like with normal single and multi-select.)
Maybe going the opposite direction would be easier to impliment? Adding database setting to hide the “open arrow” then they will truly be indistinguishable (except for the color field but thats a different story).
I’ll stick with this for now then. Thanks for providing the info!!! Really appreciate it :))
I wanted to jump in here and say I also want this - the ability for the open area to show up and for my clients to view all of the notes on the entity they selected is a deal breaker for one of our specific use cases. We may continue to use fibery for our databases, but sharing things with people outside the firm feels like a really big “gotcha” - like there are 30 different ways an outsider might discover confidential information on any view you share with them.
I really just want a way to share a view, and know that all the shared party can see is what is obviously visible in that view, and nothing else.
Part of the problem with this way of thinking is that there is no single universal definition of what is ‘obviously visible’ in a given view.
E.g. a Task view might include a filter like ‘Assignees contains me’ in which case, each person visiting that view will see different things. So sharing the view does not imply sharing a specific set of Tasks - it varies from person to person.
Similarly, the shown entities might change over time.
So at the moment there is technically no easy way to implement sharing of entities based on what view they may or may not appear in (now and/or in the future).
But we’ll keep thinking about options
In my use cases, being able to allow the viewer to see literally only what is represented in the table, and nothing more, is my main goal. I don’t think it’s too hard to anticipate what is seen if I can also include “me” filters based on what person I’ve attached to each database entity.
The area where I get real nervous is once the user opens up the entity. I consistently get shocked by what is visible. I was very surprised, for example, that a user could open an entity and see all of the hidden field names, even if they couldn’t see the contents. Or that a user can see all the other users in the workspace by doing a search for users.
I get that in some situations this is fine. But I really need a user who can see very little. If one of my law firm clients can see all of the other clients I have in the firm by searching the users, this would be a disaster. I was very excited about the prospect of using Fibery for a client portal, since all of our firm information is in it. But this issue alone, and the ability to see hidden field titles, both seem like too big of risks.
It is almost certain that the titles of fields will never be access controlled. The schema (what fields a db has and what dbs are related) is considered public.
Of course, there are ways to make it inconvenient for a user to see all fields, but there is nothing to stop a user creating views (in private space for example).
We are currently working on a feature to allow controlling which users can see other users, but sharing data views is not on the short term radar.