I don’t think you fully realize how much this change could benefit Fibery’s growth. This is exactly what made Notion take off—its fundamental simplicity made it easy for a broad audience to adopt, even if it’s fairly limited under the surface.
Right now, Fibery requires a technically savvy user to navigate effectively.
I strongly recommend taking a deep, deeper, and even deeper look into this to find a solution. While it won’t directly solve permission issues and the complexity they bring, it will dramatically simplify a tool that, in many ways, is far more powerful than its alternatives but remains unnecessarily complicated due to its history.
Indeed, the current data-Space + view-Space workaround is exactly that—a workaround. We are working on allowing Admins to share a Space without necessarily sharing all the data inside.
You’ll be able to share a Space with all its Views but none of its data on the Space level, and then grant access to individual Databases and Entities. Here’s a prototype:
This looks great! I’m just a bit confused as to why not use the same interface as the access template, where you can define the exact permission per database, rather than a role. If want them to have the ability to submit and view, but not edit or comment, is that possible like this? The UI is already there! Or even better, why not use the same “Access Template” idea and treat the space as an entity. It feels a little off that different things have permissions working in different ways. I honestly looked at this and was quite confused… And I’ve been building in Fibery for some time.
One request as this gets developed is the ability to copy paste the permissions from different roles, people, and “Everyone at workspace”. As an org grows, they might start by giving everyone access, but soon enough need to separate teams, so setting all of it up manually would be a headache (especially with many databases). Maybe the custom access template solves this too actually?
100% agree with this. We’re thinking a similar thing
I think it makes sense to keep the access template style UI and functionality but apply it to the Space for each database. Then, you can override on a per entity basis. Additionally, in “Space Access” we should be able to see all who can access, including overrides. This way, you can revoke when needed without having to remember each individually shared entity.
Important note that makes things so much more confusing right now:
When I set a space to “Everyone is editor” the database access still shows me “No access”. When in reality, everyone has editor access. I know permissions can not be removed, but right not the UI is suggesting they can be. Even in the screenshot you shared:
Having the UI reflect how things work makes it easier to understand how things work.
Making complicated things feel simple is very hard to do, and Fibery permissions are quite complicated… But its really needed for growth or else people will abandon the tool. I’ll make a separate post with a video other places it just isn’t intuitive right now.
For what it’s worth, the access levels for Space/Database are pretty much effectively nested sets, i.e.
Commenter = Viewer + comment capability
Editor = Commenter + editing capabiltity
Creator/Owner = Editor + configuration capability
so there should be no real need to display ‘calculated capabilities’.
This is different to Entity access, where someone can have pretty much any combination of capabilities, however weird (e.g. can Update, cannot Comment, can Delete, cannot Share, etc.)
But I agree with your observation above, that since a User can have ‘direct’ access but also ‘indirect’ access (through group membership) the UI will need to be clear in indicating the resultant access that a user has, based on all possibilities.
Yes exactly, this UI. But then also with a submitter option.
2 things to respond to that:
Why can the Space/Database only be the nested permissions and not with different capabilities? Like with entities? What if I want someone to be a viewer and submitter, but not editor? Right now i need the viewer access to be inherited, and then add the submitter… its cumbersome… really cumbersome.
If its a technical limitation, I still think the UI would be much cleaner if it was with the icons. Space at the top of the list. Then when you drop down you see the databases (with the icons). The icons that are set by the space (inherited) are blue (but not clickable), and the ones to the right of that can be selected to give even more access to the database than the space. It makes it so much clear as to what access is coming from where.
But I’ll note this isn’t only for group memberships im now realizing. Michael is given Commentor access to the space as well. To that “Initiative” database saying “No access” is inaccurate, even if everyone in the workspace had no access. Right now, (unless its changing) you can’t remove inherited DB access from the space access.
And to link back to the topic of this thread:
Include both the databases and a list of views in the space dropdown. Where you can specify the access to the views. Edit the view, see the view, per view access within the space.
It’s not technically impossible, but there aren’t many significant use cases for database-wide combinations like the example you gave (Submitter + Viewer). What is the use of being able to create entities, be able to see all entities, but not be able to edit any?
I can think of cases where people should be allowed to create entities, see the ones they have created, but not any others. And also cases where people should be able to create entities but not actually see any of them (including the ones created).
These can already be achieved with Submitter ± Viewer-via-Created By.
TLDR, allowing for granular custom access templates at the Space level will add complexity where we don’t believe the use cases are important enough to demand it.
It is changing. It will be possible to grant Space access without it being inherited by the databases therein. This it what is hinted at with the padlock and toggle:
So in this example, Michael can in fact be a Space commenter and yet have no access to the Initiative database.
It’s quite possible that some UI along those lines will be implemented, but maybe not with the granular level of capabilities you have in mind.
In other words, if the Space level access is Viewer (and the toggle for Apply same access to all Databases is enabled) it won’t be possible to choose an access level lower than Viewer when using the dropdown for the individual databases (and probably with an icon/tooltip to indicate/explain why you can’t choose a lower level).
Fair enough. But I would argue that the added complexity is not large, and that it would it would reduce the “mental complexity” because of a more intuitive UI. (Side note that the Editor permission is labeled as “Can read, update, and share entity externally”, it’s missing that they can also submit… It’s just weird right now…) You need to read each role and understand the permissions. Those icons are now used all over Fibery when it comes to permissions, I really don’t understand why not use them here as well. But if they are used here, but do not behave the same way as in the entity access templates (granular custom) it would indeed be weird. So yeah, it’s all or nothing I think.
Okay makes more sense then! While I’m all for new features and customisability, this really confuses me… The one design pattern that made sense about Fibery permissions is that they are additive and not removable. This takes that away. But only here in the Space → Database and not the Database → Entity. If there are plans to bring it also to Database → Entity, then it’s less of a problem, but right now it’s just inconsistent. And inconsistency leads to confusion. I don’t understand why this is coming… (And its not on the public roadmap, so I can’t read the rationale sadly.) I doubt this will stop it from being released seeing as its already in progress, but I’m curious to hear other people’s viewpoints on this!!
If you want users to have more granular control of the database access, I would just remove “Space Level Permissions” and replace with Space Level Access Templates.
Where you can set Access templates for the Databases (and views!) within the space, then assign those access templates to users, groups, and org. Like in entity permissions. (Consistency!) In the access template settings, you could also set up the template for “Newly created databases” and “Newly created views” so that you don’t need to set up access every time. I think this is the same as what @Illusory is suggesting. Correct me if I’m wrong.
While the functionality is then similar to what is proposed above, it does not make for this weird locking thing where you give access, but then need to remove access. But you can also achieve the same result by giving less access, then adding more access. If you are decoupling the space access from the database access, so why do we need both? Set default space access templates just like in the entity access templates, then new users don’t need to make new access templates just to share with their team the first time. But power users could come in and add their own templates. Just my thoughts, but open to hearing other peoples ideas and viewpoints.
We will soon be tweaking/renaming the access levels so that they are more clear and consistent across space, database and entity levels.
A lot of users never get started with entity-level permissions (and never need to) so some people may never see these icons.
Entity-level permissions are inherently complex, but hopefully space and database permissions need not be.
Being able to share the views in a space, while not granting full access to all databases in the space is functionality that supports a variety of widely-requested use cases.
Part of the reason for the planned solution is due to legacy. Historically, everything was controlled at the space level: all-or-nothing for all databases and all views in the space.
This got gradually untangled, so that it is now possible to have different access levels for different databases in the same space. But views have not yet been untangled, so you can’t share views without sharing dbs.
When they have been untangled, we think that the vast majority of use cases can be solved, without ugly workarounds.
Of course, if we had known the final destination, we might have chosen to support access per view from the outset (meaning different views within the same space could have different access levels). In that case, the concept of space as a permission container would have been redundant.
But that’s not going to happen, and so the next best thing is that a user:
can decide how to share all the views in a space (a space-level setting)
can choose whether to apply this setting to all the databases in the space or not
if not, can choose what sharing levels to apply to individual databases
and/or if necessary
can choose to share entities individually (± inheritance via extended access)
All of the above allow for sharing with a user and/or with a group.
For simple workspaces, with few users, there should be no significant amount of work for an admin to decide what access each new user should have.
For complex organisations, the expectation is that an admin only needs to decide what group(s) to put a user into, and everything else just works.
In terms of the ideal UI for this, we will obviously work hard to make it as simple and effective as possible. Let’s wait and see how good or bad the UX is for achieving specific use cases, both the simple ones and the complex ones, and then we can decide if further iterations are needed.
I see. Thanks for the detailed explanation. I agree that indeed it should be simple because it’s something a new user will do right away, as opposed to entity level permissions.
Agreed! But I also understand the complexity.
And now I see also that in the context of the spaces, the Groups are essentially the access templates. You add someone to a group in order to give them a certain access level without needing to copy paste across users. You can choose to use a group access, or add someone individually for custom access outside of the “Template” (group). Now I see the value, thanks for explaining it. It’s just a bit more of a mental load when trying to then go into entity access. But hopefully the UI will help understand.
You guys always figure it out! Waiting for whats to come excitedly!! :))
We often have a challenge in getting users to cope with the mental load of what is admittedly a very sophisticated product, but that doesn’t stop us trying
