How does getSObjectType().getDescribe() work in a 'Without Sharing' Class?

Question

I recently run into a problem when I try to check fls within an without sharing class.

Here is what I did:

For the user profile I set CustomObject__c allow delete permission to "False"

public without sharing class TestSharing {

    public static String TestAccess() {
        CustomObject__c c = new CustomObject__c();
        c.CustomField__c = 'abc';
        insert c;

        Schema.DescribeSObjectResult d = c.getSObjectType().getDescribe();

        System.assertEquals(d.isDeletable(),true);
        return null;
    }
}

I am wondering what should d.isDeletable() return if I am running TestSharing.TestAccess()?

I was expecting it to return true (ignoring profile settings), because TestSharing is a without sharing class. However, it seems the value is always false disregarding the class sharing type.

Answer 1

All security-related methods, such as UserRecordAccess and the describe calls, will always return the user's real permissions. All that "without sharing" does is turns off the permission and sharing table checks when querying, updating, or deleting records. It is strongly recommended by salesforce.com that developers check for a user's permission to fields, objects, and records being used when using "without sharing," but there are times when this behavior is desirable, such as logging data to an object the user doesn't have direct access to.

Answer 2

without sharing will not reinforce SFDC field level access and visibility, so you will be running your class on system context.

In system context, Apex code has access to all objects and fields— object permissions, field-level security, sharing rules aren’t applied for the current user. This is to ensure that code won’t fail to run because of hidden fields or objects for a user. The only exceptions to this rule are Apex code that is executed with the executeAnonymous call and Chatter in Apex. executeAnonymous always executes using the full permissions of the current user. For more information on executeAnonymous

So you can see that making those changes will affect your access level to the fields and the visibility. The only exception in on executeAnonymous from you Developer Console and also triggers run on system context.

To find out your attributes for an object you can use the WorkBench Log in with the credentials for the org you are running that code. On the jump to: select : Standard & Custom Objects . Select the object, in this case, the CustomObject__c, you want to check and look under the attribute folder.

Also, your code needs to point to a specific object, like you do on this line CustomObject__c c = new CustomObject__c();. There you will find the Deletable() value.

Pretty sure that it is set to false if the assertEquals is returning false.