1

I am creating Apex triggers that automatically create share rules in which access is given to a Group when a "child" record is linked to a "parent" record via a Master-Detail/Master-Detail junction record. The share rule is created on the "child" object when a new junction record is created. Without going in to too much detail about the application, exactly what type of share rule is created is controlled by a Custom Setting - the trigger looks to the Custom Setting to lookup the "child" sObject for which the share rule will be created, to define what access level to provide in the share rule (i.e., "Read" or "Edit"), and to specify the Row Cause for the share rule (which can be one of multiple Apex Sharing Reasons that already exist on the "child" sObject).

I want to be able to validate the contents of each dataset row to make sure that a valid sObject API Name is provided, to make sure that the access level is either "Read" or "Edit", and to make sure that the provided Apex Sharing Reason represents a valid Apex Sharing Reason for the sObject identified by the sObject API Name. I already know how to validate that the provided Text value for the Custom Setting sObject Name field represents a valid sObject Name in the Org. And checking for a Text value of either "Read" or "Edit" is easy. But I want to make sure that the provided Text value for the Apex Sharing Reason represents a valid Apex Sharing Reason API Name.

One obvious solution would be to compare the provided Text value to a hard-coded list of Apex Sharing Reason API Names in the Org, but my ultimate goal for this application is to allow a System Administrator to create a new Apex Sharing Reason for the "child" sObject and then be able to quickly create new Custom Setting dataset for the "child" sObject and new Apex Sharing Reason combination and then have the Apex code automatically take care of everything else. However, this solution is dependent upon the System Administrator correctly typing in the sObject API Name and Apex Sharing Reason API Name values when the dataset is created.

So this leads me to my question that is in the title of this post. Is there a way to programmatically retrieve a list of all of the Apex Sharing Reasons for a particular Custom sObject using Apex so I can compare the supplied Text String to the list of valid values retrieved? I scanned through the DescribeSObjectResult Instance Methods and did not see anything there. I was thinking that perhaps there would be a way to introspect the sObject__Share object that is automatically created when the "child" sObject's default Sharing Setting is set to Private or Public Read-Only, but I could not figure out how to use the available DescribeSObjectResult Instance Methods to retrieve an enumeration of all of the Apex Sharing Reason Names.

The only other idea I came up with for validating a provided Apex Sharing Reason API Name in a Custom Setting dataset would be to create a "child" sObject record in Apex code and then create an sObject__Share record for that sObject record using the supplied Apex Sharing Reason API Name wrapped in a try/catch/finally block. If an Exception is not caught, then I know the supplied Apex Sharing Reason API Name is valid. I could then delete the temporary sObject__Share and sObject records in the finally clause. This proposed solution is not very elegant, though (mostly because of all of the wasted DML operations needed to validate each Custom Setting dataset), which is why I would like to see if there is some way to retrieve a List of all of the Apex Sharing Reason API Names for a particular sObject.

  • Welcome to the community! Please try to post the exact problem you are facing so that contributors can help you easily. – highfive Apr 17 '14 at 4:09
1

RowCause is considered an SObjectField of type Picklist. You can enumerate the values with:

Map<String, String> values = new Map<String, String>();

for(PicklistEntry value: Schema.Object__Share.RowCause.getDescribe().getPicklistValues()) {
    values.put(value.getLabel(), value.getValue());
}

This includes standard share reasons, such as "Owner" or "Sharing Rule", and custom share reasons, such as "Account Manager" or "Secret Spy Guy." You can invert the map if you want to go the other direction as well. It really depends on your use case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.