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 :))