Troubleshooting and perTableParams

[JMPeterson]

TLDR; Is there any guidance on how to interpret or how to effectively troubleshoot the data in the audit logs for the layman? Or am I wasting time/spinning my wheels trying to glean any information from these things?

I have been working to debug some errors reported by our users, but I am having trouble pinpointing the exact culprit. It seems like the errors are only happening to specific users, and I have run through the standard approaches that I can think of to resolve the problems. When I dig into the monitoring tools, I feel like I can see some discrepancies that are raising some flags for me, but I don't know enough about the data being presented to me to make a full assessment.

Now when I pull audit logs and look into the details, I notice that for the users having issues, their logs are much shorter and look incomplete compared to users not experiencing any issues. For example, the "perTableParams" section of the log will only have three tables formatted like the following:

"{\r\n  \"table1\": {\r\n    \"time\": \"2024-01-08T20:13:33.2710046Z\",\r\n    \"etag\": \"randomalpanumericstring\"\r\n  },
\r\n  \"table2\": {\r\n    \"time\": \"2024-01-08T20:13:33.556345Z\",\r\n    \"etag\": \"randomalpanumericstring\"\r\n  },
\r\n  \"table3\": {\r\n    \"time\": \"2024-01-08T20:13:33.6792236Z\",\r\n    \"etag\": \"randomalpanumericstring\"\r\n  }\r\n}"

However, for the users not experiencing any issues, all twenty-three (23) tables, and the "_Per User Settings" table will have the associated data points.

In a similar fashion, there is run of information for each table in the app like the following: 

"Table:_Per User Settings": "LastModified:1/8/2024 8:15:23 PM, NotModified:False"

All the associated tables are represented, but the "True" or "False" designations are different for each table per user, and don't necessarily correlate with actual changes the users are making in the app. I might be digging too deep and may not need to be reading into the logs like I am, but its something I noticed and I would like to better understand what's happening with them.

[AleksiAlkio]

May I ask what is the original error message?

[JMPeterson]

One of the original errors was "Unable to update row in 'table'. Cannot update identity column". That issue has been resolved. The other bug we are seeing does not have an associated error message, its just views and columns aren't available to specific users.

[AleksiAlkio]

Is the view always not visible for the same user? What happens if the user opens the app with another device? Is it still hidden? What kind of issue is it? Is the view name visible, but the view is shown as a blank page?

[JMPeterson]

The view window itself is visible, but none of the columns/content are there, comparison images below.

The user has tried on multiple devices, and different browsers on desktop. So far only two users are experiencing this specific issue.

[AleksiAlkio]

How are you opening this view?

[JMPeterson]

It's a dashboard style view front and center for the user.

[AleksiAlkio]

Is it a detail view using slice?

[JMPeterson]

No sir, its just a flat table with a security filter.

[AleksiAlkio]

But it's a detail view, right?

[JMPeterson]

Yessir, apologies. It is a detail view.

[AleksiAlkio]

As your earlier printscreen shows, "No Items selected".. is it possible that for these few users, it's not able to read that row and then they are not seeing anything? Do you have a security filter in that table and it filters that row away?

[JMPeterson]

There is a security filter that looks at the USEREMAIL(). I can adjust the security filter to call out those specific user's email (e.g. [key]=john.doe@user.com), and of course they come through then. I've tried to wrap things in TEXT() to make sure there wasn't a datatype mismatch, but have not had any luck so far.

[AleksiAlkio]

And your security filter formula is?

[JMPeterson]

[key]=USEREMAIL()

[AleksiAlkio]

Any chance the user is logged in with a different email that you have in your table? That would explain why it doesn't find user's own row.

[JMPeterson]

I worked with one user to confirm just that, had them log out and back in. They were using the correct email and are still unable to see the options. We also use domain authentication, so it needs to be the correct email for the user to access the app.

Reminds me of this issue that I've run into before. Although not exactly the same, it just feels like it refuses to find the row even though it exists? I'm sure there is a clever work around, but I am open to additional suggestions or insights. 

[AleksiAlkio · Accepted solution]

Any chance they are using alias email addresses and the auth provider sends different email address to AppSheet after they have logged in? This you can easily test if you use USEREMAIL() as an initial value somewhere and then ask the user to fill out a record. 

[JMPeterson]

This was a very good suggestions. The emails were the same, but the capitalization was different. I am not sure how that happened but essentially "john.doe@email.com" <> "John.Doe@email.com"...

Now I just feel silly.

[AleksiAlkio]

Interesting.. it should not be case sensitive