INKED!?

  • 3
  • Problem
  • Updated 2 years ago
  • Solved
  • (Edited)
My users are getting INKED:

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.

????
What am I missing here?
Photo of Matt Sones

Matt Sones, Champion

  • 31,478 Points 20k badge 2x thumb

Posted 3 years ago

  • 3
Photo of Matt Sones

Matt Sones, Champion

  • 31,478 Points 20k badge 2x thumb
Assigning the page builder permission set doesn't help.
Photo of Louis Skelton

Louis Skelton

  • 4,878 Points 4k badge 2x thumb
How about the Visualforce redirect pages - they default to System Administrator access but you have to manually assign other profiles?
Photo of JD Bell

JD Bell, Senior Product Engineer

  • 2,996 Points 2k badge 2x thumb
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.
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
Could be a record-level sharing problem. Did you change your Sharing settings for the Page object, e.g. organization wide defaults? 
Photo of Matt Sones

Matt Sones, Champion

  • 31,478 Points 20k badge 2x thumb
I've never touched sharing settings anywhere. Where would I find that?
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
Setup > Sharing Settings, search for the Page object. If your setting is "Private", change it to "Public Read Only".
Photo of Matt Sones

Matt Sones, Champion

  • 31,478 Points 20k badge 2x thumb
Found it. Looks like Page and Page Assignments were set to Private. Is that the default? I've never had that experience before.
Photo of JD Bell

JD Bell, Senior Product Engineer

  • 2,996 Points 2k badge 2x thumb
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.
Photo of Matt Small

Matt Small

  • 1,182 Points 1k badge 2x thumb
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 =)
Photo of srlawr

srlawr

  • 494 Points 250 badge 2x thumb
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?