In the code below, keep this in mind:
Joe -> Jane -> Mike -> Mary
In our org, the sensitive records that require Private org wide defaults give record owner's read-write access by virtue of their ownership of the record. For all others to have read access, we have to create sharing records for the object.
A share is composed of the following elements:
- ParentId - the record that you want to share with others
- RowCause - the custom reason you are sharing this record
- AccessLevel - the level of access being given (in our ex: read)
- UserOrGroupId - the user (or group) who should have access
By creating a record with these required elements, these private records can be shared with those users (or groups) mentioned in the shares.
Programmatically, it is pretty easy to create a trigger on an object and create a related share for the object's owner. Salesforce's documentation of apex managed sharing does an adequate job of this. Where I scratched my head a little was figuring out how to share all the way up the hierarchy. And do the sharing without hitting any governor limits. I did some searching of blogs and found an interesting post by Jeff Douglas. Jeff's solution is elegant, but I wanted to try another way myself. In plain english here is what I wanted to do:
1. Create an object share record for the record's owner's manager
2. Then, create another object share for that manager's manager
3. and so on...
4. Insert list of object share records
It felt like a loop to me, so what I tried initially was to iterate through the object share collection, and for each record in the collection, create another share record, assign the manager, then add it to the collection and continue until a manager is no longer found for the user. In this snippet, the collection of all users and their managers is held in a map:
for(User u: [Select u.Id,u.ManagerId from User u])
{
mapUserManagers.put(u.Id,u.ManagerId);
}
for(someObject__Share os: sharesToCreate)
{
if(mapUserManagers.get(os.UserOrGroupId) != null)
{
someObject__Share os_mgr = new someObject__Share ();
os_mgr.AccessLevel = MGR_ACCESS;
os_mgr.ParentId = es_mgr.ParentId;
os_mgr.RowCause = MGR_ROW_CAUSE;
os_mgr.UserOrGroupId = mapUserManagers.get(os_mgr.UserOrGroupId);
sharesToCreate.add(os_mgr);
}
}
This approach throws an error: "Cannot Modify a Collection While It Is Being Iterated"
Some folks over at stackexchange explain the issue with the index behind this loop.
So, I took a slightly different approach to the loop:
allUsers = [Select u.Id,u.ManagerId from User u];
for(User u: allUsers)
{
mapUserManagers.put(u.Id,u.ManagerId);
}
Id managerId;
for(SomeObject__c so: RecsToProcess)
{
managerId = mapUserManagers.get(so.OwnerId);
do{
SomeObject__Share sos = new SomeObject__Share ();
sos.AccessLevel = SHARE_MGR_ACCESS;
sos.ParentId = so.Id;
sos.RowCause = SHARE_MGR_ROW_CAUSE;
sos.UserOrGroupId = managerId;
sharesToCreate.add(sos);
managerId = mapUserManagers.get(managerId);
} while (managerId !=null);
}
//allow for partial successes
Database.SaveResult[] srList = Database.insert(sharesToCreate, false);
This compiles without issue and achieves the effect of creating a collection of share records for each of the managers with only 1 SOQL call. It's another way to solve the hierarchy loop challenge. Hope it helps you find a solution to your own problem.