As per my knowledge, I dont think this metadata is exposed for Apex usage. The closest I could find, was the Descibe Result's methods, which could tell you the access of the object. These can be used to enforce current users permissions for Objects and Fields
isAccessible
isCreateable
Check these methods if you find them useful for your purpose here -
Other than these, what I can think, is to use Apex managed sharing to insert some test data into the sharing object for the object under consideration and then catching the exceptions appropriately to figure out the org wide setting.
Say like, if the share obj is not available, then OWD is public r/w , if inserting record with read access causes error, then OWD is public r, else its private..
Your post has some content which I believe has been taken from the developer's guide. I have only gone thru that content and did not implement it.
What I was suggesting was different way of exception handling using the try catch statements.
public static method getOWD(String objName){
Savepoint sp = Database.setSavePoint();
Boolean error = false;
// Use global describe to check if Sobject exists with name provided
// if no, then OWD is public r,w
// if yes, then a generalised version of
try{
SObject js = new Job__Share()
// populate fields for your share record here. you could use the sObject.put methods
insert js;
}
catch(Exception ex){
// check the exception contents here to see if OWD is public r
error = true;
}
if( !error)
// OWD is private;
Database.rollback(sp);
}
Your approach is nice but don't you think that not catching a specific exception might end up in wrong results? I hope you are getting my point. Because if error is occured due to some other means and not due to trivial access then it will display wrong results.
Hi,
As per my knowledge, I dont think this metadata is exposed for Apex usage. The closest I could find, was the Descibe Result's methods, which could tell you the access of the object. These can be used to enforce current users permissions for Objects and Fields
isAccessible
isCreateable
Check these methods if you find them useful for your purpose here -
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_sobject_describe.htm
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_fields_describe.htm
Please do share if you find anything else.
Thanks
Agree with Ritika's comment.
If you really need to view this piece of the metadata, you might have to invoke the metadata API using a webservice call.
Not sure if it still works, but check out the thread at :
http://boards.developerforce.com/t5/Apex-Code-Development/Is-it-possible-to-call-Metadata-API-from-Apex-code-Getting-Error/td-p/119412
Other than these, what I can think, is to use Apex managed sharing to insert some test data into the sharing object for the object under consideration and then catching the exceptions appropriately to figure out the org wide setting.
Say like, if the share obj is not available, then OWD is public r/w , if inserting record with read access causes error, then OWD is public r, else its private..
Just some thoughts.. not sure if they can work.
Thanks,
Jerun Jose
Thanks Ritika, Jerun
Jerun,
I tried to catch the exception but it is not working. I've posted seperate post for that
http://boards.developerforce.com/t5/Apex-Code-Development/Apex-managed-sharing/m-p/403115#M72575
Can you please share your way of doing it?
Your post has some content which I believe has been taken from the developer's guide. I have only gone thru that content and did not implement it.
What I was suggesting was different way of exception handling using the try catch statements.
Jerun,
Your approach is nice but don't you think that not catching a specific exception might end up in wrong results? I hope you are getting my point. Because if error is occured due to some other means and not due to trivial access then it will display wrong results.
You are absolutely right Jagdeep.
I just put that to display the format. I really do not know what exception category it will throw.. probably a DMLException.
The way I do it is to debug the exception once, and then know what its contents are.
And then when developing the logic, check for exactly that exception and handling it.