Inaccessible field on User Side (production 11.1.8)

After upgrading our production org to 11.1.8, we are seeing a user side error on inaccessible fields. I understand there was a recent change to Skuid to show page builders inaccessible fields on the design side, but now we are seeing different behavior on the user side.

We have a case with a condition on a model, and the condition uses a field that the user may not have read access to. Pre Skuid 11.1.8, the condition would just be ignored. Now on 11.1.8, the user sees red bars saying a model condition is using a field that they don’t have access to.

Is this to be expected?

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. :wink:

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

No worries. :wink:

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.