Operations on tables: I have a small problem...

(Viktor) #1

Operations on tables:

I have a small problem on limiting who can make modifications to a table in AppSheet. The thing is, we have a sheet (Google Drive) with all of our users and the different roles they have (for instance, “manager” or “production”). I’ve then created a slice for all users who have the “production” role. The filter for the slice is therefore [Production employee] = “Yes”. This seems to work without problems

The issue is, that I’ve made it so only users who are a part of this slice can add and update to a table - The rest is read-only. This works fine for me; when I have the production role I can add and update, and when I don’t, I can’t. However, another user of the app cannot add or update to the table even though she has the role, and we seriously cannot figure out why. We’ve cleared browser cache, browser data, tried it in another browser, removed her from the app and invited her again, but none of it works. It just says that the table does not allow the operation as if she doesn’t meet the requirement for adding/updating.

The filter on the table looks like this: IF(IN(USEREMAIL(),Production employees[G User]), ADDS_AND_UPDATES, READ_ONLY)

Does anyone have a suggestion?

(Aleksi Alkio) #2

First check what is her email address with the simple USEREMAIL() expression. Then check is it exactly the same than in your [G User] column. If it works for other users, then the problem needs to be the email address.

(Steven Coile) #3

The in() function is case-sensitive, so the address returned by useremail() and the one stored in Production employees[G User] must match exactly (including upper- and lower-case letters).

(Viktor) #4

I agree with you, it is odd indeed. Another interesting thing was, that when you start the app, it starts in a certain view if you have this “production” role. If not, it should start in another view. She reported that when I removed her “production” role, it actually still started in that view.

The formula for it is: IF(IN(USEREMAIL(),Production employees[G User])], Movements, Assets)

I found it interesting when she said that, because I had the same error as well, but that was before I added the formula above (so not really an error), but it works fine for me now, so somehow it almost acts like she isn’t working in the newest version of the app. However, that doesn’t make much sense to me (all users work in the latest version), so it has to be something else. Unless only some of the changes I make to the app are updated to the rest of the users

(Steven Coile) #5

As a suggestion to avoid another potential problem, when initially storing the user’s email address, use upper() (or lower()) to force the case of all letters, then do the same to useremail() when comparing. Internet email addresses are not case-sensitive, so converting case won’t invalidate them.

If you aren’t already doing so, use and Email-type column to receive the user’s email address, especially if manually entered. Then the column itself will do some address validation.

(Viktor) #6

I’m already using the Email-type but thanks for the tip about upper()/lower(), I didn’t think about that!

(Viktor) #7

The e-mail she’s logging in with seems to be exactly the same as the one in the [G User] column, but since it works for me, I’d suggest it would be the e-mail address as well. However, a workaround seems to be that instead of limiting operations on the table itself, you can limit who can use the system-generated actions (such as add, edit, delete) and achieve the same goal although it takes slightly more work.

Nevertheless, thank you for your suggestions!

(Aleksi Alkio) #8

I would say don’t add more work for you because it should work correctly. There has to be some reason for this behavior. What is the account ID number and the app name… and if it’s okay to check your app?

(Viktor) #9

Thank you for your interest, but the workaround is no problem at all. It is only a few actions that I have to filter away for those who don’t have the specific role. I don’t know if I can share the app, since I’m not working alone so I would probably have to go further with that request which seems a bit unnecessary when the problem isn’t bigger than it is. It’s interesting though, that the formula I use to “hide” system actions is:

IN(USEREMAIL(),Production employees[G User])

And this seems to work without problems both for her and me, so I guess that means there is not a problem with the e-mail address (since it is able to match her e-mail with the e-mail in the [G User] column).

(Aleksi Alkio) #10

I just want to be sure there is no bug in our code that we should fix. You said on your original post that “It just says that the table does not allow the operation as if she doesn’t meet the requirement for adding/updatin”. It should not show any alert and saying anything. Are you able to take a printscreen of that situation?

(Viktor) #11

Of course, I understand that, but it could likely be either a mistake on my end or hers. Unfortunately, I was/am not able to be present at her computer, so troubleshooting became pretty difficult. I’ve attached a photo that she sent me of the error message she got. I was able to recreate it, by going into a form to edit something that I was only allowed to if I had the certain role, then I went into the sheet behind and removed my role, and then tried to save the edit I had made, resulting in the same error.

It makes sense that I got the error since I removed the role that allowed me to do such edits, but obviously she should not get it when she has the role. Interestingly, the add/edit/etc. buttons disappear when you’re not allowed to make operations to the table, but it seemed like she had the buttons available, but just couldn’t use them (I tried removing her role and she confirmed that the buttons went away like they should, and came back when I gave the role back)

edit: Just to clarify, as I realize the below picture is quite cropped - It’s the picture that is displayed when you try to sync something that you’re not allowed to

(Aleksi Alkio) #12

Okay it seems that the issue is not the email address or the IF formula because it’s working correctly. Is she trying to add/edit record in a slice? Does it work correctly with the normal table?

(Viktor) #13

She’s trying to add/edit directly in the table

(Aleksi Alkio) #14

This is weird because the “Are updates allowed” option seems to be working correctly because she can see buttons as normally and she should be able to add/edit record. Without opening & investigating the app, it’s difficult to say more than this.