[SalesForce] Code without sharing information

Part 1

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.

2. 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.

3. 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.

4. Correct. Extensions are basically a rewrite of the original class plus additional code, so they behave like the original class, including its sharing mode.

5. 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

1. Correct, as per 4 above.

2. Correct, as per 5 above.

3. Correct, as per 5 above.

4. Correct, as per 4 above.

5. Incorrect, as per 3 above. Because A has "with sharing", C will have "with sharing" when called from A.

6. 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.

The system context is not just about sharing. From the docs:

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.

setting a class to run "with sharing" tells Apex to apply the current sharing rules for the current user, but field level security, object permissions etc still don't get applied. The class doesn't run in user mode though - only standard controllers or code run via execute anonymous run in user mode.

If you have a controller class without sharing that causes a trigger to be fired, the trigger will still run in the system context (i.e. no sharing, FLS, object security). If you need to respect sharing your trigger will need to delegate to a class declared as 'with sharing'.

There's a blog post from Abhinav Gupta that covers some of this, although its coming from the other side and explaining how delegating to a 'with sharing' class takes a trigger out of full system context:

http://www.tgerm.com/2011/03/trigger-insufficient-access-cross.html

Guest site user is a slightly different situation, in that some of its ability to access objects is constrained by the user license. I've hit the issue where I was trying to update something that the guest user profile should only have read/create permission on, so I thought I'd get around it using a custom controller (running in the system context). This had worked for me for contacts, but for another standard object I received an error that the license didn't support the operation. The license issue persisted even if I executed the update from an @future method. So no, I wouldn't expect it to have as much clout as the system administrator, although actions that should be prohibited by the license may sometimes work.