Record Security Issue??

I’m getting a really strange issue where a user is able to query a record and successfully save it in from a skuid table when they don’t even have access.

Is there some without sharing setting I’m unaware of? This seems very dangerous.

Record on page:

Proof of non access:

That’s an OpportunityShare record. Why do you have that in a table?

It’s a task. Not an Opportunityshare (that’s 00t as opposed to my 00T). It’s for a task list I’m making for sales reps.

Jumping Jeepers! That is really strange. 

Could you provide more detail? We’d like to see how to reproduce this issue on our end. Do you have any XML you could paste and share what your security settings are in SF? Perhaps even a video…


I made a video showcasing the issue:

Here’s the XML:

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="false" useviewportmeta="true" showheader="false">    <models>
        <model id="TaskList_UserMadeTasks" limit="50" query="true" createrowifnonefound="false" datasource="salesforce" type="" sobject="Task">
                <field id="Subject"/>
                <field id="Id"/>
                <field id="workflowstimulator__c"/>
            <conditions logic="(1 or 2) and 3">
                <condition type="fieldvalue" value="true" enclosevalueinquotes="false" field="NotIsAutoTask__c"/>
                <condition type="fieldvalue" value="true" enclosevalueinquotes="false" field="NotCompleted__c"/>
                <condition type="fieldvalue" value="Lead" enclosevalueinquotes="true" field="Who.Type" operator="!="/>
        <skootable showconditions="true" showsavecancel="true" showerrorsinline="true" searchmethod="server" searchbox="true" showexportbuttons="false" pagesize="10" createrecords="true" model="TaskList_UserMadeTasks" buttonposition="" mode="read" allowcolumnreordering="true" uniqueid="sk-3y9jGj-146">
                <field id="Subject" hideable="true" uniqueid="fi-3y9ku3-159"/>
                <field type="COMBO" hideable="true" uniqueid="fi-2Kv9M-140" valuehalign="" allowhtml="true">
                    <label>Template Field</label>
                    <template>&amp;lt;a href="/{{{Id}}}"&amp;gt;Task Link&amp;lt;/a&amp;gt;</template>
                <field id="Id" hideable="true" uniqueid="fi-3y9ku3-160" valuehalign="" type=""/>
                <action type="edit"/>
                <action type="delete"/>
            <massactions usefirstitemasdefault="true">
                <action type="massupdate"/>
                <action type="massdelete"/>
                <view type="standard"/>
        <styleitem type="background" bgtype="none"/>


Activities in Salesforce aren’t ‘truly’ private.  You still have read access to an Activity if you can see the WhoId or WhatId the activity is linked to.  I think this applies in your situation.



Thanks for the reply Bill. I don’t think that’s the issue here.

The video shows there is no WhoId, and the user doesn’t have access to the object so they can’t have access to the WhatId. Additionally, if they had access to the record, why would UserRecordAccess show HasReadAccess as false, and why would the user be unable to access the task from the standard user interface (in video as well) but able to access the task from skuid?


I failed to ‘RTFM’ (watch) the video.  This does seem like a bug in Skuid.

One thing I was wondering is when you are logged in as the user and using Workbench were you able to query on the Task table using the task id?

Best regards,


Ha no problem. I wasn’t logged in as the user when I was using workbench (I don’t actually have their password). I was logged in as myself.

But that’s a good idea. I’ll see if I can check that later today.

Thank you providing this. We’re doing our best to look into it now.

Thanks for your patience with this problem. This is the kind of thing that would have my eyebrow raised and my gut feeling knotted.

Skuid respects all security rules set by salesforce. We simply run the APIs provided by salesforce. We have no capacity to bypass their security models. Whatever the error is, it’ll be odd if it is coming from the skuid side of things. That said, we won’t point fingers until we have some data to work with.

We’d like you to try and conduct the same experiment off of skuid. When you see the problem arise, open the console and type in then pull up the SOQL statement. Copy it. Open up the developer console in salesforce, enter the query editor, paste what was copied. See if the results are the same. If they are the same, this is definitely a salesforce issue and you should immediately move to open a case with their technical support. If they are different then it might be a skuid problem.

This test is dense and code-y. If you’d like, we’d be happy to go into your org and test it to see. We certainly want to make sure Skuid is on 100% lock down in all departments security related. We’d prefer to run the test as well. Two sets of eyes are better than one. If that is the case, let me know and we’ll complete that step via email rather than community.

Thanks Stephen,

How do you suppose I test the query? The user in question doesn’t have access to the admin console (which requires Author Apex permission, which requires Modify All permission which required View All permission which would invalidate our test :P)

Check your email

Check your email