[SalesForce] Does it matter to have classes with `sharing`

When I create classes, I've seen that there's an option to have create the class with or without sharing.

Example:

public class with sharing myClass{
    //  awesomeness
}

I've read the documentation, but what are the "sharing rules" enforced if I set my class to be with sharing? What's the extra benefit of having a class with (or without) sharing compared to classes without this specified?

I don't use sharing classes currently because (1) I'm uniformed and (2) I'm leary I will create code that won't work as I expect it. And I feel like I may be missing something useful by ignoring this functionality.

Update:

Right now, I don't use the with sharing property with my classes, and if a user's profile doesn't have ample field-level security settings, then the data isn't displayed. It seems that there already is security in place — we use Sites extensively, and I have to manually give Site profiles permissions to view/use fields, objects, classes and pages. Is with sharing necessary? I don't use it now, and I still have to give permissions anyways, so what's the point? It seems to be a redundant security feature.

Are there any reasons why I should be using with sharing? Or my fears that I am doing things wrong unfounded?

Best Answer

To understand the implications to an apex class of with/without sharing first you need to understand how salesforce's security model works. It really consists of three layers of security:

CRUD (Create,Read,Update,Delete), or table-level access. This is defined on the profile/permission set.
FLS (Field level security), or column-level access. Also defined on profile/permission set.
Sharing, or row-level access. This is much more complex and is based in large part on the configuration of your org.

CRUD is automatically enforced by standard controllers, if you make use of them. FLS is automatically enforced by the apex:inputField and apex:outputField tags, if you make use of them.

Sharing is enforced at the class level based on this keyword.

But what exactly is sharing?

It depends in large part upon you organization-level defaults. By default in new orgs most objects are set to public read/write, which disables sharing for that table until changed. This means that out of the box with/without sharing often won't have much an impact.

However once you do turn "on" sharing by changing this setting to something more restrictive you'll find that sharing is a complex calculation that's done by checking the role hierarchy, record ownership, apex-created sharing rules, point-and-click defined sharing rules, and even manual shares created by hand on a per-record basis.

The net effect of this is that sharing is much, much more complex to calculate than CRUD/FLS (which have simple apex methods for "can I do this?"), so this class-level control on sharing was introduced. If a class is defined as "with sharing" then the system will automatically enforce sharing on all queries you run, and DML you perform.

If your user only had read-level access to Account "X" and you try and update a field on it then "with sharing" would fail, but "without sharing" would succeed. The UI would fail in this scenario, and prevent the user from editing the record, so "with sharing" is a consistent experience for the user here.

If you leave off the sharing declaration then the class will inherit it's with/without sharing from whatever calls it. this is quite useful for helper classes with only static methods, if you leave off the sharing declaration then whatever calls these methods will determine if they respect sharing or not. If a class with no sharing declared is the top-level in a request (e.g. a visualforce page controller) then it will default to acting "without sharing".

Edit: Except when using execute anonymous, where it will behave as "with sharing".

Part 1

Correct. You cannot "automatically" enforce field level security or profile permissions with "with sharing," as this would make code much more difficult to debug because of failures. This is noted in Using the with sharing or without sharing Keywords, under the second note.
Correct. This means that if do not specify "with sharing" or "without sharing" for the inner class, it behaves according to the calling class mode, or "without sharing" if called directly, except as noted in the first section of the link provided above.
Partially correct. If you run a class that has no sharing in Execute Anonymous, or in Chatter, it is treated as "with sharing." In all other cases, it is treated as "without sharing." For most cases, this is not significant, but you should be aware of this feature.
Correct. Extensions are basically a rewrite of the original class plus additional code, so they behave like the original class, including its sharing mode.
Correct. Calling a function in a class will use the sharing mode of that class, unless it is undefined, in which case the mode stays the same.

Part 2

Correct, as per 4 above.
Correct, as per 5 above.
Correct, as per 5 above.
Correct, as per 4 above.
Incorrect, as per 3 above. Because A has "with sharing", C will have "with sharing" when called from A.
Partially correct, or incorrect, depending on the exact definition of A. If A is "public with sharing class A extends C", then it is "with sharing," or if it is "public class A extends C", then it falls under item 3 from part 1 (that is, "without sharing unless executed from executeAnonymous").

With Sharing

This is when you're trying to perform an update as the user. If user X cannot edit record Y, then an error will occur. If user X cannot see record Y, they cannot query that record. Use this mode when for pages that should respect sharing settings, or any other time you might want to enforce the rules.

For example, a page that edits opportunities should probably enforce sharing to make sure that users can't modify other users' sales data without the appropriate sharing in place. For Visualforce pages, this is true approximately 99% of the time. Some Visualforce pages might be able to circumvent sharing, for example, to show data that the user wouldn't normally. A page that can tell users that a possible duplicate lead exists (without exposing who works the lead, or specific details) would not want to use "with sharing" in a private data model.

Without Sharing

This is when you're trying to perform an update that should not fail ordinarily. For example, a logging system is designed to write certain non-fatal messages to a logging object. The user doesn't have any right to edit the logging files normally (OWD is private, and the logging records are owned by a system administrator), but the logging files need to be queried and updated accordingly (to save space, etc). Using "with sharing" would make this code impossible, but by placing that code in a "without sharing" class, the code can make logs on behalf of the user even though that user has no access to the object normally. As another example, users can't see others leads, but the system needs to flag potential duplicates and notify someone that there is a duplicate. "Without sharing" makes this code possible.

[SalesForce] Sharing rules and Inner classes

From the documentation, two critical rules:

Inner classes do not inherit the sharing setting from their container class.

Classes inherit this setting from a parent class when one class extends or implements another.

And when no sharing model is declared or inherited,

If a class isn’t declared as either with or without sharing, the current sharing rules remain in effect. This means that the class doesn’t enforce sharing rules except if [...] the class is called by another class that has sharing enforced.

So here we have a, with sharing, calling a method on the inner class b.c, which does not declare a sharing model. Since inner classes do not inherit sharing, and b.c has no superclass, it will acquire a with sharing context from the calling class, a.

If, rather than being an inner class, c were a subclass of b:

public virtual without sharing class b {
}

public class c extends b {
    public static Integer testing() {
      return 5;
    }
}

here, c would in fact be a without sharing class, because it inherits that declaration from its superclass - and this would apply regardless of who called c.testing().

Best Answer

Related Solutions

[SalesForce] SFDC: Understanding With Sharing, Without Sharing & Unspecified Sharing Classes

Part 1

Part 2

With Sharing

Without Sharing

[SalesForce] Sharing rules and Inner classes

Related Topic