If possible, they should be able to see ONLY the left menu.
users that shouldn´t have access to a lot of stuff are able to see everything if they click on Primary Data!!!
Access rules should work reliably on Raw Data (as well as on API endpoints any any other way to access data). In fact, Raw Data is a good place to test that access rules restrict data permissions in the way you intend.
But they are working elsewhere.
Like, if I log with a different user, I can´t see ANY record on the PDCA table. But I can click on Raw Data and see everything
here… PDCA Table being viewed by Editor type of user… no record visible
Denied Access to Code
but then… Raw Data, same PDCA table.
Really, the tools menu shouldn´t even be available for non admin users…
I didn´t find in the help if there is a way to create a 4th type of role, that would fit between Viewer and Editor. I want user to view or make changes to the document data, but NOT to structure or formulas.
I noticed the user here (help page for Access Rules) doesn´t even have access to Raw Data option.
Access rules should work reliably on Raw Data (as well as on API endpoints any any other way to access data). In fact, Raw Data is a good place to test that access rules restrict data permissions in the way you intend.
I see the problem. Is that sometimes you make INDIRECT access rules.
In my table, users are linked to companies.
The PDCA records are also linked to companies.
I have access rules to companies. Users can only see the companies they are linked to.
And therefore, since widgets are linked, users can only see the data linked to the companies they can see.
But the when accessing RAW DATA, they are able to well, access DIRECTLY the raw data instead of a widgets linked to a table with acess rules.
I think that makes it even more important to be able to hide the Raw Data from common users. Because MANY times, users might want to hide data based on other means, not on direct rules based on that table.
Glad you found the issue. So you are right, with access rules, you need to restrict access to each table separately.
It may help to deny access by default, then add access explicitly to each table, to make sure nothing is slipping through undetected.
We could try to automatically create (or suggest) additional rules to apply to linked tables. That could be tricky, since there are many different ways to link data.
Regarding the 4th role, you can achieve something similar by giving users “Editor” permission (which allows data AND structure changes), then removing the “Structure” permission in the Access Rules page:
Hiding the raw data page would make it harder for a user to discover any data they shouldn’t see, but a savvy user could still use the API to get at anything permitted by the rules. Today, raw data pages are helpful to the creator using “View As” to explore the effect of rules, though you are right, for users you are trying to limit, offering “Raw Data” page feels wrong.
So you make a good point about the tools menu generally. It could perhaps be hidden entirely in some cases, or owner could have an option to hide it from all non-owners or certain roles (similar to the option to limit structure changes).
THIS!!!
I think more of the tools could with time be hidden. For many end users, having all those extra icons on the screen, as well as the rightside edit menu, is quite confusing EVEN if they ultimately can´t do nothing with it, being able to access those, mess with them, just to be blocked when trying to save the change, is very confusing and frustrating.
Believe me, I HAVE seen users explore the extra icons. Human curiosity. And they get really lost with the extra icons.
For the internal Grist version we are using in my company (something completely different than the case above, which is a personal project), I am using much more than recommended the iframes because the iframes can hide the menus. Users have a much easier time using Grist in iframes without the menus than with the original interface with tools, edit menu that can be viewed, etc.
Related feature request here: Add possibility to mask lateral columns to simplify uses for beginners · Issue #1266 · gristlabs/grist-core · GitHub