I am just getting started with SKUID, and am mostly involved in helping the project SKUID team with SFDC security model issues. The team wanted to conditionally render a button and based on their description of what they wanted I recommended something like the SOQL below:
SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel
FROM UserRecordAccess
WHERE UserId = ‘005J0000002Wc99’ AND RecordId = ‘001J000001VLJe2IAH’
The team tried the above SOQL and said that it didn’t work because “in Skuid by default the “Id” field is getting populated in the select query and because of that we are getting error.”
I take this to mean that SKUID is automagically adding the ID field to the query. This is a problem since there is not an ID field in the UserRecordAccess object.
Does this description make sense? And if it does is there a workaround?
Thanks!
Very interesting! UserRecordAccess is unique in that it’s the only object I’ve ever encountered that will not work if any other fields other than “RecordId, a Has*Access field, and MaxAccessLevel” is included in the SOQL.
Skuid has made the Id field a default field in their Model architecture. I wouldn’t of thought of that ever being an issue, but I stand corrected.
What’s more interesting is that the option is there to “not” select the Id field for the model. Quite misleading to me, but I can understand how the decision was made to always include by default. I don’t think anyone’s ever tried to use this object on a Skuid page, and adding the Id field by default makes Models that much more quick to use and less prone to issues.
I suppose it’s appropriate to ask for a tweak to the Models: auto select the Id field but let the user unselect it.
Another odd thing.
The field with the label of “Record ID” doesn’t have the API name of “Id”. Every other place I’ve seen a field with the label “Record ID” it did have “ID” for it’s API name.
I wonder why salesforce decided on these fields labels and names. Better yet, why is it not possible to query anything other than “RecordId, a Has*Access field, and MaxAccessLevel”.
At this point, UserRecordAccess is one of those objects that Salesforce will not let us query. There are a few of them (Combined Attachments and Activity History are two that come to mind). I don’t think Skuid will stop automatically trying to grab the ID field in its models - since it is needed on about 99% of cases.
Sorry about that…
I can query the UserRecordAccess object in Developer Console. I get why Id is auto added, but I still think it should be optional. An “Advanced” setting maybe so it’s not so easy to mess up models for the other 99% of the objects.
Skuid depends on the Id field being there for just about everything it does. Although it would be possible to make this work in a future release of Skuid, it would be a bit more involved than just an option to remove the Id from the SOQL query.
Seems to me that the SOQL query being generated has all the fields selected in the model appended together with a comma delimiting them, and then “,Id” appended to this.
When creating the query, can you not add an IF statement to look at the model value for “Include Id” being True in order to add “,Id”?
Rob - Thanks for your feedback.
Sooo - I gather editing the SOQL in the XML generated by SKUID is not doable. I suppose I can write a webservice that I call from some javascript behind a button, but that is work that I’d like to avoid if at all possible given that we’re talking about multiple rows in a list (table? in SKUID-speak).
Taking a step back, I got started down this path because we want to display the Edit and/or Delete buttons or images on a SKUID page or table only when the user has Edit and/or Delete on the record in question. Since the UserRecordAccess rabbit hole appears to be deeper than anticipated - any thoughts on how we solve the above problem?
I think you will have to go back to the data that is used by Criteria based sharing rules and build your rendering based on those values. But if you are using role based sharing, or manual sharing - I don’t think there is a good solution.
We ended up coding up a web service to do this; now we’re having a problem calling the web service from SKUID 
. We’ll either get the problem sorted out or convert this to a @RemoteAction but either way we are on track to solve the overall problem.
Thanks!
