Sounds like a problem for that user rather than a problem for Fibery
Then the view can have an âAssignees contains Meâ filter (or whatever is the right field to determine relevance) and then each person sees different content when they open a given view
When we are planning an initiative, there may be many tasks and we need to track each tasks completion. Views is the best way to work through those tasks, not the left menu.
But then, they can still search other tasks and projects in main search, so it is not private.
Then you limit them to entity-level access, rather than db level
How do you suggest that? By using the Share function on the actual entity?
Probably by automatically sharing the relevant entities.
Weâre already doing that.
I also noted above that users are not being notified when added to a Project or Task via âPeopleâ field if they do not have Space-level access. We have to create an automation to notify them.
There is a bug in which âWatchingâ does not work when they are assigned to an entity within a Space they do not have access to, so we are forcing that as well via automation.
The assignee is the editor, and it is automatically shared with them. However:
- If we do not give db-level access, they cannot create new entities (new tasks)
- Still, this setup requires creating a separate Space to display default views and leverage the left menu as I have described when accessing the Tasks (not including smart sections, which start at the task level); as you stated earlier:
Am I wrong in my assessment here? Forgive me if I am missing something.
You can grant Submitter access to people who need to create entities.
Yes, if users canât get by with navigating from Search, Favourites, My Space views and/or Smart Sections.
Indeed, but we do anticipate that users whose access is limited to a few entities, or to a subset of databases within a space, are users who are not âheavyâ Fibery users, so the left menu has not been optimised for them.
There is always going to be a challenge to make a left sidebar design that works really well for all possible users. Weâll keep trying thoughâŚ

You can grant Submitter access to people who need to create entities.

From there, we give access to âProject Board > Tasksâ and âProject Board > Projectsâ to relevant members as âSubmittersâ. âCreated byâ is the Owner and âAssigneeâ is an âEditorâ. In theory, this works but presents other issues.
Yes, we already do that as I noted in my last response and my initial post.

Indeed, but we do anticipate that users whose access is limited to a few entities, or to a subset of databases within a space, are users who are not âheavyâ Fibery users, so the left menu has not been optimised for them.
There is always going to be a challenge to make a left sidebar design that works really well for all possible users. Weâll keep trying thoughâŚ
I understand. My suggestion was aimed at improving the user experience surrounding entity view limitations and restricting âfullâ Space access in a more natural and intuitive way while reducing necessary workarounds and configuration.
Was not trying to cause trouble! We love Fibery, which is why we recently made the jump to Enterprise. Just sharing my feedback on the topic. Appreciate your help as always @Chr1sG!

Yes, we already do that as I noted in my last response and my initial post.
Sorry, serves me right for doing work late at night!

Was not trying to cause trouble! We love Fibery, which is why we recently made the jump to Enterprise. Just sharing my feedback on the topic. Appreciate your help as always @Chr1sG!
No trouble being caused
I just like to ensure I have explored every angle, so as to get a good understanding of the root problem.
As far as I can tell, the Fibery permissions model does in principle serve your needs, but data access control is only half the story.
Navigation (via left menu) and notification are at least as important, and for some users, the experience is sub-optimal, and itâs not clear what the best solution will be if controlling access to views (separated from controlling access to data) is not possible.

In this case, it would seem that the solution is to separate the databases into a different space leaving the views accessible in the original.
Our issue is that our org currently doesnât allow this. They want to keep things grouped geographically for certain locations. Iâm talking with people to see if we can change this, but I donât know if weâll be able to make this change or not.
I generally really like Fiberyâs sharing model, especially the additive approach to permissions. I just wonder if sharing a Space (at least on the lowest permissions level) doesnât necessitate sharing visibility with entities.

I just wonder if sharing a Space (at least on the lowest permissions level) doesnât necessitate sharing visibility with entities.
A space is a collection of views (data views, whiteboard, documents, etc.) and a collection of databases, and yes, at the moment, you canât grant access to one without the other.
Another small disadvantage we encountered was the inability to see relevant views within the âGo toâ menu.
If we create Space B to show views from restricted Space A, we cannot utilize the âGo toâ menu as a restricted user.
Viewing entity as creator of Space A:
Viewing entity as a âsubmitterâ of Space A with âNo Accessâ applied but âAssignee: Editorâ applied.
As you can see, since Fibery âGo toâ menu is based on views within Space A (which the user does not have access to), they do not have a Go to menu at all.
Ideally, âGo toâ would show views for the database that users actually have access to.
Not the end of the world but there is some inconsistency in the UI: users may or may not see the âGo toâ menu depending on their Space access, regardless of whether they have access to views for the database.

users may or may not see the âGo toâ menu depending on their Space access, regardless of whether they have access to views for the database.
Actually, the âGo toâ menu only shows views in the space where the database lives, and not any views in other spaces.
This applies for everyone and is not really a permissions thing.
As you have seen, if the user has no access to the space where the database lives, this list is obviously empty.
However, if there only exists views in spaces different than where the database lives, even admins wonât see those views in the Go To menu.
Yep! Totally understand, though it still appears to be related to permissions at Space level.
From my understanding, based on their space access, go to menu displays/hides.
A: If they do not have access to the space (purely because it is the only way to restrict them from seeing entities not assigned to them), they will not see the Go to menu.
B: If they have access to the space, they will see all entities and have access to the views.
The inconsistency in UI arises when a non-admin user has access to some spaces but for other spaces, only has access to the database. It means that some entities will have go to menus and some will not. I doubt this will make sense to the non-admin user (unless explained to) but it does create UI inconsistencies. Itâs a small disadvantage to the way Space level permissions currently operate.
Bottom line is: they must have full access to the space in order to see views in Go to menu. Which is not the end of the world, but ideally, if weâre granting access to the database, views associated with said database would be visible on Go to menu.
I may be totally off or being silly here but just my initial thoughts!
Reading through this threadâwhile feeling incredibly frustrated with Fiberyâs foundational structureâI couldnât help but feel like @Illusory was venting on my behalf.
I genuinely donât see the need for Spaces. Theyâre redundant and unnecessary. Folders alone could serve as the foundation of a workspace, containing databases, views, and even nested folders. A folder could function as a âSpaceâ without the added complexity.
This is exactly how Coda structures its environmentâsimple, intuitive, and achieving the same result with far less friction.
The core issue in this threadâpermissionsâis just as frustrating as Spaces. Permissions in Fibery are overcomplicated and messy. Like the complexity I was trying to escape when moving away from Coda.
In a perfect world, Fibery would eliminate Spaces altogether. Instead:
- Folders would handle hierarchy from the top down.
- Permissions would be simplified while not losing flexibility, making access control way better.
This approach would drastically simplify workspace management and remove unnecessary friction. I really hope this gets serious consideration. Right now, Fiberyâs permissions feel like Codaâsâhide this item here, tuck that one there, and yet it still feels imperfect and janky.
In general you are completely right, Folder and Space should be a single concept. Unfortunately, now it is quite hard to do. Space was historically and App in Fibery and we wanted people to create custom Apps, this this abstraction. It is hard to merge it with Folders now.
But even if we do, it would not solve the original problem. Letâs say you have nested Folders and give access to Folders, how it will solve View vs. Data problem? You will still have to give access to views and data separately, and you can do it now if you treat Space as a Folder.
I broke down our current Fibery Permissions Setup in another thread if interested in reading.
Definitely looking forward to trying out share with groups, though it probably wonât solve much for us. Currently, we are creating 2 spaces for each use case.
e.g.
- Projects Admin
- Projects
Projects Admin has no access to all at Space Level and only Database level access for each user as âSubmitterâ.
In Projects, users have Access. Then, we create views to display items from Projects Admin.
Projects Admin/ (no access) âââ Database_1/ (only Submitter) | âââ Fields/ | âââ Person (share access by person) | âââ Relation (share access by group through Person lookup field in Team space) âââ Database_2/ (only Submitter) | âââ Fields/ | âââ Person (share access by person) | âââ Relation (share access by group through Person lookup field in Team space) âââ Database_3/ (only Submitter) âââ Fields/ âââ Person (share access by person) âââ Relation (share access by group through Person lookup field in Team space) Projects/ (full access) âââ View 1/ | âââ Projects Admin/ (only submitter access) | âââ Database_1.table (now can see entities if shared via person, related group's person lookup or submitted) âââ View 2/ | âââ Projects Admin/ (only submitter access) | âââ Database_2.table (now can see entities if shared via person, related group's person lookup or submitted) âââ View 3/ âââ Projects Admin/ (only submitter access) âââ Database_3.table (now can see entities if shared via person, related group's person lookup or submitted)
The biggest issues with this setup:
- Requires two spaces to manage permissions effectively
- Tedious and complex
- Notification issues (had to create rules to notify in some cases since user does not have access to Admin space.
Just sharing our setup in case it is helpful for anyone else.

Letâs say you have nested Folders and give access to Folders, how it will solve View vs. Data problem
I think the disconnect in what âgive accessâ means.
Most commonly used data security architectures include âreadâ and âwriteâ top-level permissions.
Iâm sure Fibery team already knows this but just for others who may not. Popular systems like Postgres through Row Level Security include:
- select (read)
- update
- insert (create)
- delete
- all (everything above)
Through the use of Policies, you can further extend how these permissions are applied. For example, when an authenticated user is browsing Table A, only allow âreadâ where the user_id is linked (related).
So, ideally, we use permissions with extended capabilities:
read:
* all
* own
* none
update:
* all
* own
* none
delete:
* all
* own
* none
create (simpler):
* true
* false
Folder vs Database Permissions
Folder permissions apply to the folders and views within. We can apply the same architecture above. e.g. If we apply read.all, that means they can read.all âviewsâ in a folder. If read.own, this means they can read views they created (if they have create.true enabled) or ones that they have been explicitly linked to (by an admin). If we add create.true, that means they can create new views and folders.
Now that they can read.all views, they can see them, but it does not mean they can see the data within. Then, we can apply create, read, update and/or delete to the database.
Folder (read.all views) â Database A (create.true, read.own, update.none, delete.none) â Entity (override.read.own, override.update.own, etc.)
Alternative approach: Forget permissions on Folders and only focus on Database level permissions with Entity overrides. Folders are just a way to organize views. Views display rows from the database, which a user has or does not have access to. Flow becomes:
Database A (create.true, read.own, update.none, delete.none) â Entity (override.read.own, override.update.own, etc.)
Then see my last point under âUX / Cleanlinessâ below to manage visibility of Folders.
Entity Level Permissions
When it comes to âsharingâ an entity, all weâre doing is linking the user to the ârow of dataâ. If a user had no âaccessâ to a database but I share an entity, I think it is safe to apply âread.ownâ to the database weâre sharing it from (since weâre explicitly saying, I want to share an entity that is in a database that the user may not have read capabilities to). If I want the user to see all rows in a database, I can extend there capabilities to âread.allâ. If I want to revoke access, I can either: Remove their relation to the entity (while leaving read.own enabled), or update their database capabilities to âread.noneâ, in which they will not be able to read anything, even if they are related to the entity. The same logic can be applied to update and delete permissions.
User Experience
Ease-of-use:
If I apply read.all on a user to a Folder, Fibery should know what views and databases are within. I should be able to multi-select all databases present within the Folder and apply wanted permissions, instead of having to manually go to each database and enable the permissions.
Cleanliness:
If a user has read.all applied at top-level Fibery should know if their are any rows to return to the user within the database. If the rows = 0, then you can hide the views associated with the database. If there are no views to show within the top-level Folder (due to no records to return), Folders can be hidden as well.
People may not necessarily agree with this but just putting it out there. Though tedious, we have determined a way to implement permissions that gets the job done.