Two Users with same license, profile and permission sets. One gets error on load more". Salesforce "

Hi Raymond,

I’m sorry you’ve been dealing with this for so long. I have a few questions if you don’t mind:

Does the problem happen for User 2 regardless of which computer he’s using?
What about other browsers besides his default browsers? 
Which version of Skuid is installed in this org?
Are you able to set up a basic new page that connects to this object and has a similar table? The goal would be to determine if the problem lies within your existing page or if it’s something that’s on the config/Apex side. 

Mark

Thanks for Responding!
It is Skuid 12.4.6 and several previous versions.
Happens on multiple computers. Happens on multiple browsers. Happens when I use the “login as” function too. 
I am using API v.1 page. 
Your suggestion to build a simple page was a good one. I did that, but it had the same result. It isn’t the number of records retrieved in each batch. Whether I pull 20 at a time or 200 any time I hit the load more button or try to export with the “load all rows” option, it throws the error.
Thanks!

Raymond, can you post the code for the VF Override page that is used to display Skuid?

Is this happening when you “Preview” the Skuid page from Page Composer as well as when using Skuid from a VF override page?

Can you post the XML for just the Models in the Skuid Page? That might help narrow down.

Hey, Zach!

It happens from the preview page. Doesn’t seem to have anything to do with VF Override. Model is very simple. No conditions. It is accessing an object from an installed package. I would assume that there is something preventing the user from accessing the records in the installed object, but the user can access as many records as will load in the initial query. It is only when clicking the load more button that we get the error.

Thanks for looking at this!

Thanks Raymond. Can you verify that the users in question also have “View All” permissions on these related objects being referenced here: Account, OASP__O_Household__c (not exactly sure what the objects are, but i’m guessing based on the field names 🙂 — or at least permissions to view all records which may be referenced through these Lookup fields? Also, make sure that they have Field-level Security and Object-level Security permissions to read all related fields and objects in this chain, from OASP__O_Household__c field, etc.

Good question and yes. That is what I trouble shot with Salesforce support. I assumed there must be a permissions or sharing issue, but I couldn’t find any and either could salesforce. Two users that have the same license, profile, and permission sets. One can use the “load more” button and one cannot. I have even checked other users and the same issue is true of ALL USERS except me. I am the only one that can use the Load More button on this object and a couple others.

I am the the one that set up SKUID and I am the only one that can use the load more button for this object. Is there a chance it is SKUID license or settings related? 

As a sanity check, have you ensured that all the affected users have a Skuid license and the Skuid Page Viewer permission set?

If there was a way to do it, my next troubleshooting step would be to try and compare network request or SOQL query that’s being sent when you click Load More, to when other users do it.

Haha… that would be embarrassing. I haven’t found the answer, but I did find the culprit. I could see it was happening on a lot of objects but not all. All the objects that throw the error are from the same installed package. Objects not in that installed package work fine. Permissions are the same for the two users, but there must be something about the installed package that is incompatible with the load more. Thanks everyone for your help… I’ll keep digging.

Ah, so do all the users have a license to the installed package where the objects are coming from?

“Kind of” . It isn’t a traditional App Store app where they charge by user like SkUID with licenses for assignment. We have users in another system and we pay a single fee for the app for all users, but there must be some sort of configuration on their end for which users can access which features. Just not sure what permission would allow a user to query as many records as they want on page load, but would restrict them from adding more records through the add more button. Question: Is the load mode query a different api call than the initial query? I assume so. So the permission limitation must be on the load more records query type, correct?

Load More code path can be slightly different, yes. This error message that is being received comes from the Visualforce StandardSetController, which Skuid may use to query both on initial load as well as on load more. I haven’t seen anything conclusive searching the internet other than “check your permissions” related to this error message, but it’s a Salesforce error, not a Skuid error, which customers not using Skuid have received as well. All of the posts i’ve seen seem to point to permissions-related configuration being the culprit. 

My only guess for why it’s working differently for one user and not another is that the queries being run are returning more / less records for one user vs. another, so some sort of internal Salesforce threshold must be being exceeded for one user. 

Thanks for the research. Your hypothesis seems to make sense, but if I have a table attached to a model set to load 20 records from a query returning 300 records and I hit “load more”, one user loads the next 20 fine and the other gets the error. It is so weird. Thanks for your digging. I’ll reach out to the sponsor of the installed package and to salesforce with the new info that it only pertains to this specific installed package. See if anyone can answer the riddle.

In the shocking season finale of this saga, I was able to confirm with the maker of the installed app that it was a access issue built into their installed app permissions. Thanks for the help trouble shooting this and sorry for wasting everyone’s time!