Perhaps I just don’t understand Fibery’s ethos as it pertains to sharing and permissions. I want to build out a specific view for specific employees. In this view I want certain fields to be exposed to those users, but some fields I want hidden. Here’s my use case:
I have a task list, and I sometimes delegate to different users. I don’t want them to see the “Delegated to” column.
Maybe there’s a work around for this, but I’m struggling to wrap my head around how sharing and permissions work in general. I can give workspace, database, or entity permissions only. Start small, work upwards. Only, the small isn’t small enough. There’s no control over fields.
Also, there doesn’t seem to be a way to share or build a view for someone else. I’m an admin, and I want to build a task list for a coworker. As far as my testing shows, I can’t do this at all. All I can do is share that task with them, then they have to build their own view? Is this correct? Please let me know if I’m wrong here.
Fibery is amazing in the fact that it let’s me build what I want. It seems to fall on it’s face though in terms of sharing and permissions, and sharing views. I’m willing to build out exactly what specific users should see and be able to do, but I can’t even do that.
Correct*
There are no field-level permissions. If a user has access to an entity, then they have access to all its basic field values. However, for relation fields, the user may or may not see the linked entity(ies) depending on their access level for those items.
*technically it is ‘workspace, database, or entity permissions’
What do you mean by ‘build a view for someone else’?
A view in the sidebar lives within a space (including the ‘default’ space) so if a user has access to that space, they will see the view in the sidebar.
Of course, what they see when they open the view depends on what access they have to the data that is being presented in the view.
For example, if you have a Task database (in the Project Management space) and a board view of Tasks (in the Marketing space) a user with access only to the Marketing space will see the view, but won’t see any Tasks in the view since they don’t have access to the entities in the Task database.
Note: you can always define what fields are visible in any given workspace sidebar view, but this is not strict access control - a user can always create their own views in the Private tab of the sidebar, and in those views they can show/hide whatever fields they choose.
In your specific example, even if you created a nice list view of Tasks in the sidebar, that didn’t show the ‘Delegated to’ field, a user who has access to Tasks could create their own view of Tasks with that field enabled.
Out of interest, is ‘Delegated to’ a People field (i.e. a relation to the User database)? Or is it a relation to another database in the workspace?
Ok, so the way I see how Fibery is structured is accurate. There is no way to shield specific fields from a user.
The use case I gave you isn’t a good use case. Here’s a different use case. If in my task table I have a monetary value for the labor of this task, I probably wouldn’t want that exposed to the employee doing the task. This task takes 4 hours, labor rate is $30 bucks an hour, the task value is $120. Different employees make different amounts of money. I certainly wouldn’t want the employees to know the values of these tasks.
Ideally, I would have a master task table that has all fields and values. This would be exposed to management. I could then create a view for Employee A. She can see 7 of the 15 fields.
With the flexibility of Fibery, it strikes me as weird that I can’t accomplish this.
Yep, I see why you think it’s weird. At the moment, the technical complexity of implementing field-level permissions is too great, so it’s not on the radar.
However, for your example, I would imagine that the best way to implement this is to split a task across two dbs - one for sensitive fields, and one for general info. Each ‘task’ is then made up of a pair of linked entities (one from each db) and different users get different access (e.g. managers always see both, employees only see the general info).
You can use lookups if necessary, so that info from the general task entity is visible in the sensitive task entity, allowing the manager to see everything without having to navigate back and forth.
And depending on your flow, you can use automations to make things simple, e.g. create a ‘twin’ sensitive entity whenever a general entity is created, or vice versa.
It’s not ideal, and some features that we plan to deliver will no doubt make this sort of solution slightly more user-friendly, e.g. Editable Lookup Fields
We might even implement a semi-native solution for this kind of ‘twin’ entity solution so that the UI behaves a bit like field-level permissions even though it is in fact just paired dbs under the hood.
I think this would be great! My main issue with the current “twin db” workaround is how cluttering and potentially unwieldy the workflow becomes. If this UX matter can be solved, that might sufficiently resolve the field-level permissions function, imo.