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
TScottTScott 

AccountShare referenced in Apex Code, so we cannot edit ANY org-wide sharing defaults!

We have an Apex class that updates the Account sharing rules. Since we implemented this class, we cannot update any org-wide sharing defaults via the native UI. We receive this error that appears below "Default Account, Contact, and Asset Access":


Error: Unable to change sharing model because sharing objects are referenced in the following Apex code. Apex Class: UpdateAccountTeam


I don't understand why it would restrict changing any and all org-wide defaults (a bug??). Does anyone have insight into this business rule or any crafty workarounds?

Thanks. -Tom
Best Answer chosen by Admin (Salesforce Developers) 
J_CJ_C

A bit of an old thread, but there is answer to this (I ran into the same problem).

 

The share objects can be volatile, in other words, changing the sharing model may make them disappear.

 

Salesforce will prevent you from changing the sharing model in these circumstances, your code might break as a result of a change to the sharing model.

 

The solution is to avoid making any direct references to these objects, for example, if you are creating a list from a query on a sharing object, make sure that the type in the list is of type SObject, instead of the sharing type, build your query dynamically and pass the object name as a String.

 

Make sure to wrap it in a try catch block to avoid issues if the object disppears, you must handle that possibility in your code

 

Message Edited by J_C on 10-16-2009 09:27 AM

Message Edited by J_C on 10-27-2009 02:50 AM

All Answers

A_SmithA_Smith
Hi Tom,

This restriction was put into place to prevent apex code from trying to write account shares with an invalid access level.  For instance, if your org-wide default is Read Only, then writing an account share using the access level "Read Only" would fail. 

As a workaround, if you need to raise your org-wide default on accounts, you can create an account sharing rule using the public group "Entire Organization".  This is a system maintained group that contains all of the users in your organization.

Thanks,
Andrew
TScottTScott
Thanks for the response Andrew. I can understand the restrictions around the AccountShare. However, we aren't able to even change the default access level for custom objects because of this restriction. E.g. we have a new custom object that is currently set to Public Read/Write and we would like to change it to Private. We edit, change *only* that access level and try to save, but the error appears next to Account, Contract, and Asset Access. It seems to think that we're trying to change the access level for Account, but we are not. Should this restriction really stop us from changing any and all access levels just because we're using one sharing object in Apex code?
A_SmithA_Smith
Do you have code that refernces the custom object or custom object's share table?
TScottTScott
Nope, AccountShare is the only share object that we are referencing in our Apex Code. If we comment out the AccountShare stuff, we can change the org-wide defaults again.

NOTE: Our Account access level is currently set to Public Read Only.

Thanks. -Tom
J_CJ_C

A bit of an old thread, but there is answer to this (I ran into the same problem).

 

The share objects can be volatile, in other words, changing the sharing model may make them disappear.

 

Salesforce will prevent you from changing the sharing model in these circumstances, your code might break as a result of a change to the sharing model.

 

The solution is to avoid making any direct references to these objects, for example, if you are creating a list from a query on a sharing object, make sure that the type in the list is of type SObject, instead of the sharing type, build your query dynamically and pass the object name as a String.

 

Make sure to wrap it in a try catch block to avoid issues if the object disppears, you must handle that possibility in your code

 

Message Edited by J_C on 10-16-2009 09:27 AM

Message Edited by J_C on 10-27-2009 02:50 AM
This was selected as the best answer