5

One of the most common use cases not supported by sharing rules is when we have a lookup field to the user object and whomever is selected in the lookup field will automatically get read/write access to the record.

Can we design a reusable code/trigger to do this? Its one of the most common things that we had to create a trigger for.

More information on creating a trigger: http://wiki.developerforce.com/page/Using_Apex_Managed_Sharing_to_Create_Custom_Record_Sharing_Logic

I've had some success using the following code:

LeadShare leadShare = new LeadShare();
leadShare.ParentId = '00QC00000121LCI';
leadShare.UserOrGroupId = '005C0000003N5lT';
leadShare.AccessLevel = 'edit';
insert leadShare;

Here are some of my considerations: - How can we get the different rowCause from Apex? - How can we determine if the OBJECTNAME__Share is available?

Feel free to share other information that need to be considered. Thanks!

Improve this question
1

1 Answer 1

Reset to default
10

Just tried this with an object called Test, with a Reason also called Test. Hope this helps!

Schema.SObjectType testShareType = Schema.getGlobalDescribe().get('Test__Share');
SObject testShare = testShareType.newSObject();
testShare.put('ParentId', 'a00G00000099pyM');
testShare.put('UserOrGroupId', UserInfo.getUserId());
testShare.put('AccessLevel', 'Read');
testShare.put('RowCause', 'Test__c');
insert testShare;

If the object does not have a sharing object 'testShareType' in the example above will be null.

Improve this answer
5
  • 5
    You'd prolly need a try catch around checking the existence of the Share table, as this will be available only if the Sharing Model for the object is Private. Don think there is a describe route to query the object sharing model.
    – techtrekker
    Oct 23, 2012 at 11:40
  • Yeah did have a look for describe, much like the Chatter enablement, sadly nothing as you say. I also tested with an object without Sharing Model set to private and got a null rather than exception, so he should be good checking for that.
    – Andrew Fawcett
    Oct 23, 2012 at 11:55
  • I guess we will just have to hardcode it for the standard objects right? Like in this case its using LeadId instead pf ParentId and LeadAccessLevel instead of AccessLevel.
    – Joey Chan
    Oct 23, 2012 at 12:03
  • Ah another good old design difference with Standard objects vs Custom objects! :-) Well you can determine via Describe (see Schema.DescribeSObjectResult.isCustom method) if the object is standard or custom. Then from that, providing Salesforce have mangled the field names consistently, mangle the field names based on the Standard object name.
    – Andrew Fawcett
    Oct 23, 2012 at 12:25
  • Thanks Andrew! I'm considering a product that addresses the limitation that we have in terms of sharing rules to a specific user or a lookup field in any record. Your answer definitely helps!
    – Joey Chan
    Oct 24, 2012 at 6:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .