Inaccessible field on User Side (production 11.1.8)

edited June 25 in Problems
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?

image


Comments

  • JD BellJD Bell ✭✭
    edited April 2018
    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?
  • edited June 25
    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.

    image


    <skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" useviewportmeta="true" showheader="true">
        <models>
            <model id="opportunities" limit="20" query="true" createrowifnonefound="false" datasource="salesforce" sobject="Opportunity">
                <fields>
                    <field id="NextStep"/>
                    <field id="AccountId"/>
                    <field id="Account.Name"/>
                    <field id="Amount"/>
                    <field id="Name"/>
                    <field id="StageName"/>
                </fields>
                <conditions>
                    <condition type="fieldvalue" value="Test" enclosevalueinquotes="true" field="NextStep" inactive="false"/>
                    <condition type="fieldvalue" value="" enclosevalueinquotes="false" field="Closed_Date_Only__c" state="filterableoff" inactive="true" name="Closed_Date_Only__c"/>
                </conditions>
                <actions/>
            </model>
        </models>
        <components>
            <skootable showconditions="true" showsavecancel="true" showerrorsinline="true" searchmethod="server" searchbox="true" showexportbuttons="false" hideheader="false" hidefooter="false" pagesize="10" alwaysresetpagination="false" createrecords="true" model="opportunities" buttonposition="" mode="read" allowcolumnreordering="true" responsive="true" uniqueid="sk-3Un0-271">
                <fields>
                    <field id="Name" hideable="true" uniqueid="fi-3Un0-306"/>
                    <field id="AccountId" hideable="true" uniqueid="fi-3Un0-304"/>
                    <field id="Amount" hideable="true" uniqueid="fi-3Un0-305"/>
                    <field id="StageName" hideable="true" uniqueid="fi-3Un0-307"/>
                </fields>
                <rowactions>
                    <action type="edit"/>
                    <action type="delete"/>
                </rowactions>
                <massactions usefirstitemasdefault="true">
                    <action type="massupdate"/>
                    <action type="massdelete"/>
                </massactions>
                <views>
                    <view type="standard"/>
                </views>
            </skootable>
        </components>
        <resources>
            <labels/>
            <javascript/>
            <css/>
            <actionsequences uniqueid="sk-3Un0-269"/>
        </resources>
        <styles>
            <styleitem type="background" bgtype="none"/>
        </styles>
    </skuidpage>

  • Pat VachonPat Vachon ✭✭
    edited April 2018
    By removing their write access to the page object, you should fix the issue.
  • edited April 2018
    This user only has Skuid Page Viewer and doesn't have write access to the Pages object.
  • Pat VachonPat Vachon ✭✭
    edited April 2018
    Sorry. Misread your post. "... don't have write access ... "

  • JD BellJD Bell ✭✭
    edited April 2018
    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:
    image

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

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

    image

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

    image

    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?
  • edited April 2018
    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.
  • edited February 2019
    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!
  • JD BellJD Bell ✭✭
    edited April 2018
    Thanks for the update Chandra.
  • edited June 25
    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. 
  • Pat VachonPat Vachon ✭✭
    edited April 2018
    This conversation has the solution you're looking for. ;)
  • edited April 2018
    Hi, yeah, the pages access was a problem :) Sorry for a false alarm!
  • Pat VachonPat Vachon ✭✭
    edited April 2018
    No worries. ;)
  • edited June 25
    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.


  • Pat VachonPat Vachon ✭✭
    edited April 2018
    Do they have a permission set given to them that has Pages object w/ write permission?
  • Mark DeSimoneMark DeSimone 🛠️ 
    edited February 4
    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.
  • edited February 4
    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? 
  • Mark DeSimoneMark DeSimone 🛠️ 
    edited April 2018
    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."
  • edited April 2018
    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.
  • edited April 2018
    I checked my affected user and she has ONLY read access to pages.  
  • edited April 2018
    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.
  • edited April 2018
    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.
  • Mark DeSimoneMark DeSimone 🛠️ 
    edited February 4
    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.
  • edited May 2018
    Wondering if a status could be provided on this investigation.
  • Mark DeSimoneMark DeSimone 🛠️ 
    edited February 4
    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. 


  • Mark DeSimoneMark DeSimone 🛠️ 
    edited February 4
    Thank you for your patience! Skuid has fixed the issue in which Skuid Page Viewers would "inaccessible field" Skuid error, but shouldn't (issue CORE-1789) in the new 11.2.2 release which is now available on the Skuid Releases page.


    As a reminder, Salesforce does NOT allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment. We also recommend that you update out of date themes when you upgrade. Please let us know if you continue to encounter any problems with this issue after upgrading.
     
    Thanks again for alerting us of these issues!
  • edited January 2019
    Users were seeing this on their end (not in the builder) when we used a page include
    Updating to Spark (12.0.4.0) fixed the issue.
Sign In or Register to comment.