Hide Spaces from non-Admin Users

Ideas & Features
1

It would be very useful to be able to hide Spaces from non-admin users in the Left Menu, regardless of whether they have permissions to access a space:

  1. Keep the Left Menu sparse, help users focus and reduce cognitive load.
  2. Restrict user access to only certain views.
2

Is this needed because you want to grant a user access to a space in order for them to have permissions for the contained databases, but without wanting them to see the space and all its views?

3

I want to hide all “normal” spaces with DB’s from all non-admin users (even those they can access), and only show them a specific set of “presentation spaces” that just contain views, not DBs.

4

But if they are Editors, they don’t see databases, they only see views.
Perhaps I’m not seeing the wood for the trees. Is there a concrete example we can hang this discussion on?

5

The simplest way to explain it is that as an Admin I want more control over what my Users can see in the Left Menu. And I specifically want to prevent them from seeing most of the Spaces containing DB’s, since there’s no reason they need to - just to reduce the complexity of their interface.

I want my users to only be able to see a few “curated” Spaces containing only the specific Views they need to do their jobs (and no DB’s). E.g. one custom Space for each department in the company, containing only views designed for that department’s particular workflows and needs.

3 Likes
6

Not sure I understand what you mean by ‘views containing DB’s’… :thinking:

You don’t mean the space configuration page (where databases are created, permissions managed, fields can be added/edited etc.) do you?

7

I think a lot of people have this exact issue that Matt is describing. Using empty spaces with your views to better curate department/group flows, and then hidden spaces with all your databases. Hiding seems like a perfect solution. Until entity permissions are released at least.

We personally have “data level 1/2/3/4” spaces with no views but all our databases so we can better control user group permissions per database. Then we sync space order so these are at least hidden but it still causes confusion some time. Also last I checked there is still the bug that allows anyone to view the database pages if a space has no views at all

2 Likes
8

When you say ‘empty space’ I presume you mean a space without dbs.

This was basically what I was asking about here:

If @Matt_Blais does mean the same as you (wanting to hide a space that contains dbs for which the user needs permission, but otherwise is not relevant to them) then yes, you’re right that the new permissions model may be what’s needed.

Technically, this isn’t a bug since it is behaving as designed/intended :slightly_smiling_face:
If a user has access permissions for a space, then he/she is entitled to see the contents of all dbs in that space.
It was an early decision that clicking on the space name would redirect to showing the first view in a space for those users with anything lower than Creator level permissions (since the space config page is not interactive for these users).
If there are no views, there is nowhere to redirect to so they see the space page :man_shrugging:
But from a permissions perspective, there’s actually nothing here that they’re not allowed to see.

1 Like
9

Yes, that is what I do NOT want most of my users to see - the “space configuration” page for Spaces with DB’s.

10

Then, in that case, they should have Editor permissions or lower, and as mentioned above, there should be at least one view in the space to which they can be redirected.
A simple ReadMe doc is sufficient (maybe with some #mentions of views in other spaces that they will find useful).

1 Like
11

Thanks @Chr1sG - that is a quasi-solution for my needs, but I still would like the higher level of control over what Users see in their Left Menu.

As @ccollins mentioned above, with the current Space-based permissions it is all too easy to end up with a large number of Spaces = CLUTTER and cognitive load, especially for new Users.

When there are multiple departments/groups of Users using my Workspace, I foresee that it will be time-consuming for me to set up each new User by customizing their Left Menu view for their department/Role.

Right now I believe the only way to do that is log in as the new user (which means screwing with their email) and manually move/hide a bunch of spaces.

Ideally we could just assign a “Left Menu Template” to a User.

2 Likes
12

To an extent, this is what the group permissions can be useful for - define roles, work out what they should/shouldn’t have access to, and then just assign any new users to the relevant role.
It doesn’t enforce space hiding, but it might save some time.

1 Like
13

OK, here’s a little something that you might find useful. It’s a script that will propagate the space ordering that you have to any other user (including hiding spaces).


const fibery = context.getService('fibery');

for (const entity of args.currentEntities) {
    const userToCopy = await fibery.getEntityById(entity.type, args.currentUser['Id'], ['fibery/menu-rank']);
    await fibery.updateEntity(entity.type, entity.id, { 'fibery/menu-rank': userToCopy['fibery/menu-rank'] });
}

It should be put in a button automation in the User database (you need to open a User’s entity view and click the triple dots, choose Edit fields, to create an automation).
Then you can open any User’s entity view and press the button. They will then inherit your space ordering.

So, for example, you (Admin) have the spaces arranged like this:

  • C
  • B
  • D
    Hidden
    – A

A new user logs in, with access only to A, B and C. They might see this:

  • A
  • B
  • C

but if you run this script on their User, they will get this:

  • C
  • B
    Hidden
    – A

Disclaimer: this is not official/publicly supported/guaranteed to work etc.

p.s. you will probably want to hide the button when you’re not using it :wink:

3 Likes
14

Thanks @Chr1sG , that is super useful! :grinning:

If this part of the API was “officially supported”, then I would mark this as a Solution, but… :thinking:

1 Like