Someway, user access to documents with user tables used for access controls and permissions?

Grist Feedback
1

It is a bit cumbersome that I must invite users to my document, and then replicate all emails and names in a table to use as source for permissions rules.

Something more integrated and out of the box should exist. I invite other users for ideas however, as I have the problem, not the solution.

1 Like
2

Hey @Rogerio_Penna !

We definitely want to improve access rules. How do you assign permissions? By department (or some other groupings) or do you have a lot of individual-specific rules?

I’ll make a note that you’re a +1 vote for improved access rules and I’ll link this thread so anyone who sees this can add their feedback as well :+1:

Thanks,
Natalie

1 Like
3

Here is my +1.
I currently add a choice field (Edit/View/None) for each table and extra fields for any field level granularity required.

Because of the Spreadsheet nature of Grist, I think there isn’t enough data protection. So I add the following

  1. A PermissionToDelete field in my sysUserAccess table
  2. Users without this permission can only flag records for deletion using the FlagDelete field in each table, which can be filtered from view or shaded as flagged for deletion. This is then an admin role to delete flagged records.
  3. A CanDelete field to each table which checks for dependant records in other tables to enforce referential integrity. Used in Access Rules, but also as a visual que for users that a record cannot be deleted.

To me #3 is absolutely crucial, otherwise Grist can’t really claim to be a relational database. Here is my +100 for that feature. (I’ve asked before)

Regards, David.

4

We assign permissions by different ways depending on the table.

Some are by departments. Some are by Responsible (user selected in a row).

Internal Auditors must have access to everything, just to read. These are the most common.

The title of this thread is so badly written that I can´t even understand what I meant with it LMAO.

But my basic point of view goes somewhat in the line that, when adding users to a document, maybe Grist should automatically create a user table.

Many systems have what seems like an independent User/Department section, that is used all across the system.

So the user does not have to replicate it everywhere.

But then, maybe even the more complex system would be considered a single document by Grist.

While in Grist I avoid using a single document for everything because:

1 - the recommended limit is 100 thousand rows
2 - the menu system gets really complicated and large and unusable, because you can´t hide pages and subpages a user can´t see in an easier way, you can´t auto close submenus, etc

So, I guess the simpler way would be for the user table to be created as you go adding users to a document. Let users add other columns, while the user columns itself is controlled by Grist.

Grist somehow add a way for some tables to be synced between different documents. Like with n8n, but simpler, all inside Grist. Maybe behind the curtains Grist automatically just connects to it’s own API to do that.

So I create a departments table and I create a “clone” of it in other document, and the clones always get updated automatically when the original is updated.

5

@Rogerio_Penna it’s fantastic!
Please tell us how you implement this:

So I create a departments table and I create a “clone” of it in other document, and the clones always get updated automatically when the original is updated.

6

I haven´t created that. It was an hypothetical scenario of how it could be done in the absense of Grist having a single system of users that can be acessed, for permission purposes, from any document.

In theory you can do with n8n. But I barely started playing with Grist + n8n

1 Like