Salesforce Certified Sharing and Visibility Designer – Programmatic Sharing Part 4

5. 3.4- Enforcing Object and Field level permissions in Programmatic Apex Sharing

This is section three, Programmatic Sharing, and this lecture is about enforcing object and feedlevel permissions and programmatic solutions. The topics of this lecture are system mode, enforcing object level permissions and Apex classes, enforcing feed level permissions and Apex classes, enabling field and object level permission, checking for Sokol, using the Wiz security enforced keyword, enforcing permissions and VisualForce pages, and enforcing permissions and custom controllers. Before talking about how to enforce object and feed level security, we have to explain about system mode Apex runs in system context.

This means that the current users permissions, feed level security and record access and sharing rules are not taken into account during code execution. What does this mean? Well, imagine that you write an Apex class that has a method that touches all account records using so called. If this method is run by a user that has only access to a subset of accounts records and to certain fields in this account object, then this user will indeed have access to all the accounts records and to all the fields of this account records, which is something that you don’t really want to have.

One more thing to talk about before talking about how to enforce object and field level security is the with sharing keyword. The with sharing keyword on class definition forces the use of the security sharing permissions of the user currently logged in. In the first example, as you can see on the right side, all contact records are returned, even if the currently logged in user does not have access to all the contact records.

But when we add the with sharing keyword, then only the contact records that the logged in user has access to are returned. This keyword only features record access and it does not include feed level security or Crad. Again, we have two classes and two methods. The first class doesn’t have the wish sharing keyword. So if this method of this class is run by a user who does have access to only a subset of the contacts, then this user will see all of the contact records. But if this user is running this method that belongs to a class that has the wish sharing keyword, then this user will only see the contacts that he she has access to.

But now, what about Cred and field level security? What can we do about these? Let’s see next. Now, let’s talk about how to enforce object level permissions or Cred. In Apex classes, you can enforce object level permissions or Cred in the code by explicitly calling the S object Describe result methods. These are methods of the scheme on that describe S object result class.

 These methods check the current user’s object access permissions level. This way you can verify if the current user has the necessary permissions on the object and only if he or she has sufficient permissions. You can then perform a specific operation like a DML operation or a so called query now, what are the details of these methods? What are they? Well, you can call the is accessible, is Createable, Is Updatable and Is deletable method of the schema that describe S object result class to verify whether the current user has read, create, update or delete access to an S object. These are the details of these methods the S accessible method returns true if the current user can see this object force otherwise. The S Createable method returns true if the object can be created by the current user force otherwise. The S updatable method returns true if the object can be updated by the current user force otherwise and the Sdeletable method returns true if the object can be deleted by the current user force otherwise. As you can see, we have four if statements here.

The first will check if you have access to the contact object using the Is accessible method. The second checks if you can create contact records, the third checks if you can update or edit contact records and the last checks if you can delete contact records. The same way we can verify access to objects fields, but this time using methods of the schema that describe field result class. The methods that are used in this case are from the schema that describe field result class and they are as accessible as Creatable and Is updated methods. These are the details of the methods. The S accessible method returns true if the current user can see this field force otherwise.

The S Creatable method returns true if the field can be created by the current user and force otherwise. The S updatable method returns true if the field can be edited by the current user and force otherwise. These are two examples. The first example checks if the user can see the email field of the contact object. If the answer is yes, then the Sock will query can be performed and its return value will be stored in a variable called C. The second example checks if the user can update the phone field of the contact. If the answer is yes, then the equivalent DML operation can be performed.

You can also use the With Security enforce clause to enable field and object level security permissions checking for socalled select queries and Apex code including sub queries and cross object relationships. This keyword applies field and object level security checks only to fields and objects referenced in the selector and the from Sock will closes and not closes like the where or the order by. In other words, security is a force on what the Sock will select query returns, not on all the elements that go into running the query. This is an example. To understand this, the query on the right side is querying two fields the ID field and the website field from the parent of the account.

So if for example a field access for website is hidden so the user who is running this so called query cannot see the website field on the parent record, which is the parent of the account, then this query will throw an exception indicating insufficient permissions. Another example the query on the right side is querying the ID and the two sub queries from two child objects that are contact and opportunity. So if field access for either last name or type is hidden, this query throws an exception indicating insufficient permissions. Now, let’s talk about enforcing permissions in VisualForce pages. VisualForce standard controller gets executed in user mode and not in System Mode, which means that field level security is enforced and fields not accessed through FLS will not be displayed.

For example, if we have a VF page with account as standard controller and the user displaying the VF page does not have permission to access account, then this user will get an error message. On the other hand, and for VisualForce pages that use a custom controller, these custom controllers and additions to controller extension always run in system mode where users permissions are ignored. In system mode, Apex code has access to all objects and fields. Object permissions, field level security sharing rules are not applied for the current user. This is to ensure that code will not fail to run because of hidden fields or objects for a user for custom controllers.

And as we have seen, adding the with sharing keywords on the class definition respects record access, but not object level security or field level security. Note also that some visual force tags enforce Cred and FLS like the Apex output field tag. So if we use these tags, then the FLS will be respected and then the user will not have access to fields that he or she does not have access to. On top of that, manual object and field level security checks using the describe as object result and the described field result class methods can be used.

This is an example of a tag that will enforce feed level security and a VisualForce page. This is the Apex output field tag. As you can see, we have a page block tag and under it we have a page block section tag and then we have a bunch of output field tags. This output field tag will enforce feed level security. This is the corresponding controller. As you can see, the constructor populates the three class variables my Account, My Contact and My Lead using a Socalled query for each. In this example, there is no need to check if the user has access to the field because we are using a tag that would do this for us.

This is the same example. But now instead of using the output field tag, we are using the output text tag which does not enforce feed level security. This is the corresponding controller. This controller follows the exact same structure of the previous one.

The constructor populates the four class variables my account name, my contact name, my contact title and my lead name using a soccer world query for each in this example. And because we are using output text, there is a need to check if the user has access to the field, because output text does not help in this. This is the modified class which is using the schema that describe field result to check. So before each circle assignment to the variable, the controller checks if the user has access to the field in question.

This way we make sure that the variables are not populated if the user does not have access to the field. And that’s it for this lecture. In this lecture, we have talked about how to enforce object and field level security in Apex in general. And of course you can use that when writing Apex classes for sharing records. We started with defining the system mode, which Apex runs on, where the current user’s permission, feed level security record access and sharing rules are not enforced during code execution. The use of the with sharing keyword in a class definition would only enforce record access and not object or feed level security.

We have also talked about methods that we can use to check object and feed level permissions before something like a DML operation or like an insertion for a shared object record. These are from both the Describe s object result and the describe feed result classes. We have also talked about the with security enforced keyword, which can be added to a sockwell query in Apex to enable field and object level security permission checking.

And finally, we have talked about enforcing permissions in a VisualForce page and custom controllers some VisualForce tags, natively enforce object and field level security like the Apex output text. And for the other tags that don’t, the fix is to use the describe field result class methods to check if the user has access to the field. And finally, as usual, thanks for watching you.