I have a Student table where there is an email column. In the Access Rules, for the User Attributes, I have set user.Email to lookup Students.email.
The problem is that somebody entered his email as Abcd.Defg@blabla.com , and in my email column it is entered as abcd.defg@blabla.com (note the lowercase a and d ).
There should be a way to indicate that the user.Email field has to be lowercased, or that the lookup is case insensitive.
The user has access to the document, so the ‘manage users’ part is case incensitive. But he was not able to see the row where there is a rule like “rec.Email = user.Student.email”
Maybe as a workaround you could just add a column with the formula $email.lower() to the Students table and then use that instead of the actual email column?
It looks like @Benoit_Desrosiers response came through to support only;
Hi,
no, it’s the other way around. In my table, the email is already lowercase. The problem is that when my student registered, he entered his email with uppercase. So in the user.email it has uppercase and that I cannot add a .lower().
I have shared this feedback with our team. I did some more testing with this and agree, it is frustrating. When I initially tested, I used accounts where the emails were always lower case and had not thought to use one with uppercase. For those coming to this thread and thinking “How am I supposed to know exactly how a user typed their email at signup?!”, I have a workaround for this situation.
Add a team member to your document. My test account has the email Natalie+TEST1@getgrist.com. I am going to enter it in all lowercase when I add it to the document. It doesn’t matter how you type the user’s email, it will appear to be added in all lowercase, like you see in the screenshot below;
Click confirm to officially add the user to the document. Now, reopen the Manage Users menu. You’ll see that their email address has updated to reflect the exact capitalization they used when signing up for their Grist account. You can copy this value and paste it into your user table. Then, the two emails will match exactly and your access rules will work.
I hope this workaround helps in the meantime.
Thanks,
Natalie
Reply came via support email:
Is there any plan to fix it?
Yes, our dev team is actively looking into this issue. Unfortunately, I don’t know an ETA for when it will be resolved but I will update here when it is!
Thanks,
Natalie