I have a case record which I have shared with few other users manually. But when owner of the case is changed/assigned to a sales rep then all those sharing goes away and default sharing applies. Has anybody faced similar issue. Any thoughts to resolve?
3 Answers
You can persist them through the use of asynchronous code; basically, we store the state of sharing before the ownership change, then restore it afterwards.
First, we need a utility class for the future method:
public with sharing class Persistence {
@future
public static void persistSharing(String ShareString) {
CaseShare[] reasons = (CaseShare[])JSON.deserialize(shareString, CaseShare[].class);
for(CaseShare reason: reasons)
reason.Id = null;
Database.insert(reasons, false);
}
}
Then, we create a trigger:
trigger CopyShare on Case (before update) {
Set<Id> caseIds = new Set<Id>();
for(Case record: Trigger.new)
if(record.OwnerId != Trigger.oldMap.get(record.Id).OwnerId)
caseIds.add(record.Id);
Persistence.persistSharing(
JSON.serialize(
[SELECT Id, CaseAccessLevel, CaseId, RowCause, UserOrGroupId
FROM CaseShare
WHERE CaseId IN :caseIds AND
RowCause = 'Manual']));
}
Note that we can only back up and restore manual shares. Other types of shares, such as from sharing rules or teams, are managed by the system.
-
Thanks for the reply. Actually I did the same but in after update trigger (synchronous call). But didnt work. Have your tried your solution?– dogaCommented Sep 14, 2013 at 14:29
-
-
one doubt, does future method execute after transaction completes? What is their order of execution?– dogaCommented Sep 14, 2013 at 17:50
-
Future methods execute after the transaction performs its final commit (after sending emails, etc). See Order of Execution– sfdcfox ♦Commented Sep 14, 2013 at 17:58
-
1@PranayJaiswal During my original research, I found that sharing was recalculated some time after the triggers finished running, and as a result, doing anything during the trigger was a pointless exercise because they'd be wiped out. I'm not sure that's true five years later, so I'd have to build a new experiment, but I suspect it still probably works that way.– sfdcfox ♦Commented Jun 29, 2018 at 12:51
Following up with SFDCFox's reponse about when the shares get deleted, I have found that the shares get deleted in between the Before and After contexts, so running the logic for recreating the shares in an After context should allow us to persist the Share records, with manual row cause, in this case.
The response that has been marked as Correct Should be updated to have the the trigger run in the After Update context for clarity.
This isn't the correct way to solve this. You should instead create a custom button that allows you to pick the users you want to share the record with and then insert share records for the case with a custom RowCause. (Define the RowCause) on the Case object before doing this. Once the shares are inserted using a custom rowCause, changing owner will not remove access from the shared users.
Use this for reference:
-
Note the detail: "Apex sharing reasons and Apex managed sharing recalculation are only available for custom objects." So you can't use a custom sharing reason on Case. Commented Jun 29, 2018 at 12:14
-
Am sorry it cant be done for case, or standard object. Am downvoting for being incorrect. Commented Jun 29, 2018 at 13:03
-
This would only work for Custom objects, Standard objects (such as case, account, etc.) do not support apex sharing reasons and so this answer is incorrect in this context. Commented Jul 27, 2021 at 16:43