Menu Visibility should be inherited!

[Rogerio_Penna]

Yes, we know we still don´t have View/Page based permissions, only permissions based on Tables.

But with or without it, the Permissions should be inherited in the menu. Meaning that if a user can´t see a page, pages that were put INSIDE that one should be invisible too.

I mean… this shouldn´t happen

If I create a table just to insert widgets with it in a page and hide that page, it’s already a cumbersome way to hide pages, please, don´t make me insert it in ALL PAGES with Configs that only the Administrator should see. Just let me insert it in the Config page and every other page UNDER Config will disappear, just like Config.

If you think it’s important for users to be able to see pages inside pages they are blocked from seeing, create this option in the Access Rules of the Document:

“Allow users to see nested pages of pages they can´t see: YES/NO”

[dmitry-grist]

As far as the UI of it, I totally agree, the way it looks in your screenshot feels wrong. But the big concern is: would people realize that a page not being listed is insufficient to limit access to data? If a table is accessible to a user, the user can get at that data even if there is no page in the left panel. For instance, via Raw Data, or via that hidden page if they put in the right page identifier in the URL.

In other words, Access Rules are all about robust access controls, so for anything that looks like it’s providing access control, we want that to be robust too. So I see kind of two paths: one is where hiding pages somehow translates to actual data restrictions; and the other where there is a separate convenience feature to give different views to different users without making any claims about access control. I wonder if your use case is more along the first path, or the second?

[Rogerio_Penna]

Sometimes you want to give user access to data, but not to pages only.

For example, in my case I am hiding configuration pages. They have tables with all columns for me to edit and check stuff, etc. There is a lof of stuff I don´t want end users to see, as they don´t need to see, it will make the user experience worse, but it’s not actually data they CAN´T see, in fact, it’s usually data I WANT them to see, just not in those pages.

[Rogerio_Penna]

I think this is a VERY good example. This page is not about data the user can´t access. It’s about the ACTION BUTTONS. Only the administrator can click those action buttons as they will create in total about 100 rows in 3 different tables, related to a specific company My problem is not the user seeing the data there. It’s the user seeing and clicking the action buttons, which are not table and thus can´t be hidden. The only way to hide the action buttons is to have alongside them a widget with data the user is not allowed to see.

[Rogerio_Penna]

so I created a table called Config (for the main Config menu) and made it invisible for everyone but the admin.

And had to include that table in EACH ONE of those submenus.

here, in this page with the 3 action buttons, the table config is hudden (I made it very slim) on the bottom rightside of the window.

in some other of those pages under Config, I had to include the table on the very top

[dmitry-grist]

Yes, it all makes sense.

So a relatively simple thing would be to address your first concern you listed: if a page is listed as CENSORED, don’t show it or any of its children. That’s a UI-only change. I think it is safe to make – I can imagine some people may have a situation like yours, in which case some pages that are currently accessible to people would no longer be shown. But it is hard to imagine that anyone is happy with the current behavior, so it’s reasonable to change.

I relayed this fix to the dev team.

For actually controlling pages without the “add inaccessible table” workaround, I can’t think of a good way without using Access Rules, because in some cases you’ll need to specify who should see the page. “Just owners” may be a common answer, but not the only one people will want, and access rules is where we have a mechanism for specifying “who” flexibly.

---

For the rest, let me describe a couple of ideas how to hide pages better.

One is the idea have “personal pages”, i.e. pages that you create for yourself and can come back to, that are not shared with anyone else. (Simple to understand, but could get annoying if you’d like to let someone else use this page without sharing it with everyone else.)

The other is a very flexible idea…

• Imagine we have a concept of “Access tags”. By default, there is only one such tag, called “Owners only”.
• In access rules, there is a section for them, and you can add other tags, and specify rules for each. E.g. for “Owners only” (the tag that would exist by default), the conditions would be: if user.Access == OWNERS, give permission All; for all others give the permission None.
• In the page menu, you could “Set access tag”. If you set it to “Owners only”, only owners will see it. You could specify another tag if you created a different one.

In implementation, it would use a helper table, like _grist_AccessTags, with a row per access tag, containing just a name. When you set an access tag on a page, the page record would get a reference to the access tag record. When the document is served, access rules would determine which permission applies to each access tag, and apply the same permission to any page that refers to that access tag.

In theory, this could then be extended to allow setting access tags on other bits of the UI, e.g. on a page widget, or a field within a widget. In practice, I don’t know if anyone needs that.