Regular users generally should not see these sorts of error messages. Page Problems are only visible to Skuid Page Admins.

In this case, “Skuid Page Admin” is defined as having Write access to the Skuid Page record. (Note that Sharing rules are taken into account; so, a user may be an Admin for one page but not another, depending on the permissions.)

Can you verify whether the affected user has Write permission to the Skuid Page object? Write permission can be granted either via the user’s Profile or by Permission Sets (such as Skuid Page Builder and Skuid Admin).

If your user is still seeing the message, can you provide more details about the page setup? Perhaps a sample of the Page XML?

We are seeing this on the user side. This user does not have Write access to the page object, and they are not a page builder.

Here is a mocked up page. I tried it 2 ways: with a Standard field and a custom field. If you remove permission (read) to the custom field used in the filter (Closed_Date_Only__c), then you get the page error thrown on the user side. The standard Salesforce fields (NextStep) don’t appear to be causing the issue. Weird.

By removing their write access to the page object, you should fix the issue.

This user only has Skuid Page Viewer and doesn’t have write access to the Pages object.

Sorry. Misread your post. "… don’t have write access … "

Thanks for the XML Chandra. I created a page based off your page in a dev org.

Please bear with me while I try to establish some common ground and get simple things out of the way.

My test user has a Profile with the following permissions on the Opportunities object:

My test user’s Profile has the following permissions on the Skuid Page object:

With the “Edit” permission on the Skuid Page, I see the following errors:

When I turn the “Edit” permission off, I see no errors:

Can you review the profile and permission sets assigned to the affected user and verify that none of those permission sets assign additional permissions on the Opportunities and Pages objects?

Thanks JD for looking into this.  I am trying to repro this in my sandbox (which is on the newest skuid version), but the problem was seen in production - on 11.1.8.  I did confirm the affected users in production have the Skuid Page View permission set, and that permission set and their profile don’t grant write access to the skuid page object.  We solved this by giving the profile access to the filtered fields (closed_date_only__c) and in that case they actually SHOULD have been given permission, so the error did surface a problem that we fixed.

So, I’ll ring you back if we see it again.  I don’t want to re-create it in prod and cause alarm with our users again.

OK … seems as though it was page BUILDERS that were seeing the error, not our viewers.  So I think the behavior is working as expected.  We will reach back out if we see differently!  Thanks!

Thanks for the update Chandra.

Hi All, actually I’m able to reproduce the same problem after update to SKUID 11.1.10. 

Long story short to give you an overview: I have model built on Account where I have field TOwnerChanged__c and custom page to view the account details - one for all users. The field Account.TOwnerChanged__c is available only for System Admin. 

If I go to to the Skuid Page for Accout with Sys Admin profile -> no error. 
If I go to the Skuid Page for Account with any other profile (which doesn’t have access to that field) -> the error is thrown:  

1. A Skuid Model, ‘Account_Parent’, requested a Field with relationship name ‘TOwnerChanged__c’, on the Account Object, but Skuid could not find a valid Field accessible through this relationship name. Please check that this Field actually exists on this Object (or on any related Objects). If it exists, then ensure that the user has permission to access it. If it does not exist, remove it from this Model.

Previously it was working fine? What is the problem here? For me it is a critical issue. 

This conversation has the solution you’re looking for.

Hi, yeah, the pages access was a problem Sorry for a false alarm!

No worries.

We have another incident with a user in production.  Skuid Page Viewer, Read only on Pages object.  I have sent an email to skuid support, granted login access rights.  We are leaving this broken in production so it can be looked at.

Do they have a permission set given to them that has Pages object w/ write permission?

Hi Chandra,
Thank you for sharing these additional details. We are taking a closer look at the intended behavior of this error message, given the security settings you have in your org, and will reach out when we have more information to share.

We are having these errors as well, I understand giving users access to the fields resolved the issue but this is not an option for us because there are fields that we do not want to be visible to all users. Is there another solution? 

Hi Andrew,

Users who only have the Skuid Page Viewer permission set (and thus, read-only access to the Page object) should not see errors about inaccessible fields in runtime.  Please check to see if other permission sets or settings are granting these users access to the Page object beyond “read” level, and let us know what you find. Here’s a summary from our Releases page about this:

“As of Millau 11.1.3, we now report inaccessible fields as Page Problems to aid Page Builders in resolving inconsistencies between the Page Composer and the runtime. Users with Skuid Admin or Skuid Page Builder permissions may now see Page Problems. This does not represent any change in behavior for standard Skuid users.”

this user has 5 permission sets.  I checked every one, none have Pages access except “skuid page viewer” and that is set to Read only.

I checked my affected user and she has ONLY read access to pages.  

Hi Mark,

Limiting access to just “Read” seems to have fixed the issue. Is there a reason to give them access to Read? 

Chandra, as Mark mentioned above perhaps your affecting user is being granted permission somewhere else.

Andrew - read to the bad field?  Or to Pages.  I don’t see any place where my user has edit access to the Pages object.  I have checked her profile and all 5 perm sets.

Andrew, to clarify: the deciding factor on whether these errors are visible on the page is whether or not user has read access to the Pages object. If they do, it means they have Skuid Page Builder and/or Skuid Page Admin permission sets, and should see field accessibility errors.

On Friday, we discovered that these field accessibility errors are being shown on the page for Skuid Page Viewers, but only if the following is true:
1) the model has a condition using an inaccessible field
2) the model is being queried by the Action Framework (i.e. not the model’s initial query on page load).  

We will keep you up to date on this Community thread as we have further information.

Wondering if a status could be provided on this investigation.

Hi David, 

The issue is known to our development team. The fix doesn’t have a release date yet, but it should be in an upcoming maintenance release. My response above, from April 30th, explains the product issue that can cause these errors to show on the page. Just to clarify though, the first thing you would want to do is rule out any legitimate reasons for these errors to show on the page. For that, please ensure that all field accessibility settings are accurate, and that the affected user does not have the Skuid Admin or Skuid Page Builder permission set, and doesn’t have edit access to Skuid’s Pages object.