You’ve been INKED! (Something went wrong) We were unable to find a Skuid Page named AppointmentQueue. The Page is either inaccessible or does not exist. If you believe you should be able to view this Skuid Page, ask your System Administrator to check the Sharing Model for the Page object to ensure that you have access to this Skuid Page.
7.27.1 installed. Users have skuid licenses and page viewer permission set. Page exists.
Seems that only users who are System Admins can access the page.
Have you shared the page with your users? Pages are subject to sharing rules, so you need to either share individual pages or grant access to all records via the users’ profiles.
Yes, the default for Pages is Private. This gives you additional control over who can access which page. If you have users who should have permission to access all Skuid pages, you can do that with Profile-level security (see “View All” and “Modify All” Permissions Overview).
If Pages were public, this would be an easy way for any user to access any Skuid page. While a user’s ability to view a Skuid page does not equate to their ability to view records they haven’t permission to see, it’s still possible that a Skuid page could have some sensitive metadata on it. For example, the CEO Dashboard might contain a template with the text “Preparing for Merger with XYZ, Inc” - information that some users shouldn’t be privy to.
This page has also just helped me with my research/learning of Skuid. I think it would be handy to have this documented somewhere else a little more clearly (unless I’m just missing it in the docs) - especially with some notes on making a “better practise” of it than simply changing the sharing model from Private to Read All, or giving users “View All” (not that these aren’t perfectly valid solutions to the problem in the scenario that users need access to all the pages…).
I agree with JD Bells thoughts on the record level security beyond access to the page (that I’m just about to play with) and what a good point to highlight that though record level information still abides by the security model, template/hard coded meta data might not be.
Also, I take it the model won’t even load data that the user shouldn’t be able to see at all - thus protecting from $Model global usage in aggregates, or UI only data models getting their hands on things they shouldn’t?