INKED!?

Assigning the page builder permission set doesn’t help.

How about the Visualforce redirect pages - they default to System Administrator access but you have to manually assign other profiles?

Hey Matt,

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.

Could be a record-level sharing problem. Did you change your Sharing settings for the Page object, e.g. organization wide defaults? 

I’ve never touched sharing settings anywhere. Where would I find that?

Setup > Sharing Settings, search for the Page object. If your setting is “Private”, change it to “Public Read Only”.

Found it. Looks like Page and Page Assignments were set to Private. Is that the default? I’ve never had that experience before.

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).

While pages deployed via a visualforce component have their names obscured, users can still type in the skuid__ui URL in their browser window:
https://skuid.cs14.visual.force.com/apex/skuid__ui?page=CEO_Dashboard

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.

Hey all, 

Just wanted to let you know that this thread helped me solve a troll of a problem I was having!

Thanks so much =)

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?