Feature Request: Share Space but restrict entity views

[Chr1sG]

@Illusory

I’m saying, what if there are 100 tasks relevant to said user.

Sounds like a problem for that user rather than a problem for Fibery

[Chr1sG]

@Illusory

they have access to all views, in a Space, but only see entities related to them

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

[Illusory]

@Chr1sG

Sounds like a problem for that user rather than a problem for Fibery

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.

[Illusory]

@Chr1sG

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

But then, they can still search other tasks and projects in main search, so it is not private.

[Chr1sG]

@Illusory

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

[Illusory]

@Chr1sG

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?

[Chr1sG]

@Illusory

How do you suggest that? By using the Share function on the actual entity?

Probably by automatically sharing the relevant entities.

[Illusory]

@Chr1sG

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.

@Illusory

Solely navigating related tasks via “Shared with Me” or “Inbox” is not viable. Instead, we create a “Home” space and provide access to all members. Then, we add “Project Board” and “Task Board”. 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.

The assignee is the editor, and it is automatically shared with them. However:

1. If we do not give db-level access, they cannot create new entities (new tasks)
2. 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:

@Chr1sG

You’re right that the left menu is not as useful for users who only have db/entity access as it should be.

Am I wrong in my assessment here? Forgive me if I am missing something.

[Chr1sG]

@Illusory

If we do not give db-level access, they cannot create new entities (new tasks)

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

@Illusory

this setup requires creating a separate Space to display default views

Yes, if users can’t get by with navigating from Search, Favourites, My Space views and/or Smart Sections.

@Illusory

@Chr1sG

You’re right that the left menu is not as useful for users who only have db/entity access as it should be.

Am I wrong in my assessment here? Forgive me if I am missing something.

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…

[Illusory]

@Chr1sG

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

@Illusory

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.

@Chr1sG

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!

[Chr1sG]

@Illusory

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!

@Illusory

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.

[Michael_Ichter]

@Chr1sG

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.

[Chr1sG]

@Michael_Ichter

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.

[Illusory]

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.

[Chr1sG]

@Illusory

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.

[Illusory]

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!

[Edan]

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:

1. Folders would handle hierarchy from the top down.
2. 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.

[mdubakov]

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.

[Illusory]

I broke down our current Fibery Permissions Setup in another thread if interested in reading.

@Illusory

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.

[Illusory]

@mdubakov

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.