Hi, Matt!
We donât Fibery-to-Fibery sync and are not sure when it will appear
We also have some big customers (like ~600 teammates) - they started working in different workspaces but ended up in a structured one
Permissions + Hidden spaces have to work, and your ability to structure the data and configure Fibery - Iâm pretty sure will make a magic
How would this work: if there are 6 Departments in my company, and each one needs âTasksâ, but they must not be allowed access to Tasks from other departments.
This would seem to require a separate Tasks DBs in a separate Space, for each Department.
So I would have to duplicate (x6) all of the work to create and maintain these Tasks DBs, as well as any other DBs that need to be restricted to certain Departments.
Add in lots of scripts (also duplicated x6) and that sounds like a maintenance nightmare.
As long as Fibery Search can show any/all entities, the limitations imposed by views have no value for restricting access by User, so we are left with only Spaces.
I think that Fibery needs to step up its game in the way collaborative technologies are rapidly becoming decentralized now. Fibery is a monolithic app that yes has integrations, but that is the minimum to expect nowadays. The next steps is to become modular and make the community contribute modules for Fibery, as well as to support Fibery to Fibery database connections.
The current topic is about multiple departments using different Fibery Workspaces, but I think we should look ahead and see the tech trends as well as the opportunity of Fibery to align with that, instead of trying to accomodate invididual organizations only.
For the readers here who are interested in that decentralized and networked development, see this related topic where we can continue the talk about that evolution:
I would likely have arrived at this question myself in time. Did you ever get an answer? I guess I wonder if youâre the admin (or creator) and you create a view using the appropriate filters to show only the allowed tasks for a given space and make it read-only, are the viewers of that space still able to change the filter to see all global tasks?
The current permissions model only allows granularity at the space level, so if you can see/edit one entity in a database in a space, you can see/edit every entity in all databases in that space (with a caveat about contributor level permissions which isnât important for this discussion).
And this means you can find anything in that space via api and search.
For the upcoming permissions model, granularity will be down to the entity level (eventually including levels in between). So you can have view/edit permissions for âXâ and you will only be able to view/edit âXâ where X can be a space, a database, or an entity.
And the search/API behaviour will reflect those permissions.
If you mean, the use case in the first post of this topic âsharing a space/db among multiple workspacesâ then, no, it is not part of the plans for permissions.
Workspaces are independent from each other, and we have no active plans to change that.