Hi Peter, yes, Skuid respects the sharing model as well as the field and object level security rules you put in place. If you were indeed able to get around the security model with Skuid then it would be a bug. We use the apex metadata methods that salesforce provides to determine what access our models have to data. Is the user that you’re seeing this behavior with a on a standard profile? Is it a sharing rule or an object or field level security rule that seems to be broken?

Peter, Sometimes Apex acts like System Admins have permissions that, according to your data model and security settings, you’d think they wouldn’t have — for instance, we’ve seen that Apex sometimes ignores Field Level Security settings for System Admins. However, we have not observed this at all with normal users. So, if the issue you were experiencing was just happening for you, as a System Admin, then I wouldn’t worry about it.

I am using the partner portal, and when I login as a normal portal user and go to a standard tab for a custom object, I can see only the records that I (the logged in user) own. However, when I use a Skuid page I can see and edit any/many records on that object. I’m seeing this with many/all objects. Perhaps I should demo this for you in a screenshare, so feel free to email me directly to work it out.

FYI for reference, we worked this problem out and there were no bugs/problems with Skuid. A redirect in a portal web tab was mistakenly pulling up Skuid pages there by the url “skuid.na14.visual.force.com” instead of the correct “customdomain.secure.force.com”. The result was that when I logged into the portal in the same browser that I was using for configuring Skuid, it was using my enterprise session key to display the pages instead of the portal session key. Quite confusing! My thanks to Ben & Zach for troubleshooting with me.