How to have users belong to AUDIT TEAM and allow Audit Team to see tables blocked to most users?

[RogerioPenna]

So, like most examples in the Access Rules, I have a USERS table, with common name and email for users.

I would like SOME of those users to be auditors (that can change depending of semester). And auditors should have access to some tables that right now, few people have access.

My first thought was to add a column “Auditor” of the type Boolean to the Users table.

But I am at a loss on how to use that new column on the User Attributes of the Permissions Panel.

these are the rules being used right now for the table
user.Access != OWNER and user.Membros.id != rec.Responsavel and user.Membros.email != "user1@gmail.com" and user.Membros.email != "user2@uol.com.br"

As I understand, there are inherent user atributes that come from the system. And what we are doing in the rule above is telling GRist to check user attribute “membros”, column email and get from that if it’s the user.Email (which is stored in the system)

My only guess on how to make this work with the Auditor rule is to create a new column in the Usuários table, where IF Auditor = yes, then it repeats the email. from the email column.

And thus I get the user attribute searching for that “second” email column, which only have anything if the user is an auditor…

Is there a SIMPLER WAY? Maybe I am going for the most complicated way?

PS: I realized that even creating the extra column in the Usuários table and repeating the email if the column Auditor is yes…

and creating the User Attribute “Auditores” in the Access Rules, searching for attribute user.Email, using the Usuários table and column “emailauditores”…

… that I still don´t know how to set the table rules to allow the auditors to see stuff lol

[natalie-grist]

Hi there!

Including a toggle column in your users table is the right way to go. You only need your original user attribute. A user attribute is telling the system which record matches the logged in user. For example, Membros checks user.Email (the email address of the current, logged-in user) and matches it to a value in the Email column of the Usuarios table. We have an example from a webinar that is going to be very similar to your needs.

Project Management Webinar Template: 6 - Project Management (full rules) - Grist

This document has a user attribute just like yours that checks user.Email and matches it to a value in the Email column of the People table.

Let’s say a user is logged in to Grist with email leonardo@tmnt.com. The user attribute would look in the People table for a match in the Email column. A match is found in row 2. Now it knows that the entire record is associated with the logged in user. It knows that their name is Leonardo and they are a Manager in the Martial Arts department. We can use all of this information within our Access Rules.

We can grant or restrict access to things based on whether or not a user is a Manager. You can see this in action in the Rules for table All Tasks

The second condition is:

user.Access in [OWNER] or user.Person.Manager_ == True

If a user has OWNER access or they are a Manager, then they have full permissions to this table. We have to take into account the first condition which restricts access to records where the value in the Archive column is True for non-owners. Because these are restricted, the second condition takes this into account and grants full permissions where the value in the Archive column is False.

I included a recording below of this webinar that walks through the permissions step by step if you’d like a more in-depth review!

Access Rules - Mar 16, 2022

If you have any follow up questions, please let me know!

Thanks,
Natalie

[RogerioPenna]

@natalie-grist

user.Access in [OWNER] or user.Person.Manager_ == True

Thanks Natalie, but “something wrong is not right” in my system lol
So, this is the usuários table

This is the Rules table

This is the rule 1 of Não Conformidades table
user.Access != OWNER and user.Membros.id != rec.Responsavel and user.Auditores.auditor == True (everything red)

and rule 2 (at first I created it and tested it. As it didn´t work I added the condition to rule 1, so now they look very similar)
user.Access == OWNER and user.Auditores.auditor == True (read and update green)

When viewing as one of the Auditors, nothing shows in that table.

btw, if I remove user.Access != or ==, I get something about not allowing chained comparisons
example

[natalie-grist]

Could you share your document with support@getgrist.com as OWNER so I can take a closer look?

For the chained comparisons error, the issue is that you have a condition where A = B = C. It should be in the format A=B and C=D. Something is either missing or was not fulling deleted from the condition.

[RogerioPenna]

but how do I manage user access to be given to user.Auditors.auditor == true? Don´t I need to use user.Access to tell who has access, in that case user.Auditors.auditor if TRUE?

[RogerioPenna]

" Could you share your document with support@getgrist.com as OWNER so I can take a closer look?"

done

[Rogerio_Penna]

Hi Natalie, I shared the document with support@getgrist.com as owner.

[natalie-grist]

@RogerioPenna

but how do I manage user access to be given to user.Auditors.auditor == true? Don´t I need to use user.Access to tell who has access, in that case user.Auditors.auditor if TRUE?

user.Access looks at the access level assigned to the user for the document under the ‘Manage Users’ menu; Owner, Editor or Viewer.

In the screenshot, support’s access is OWNER so whenever there is a condition user.Access == OWNER, that applies to the support user.

The third user in the list is EDITOR so any condition where user.Access != OWNER or user.Access == EDITOR would apply to this user.

In order to find out if a user has auditor set to true (or toggled on), we can use the user attribute Membros.

This looks at the email of the logged in user then checks the Usuários table to see if a match exists in the email column. If a match is found, then access rules knows that the logged in user is that record. For example, I am logged in as support@getgrist.com so it knows my name is Grist Support and I am not an auditor since auditor is set to false

If I add a condition to Não Conformidades with the formula user.Access == OWNER and user.Membros.auditor == False and deny all permissions, then any user with OWNER level access and who is not an auditor would not be able to see records in the Não Conformidades table.

Since support fits both of these criteria, all records are hidden in the table

You can also limit/grant access solely on whether or not a user is an auditor and disregard their access level in the manage users menu. For example, only those who are auditors should be able to update, create and delete records in the Não Conformidades table. Everyone else should be read only. You can do that with the condition user.Membros.auditor == True.

I noticed you had a condition for Não Conformidades where users would have Read Only access if
user.Access == OWNER and user.Membros.id != rec.Responsavel and user.Membros.auditor == True.

For this particular condition, all three things would need to be true for the rule to apply. So, a user must have OWNER level access, their name would not be listed in the Responsavel column and they would have to be listed as an auditor in order to have read only access to that particular record.

I hope all of this helps. Let me know if you have any follow up questions and if there are specific rules you need help with, let me know the specifics around who should/should not have access to a table and I can help you with conditions.

Thanks,
Natalie