1

I'm going to take the dev 501 exam in a couple of weeks but I'm having trouble understanding something that I am seeing in videos Apex -> Introduction to Apex slides.

In the Class Syntax: Sharing section there seems to be 2 contradicting statements in regards to "with sharing." Keep in mind this is straight from the Object-Oriented Programming in Apex slide deck, at the 7:00 marker. enter image description here

1) When performing DML operations, the user can only update the records to which he or she has edit-level access.

2) Note that even when you specify the "with sharing" keyword, all CRUD and field-level security restrictions are still ignored.

What? To me this doesn't make any sense and the edit-level access is the same thing as CRUD security restrictions... am I missing something? Thanks in advance.

2 Answers 2

2

It does sound conflicting but basically what they are saying is that if you use with sharing then the sharing rule itself must be read/write in order to update the record. This is separate from having edit access to the object itself or the field itself.

From the docs here:

Sharing rules are distinct from object-level and field-level permissions. They can coexist. If sharing rules are defined in Salesforce, you can enforce them at the class level by declaring the class with the with sharing keyword. For more information, see Using the with sharing or without sharing Keywords. If you call the sObject describe result and field describe result access control methods, the verification of object and field-level permissions is performed in addition to the sharing rules that are in effect. Sometimes, the access level granted by a sharing rule could conflict with an object-level or field-level permission.

An example would be that if I share an account record and give you read/write access, but at the object level you did not have edit access then in the UI you would not be able to update the shared account record. However, in apex you would unless you enforced them yourself in the code like the same doc explains here:

Although Apex doesn't enforce object-level and field-level permissions by default, you can enforce these permissions in your code by explicitly calling the sObject describe result methods (of Schema.DescribeSObjectResult) and the field describe result methods (of Schema.DescribeFieldResult) that check the current user's access permission levels. In this way, you can verify if the current user has the necessary permissions, and only if he or she has sufficient permissions, you can then perform a specific DML operation or a query.

For example, you can call the isAccessible, isCreateable, or isUpdateable methods of Schema.DescribeSObjectResult to verify whether the current user has read, create, or update access to an sObject, respectively. Similarly, Schema.DescribeFieldResult exposes these access control methods that you can call to check the current user's read, create, or update access for a field. In addition, you can call the isDeletable method provided by Schema.DescribeSObjectResult to check if the current user has permission to delete a specific sObject.

2

Giving you an example:

You have a iPhone but I am the owner of the iphone but I have given you privilege to use the iPhone. So, it is shared with you.

OR

You have a iPhone and it is yours so you can always use it freely.

OR

There are millions of iPhone owners but you have access to yours and mine iphone only.

Above is the "with sharing". It allows you to see the record (iPhone) only which you have privilege to see.

Now what you can do with it? It is defined by CRUD as:

I don't have given you the privilege to use some certain apps of my Iphone. Even though you have access to iphone, you cannot access to all things of my iphone because they are locked.

OR

iPhone company has not given you the permission to uninstall itunes and safari. So, it is a restriction. Even though its your iPhone but you can not do all things.

Above is the example of CRUD, you have the record but you cannot edit or see or empty some fields values. Because they are set by profile.

So having an iphone is a deal but what you can do with the iphone is a different deal. Similarly, having access to record is different than what you can do with record. Providing the access to record (with sharing) doesn't mean that you can do every thing with its fields (CRUD). This is how "with sharing" and "CRUD" works.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .