function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Edward GeeEdward Gee 

Getting user permissions at the instance level via API

Is there a way, from an API standpoint, to determine whether a user has the ability to update/edit a particular instance of an object?  As the documentation describes, you can enable security at the object level but also at the instance level using territory management and/or sharing rules.  We tried using the MayEdit field but discovered later that this is not a standard field found on all Salesforce orgs (some of our older customers do not have this field exposed at all).  I tried reverse engineering the process by querying the respective "Share" table, if it existed, and the Group, UserTerritory tables.  Unfortunately there are some pieces of information I could not retrieve that would aid in my search.  For instance, I couldn't find a way, via API, to determine what sharing model (Private, Public Read/Write, Public Read Only) a customer applied to an object.  Is this information queryable/retrievable  somewhere?  DescribeSObject only gives object level permissions.  Anyways, if anyone has some insight on this topic, I would like to hear from you.

- Ed
SuperfellSuperfell
Like many security systems, the best way to workout if you can do something is to try and do it. There's no way to obtain beforehand if a particular CRUD operation is valid for a given row.
Edward GeeEdward Gee
Since we're building our own UI for the object (and its children), I would like to prevent wasting the end user's time of filling out a form and saving it only to find out later they don't have access to modify the object.  So instead of providing them an "Edit" link all the time (and confusing the user), I would rather hide the link from the user if they don't have permissions to modify that instance.

- Ed
JBallJBall
i agree, it's bad form to let users spend time editing records they don't have permission to edit. it's a big inhibition to using sfdc as a back-end on a custom front end. i'm running into this same problem. to solve the problem of subordinate users on a role tree being unable to select parent objects created by users above them, we've set the object's permissions to public read.  but now we're unable to establish which records any given user should be able to edit.  our options appear to be either: switching back to a private model and logging in with a superuser to pull a list of parent objects available, pulling a list of user-accessible records using the current user's login, and finally doing all create & edit calls on the child objects with the superuser; or doing an immediate update call on all pulled records and using the returned errors to establish what records in the display list the user cannot edit.

the problems with both solutions should be apparent.  in the first, there's no accountability, and the read-only objects the user call pulled can still be updated, because all calls are made with a superuser.  in the second, we can't establish permissions on the data being displayed until the second call has been processed, a call where we're intentionally generating errors!

while i've never heard of a mayEdit field, it's certainly a nice idea, especially since it would allow query criteria to be very specific to what's desired.  if you want just records the user can edit, there it is! barring that, an api call that would allow a permissions check for a list of record id's would be good.
pberniepbernie
yeah I have to agree that "try and see" isn't a solution. I'd really like to see an API available to at least determine the permissions a user has on a particular object.
AviAAviA

Hello All,

I'm facing with the same problem now... Does anyone know whether SF found solution for this problem?

 

Basically indeed we have two options, but none of them not elegant and very complicated:

- The first option is the "Try and See" option, i.e. update all the records we retrieve and separate between them according to the error response we got --> Absolutely not an elegant option and it damage our reports because it will change the LastModifyBy/Date fields.

 

- The second option is to simulate SF security mechanism per each record, which is very complicated since we need to count on the object_Share__c data which includes groups & users (recursively) and their are a lot of exceptions such as "Modify All" permission Etc.

 

It's really weird that SF not provides solution to this problem, the desired solution will be to retrieve records with direct information about the user permission according to a specific record (which user? the one that made the API call of course).

 

Any piece of information will help,

Thanks in advance,

Avi.
SuperfellSuperfell

There have been no changes related to this.
Abhay PimprikarAbhay Pimprikar

Hi Is there any update on this issue? Is the MayEdit flag more reliable now? 

 

Thanks

Abhay