Switch to Inherited Sharing on SObjectDescribe and SObjectSelector

[jeffolmstead]

First, thanks for the fantastic platform. The problem initiating this request appeared when I implemented a Selector for my custom object. I had the need to use "Elevated Context" (i.e. 'without sharing') but no matter what I did, I could not get a user to be able to query a record that they didn't have direct access to. It finally hit me that there must be a lower level class that was using 'with sharing' such that my 'without sharing' was being ignored.

I looked through all the Apex classes that come with your solution and noted the following classes are set to 'with sharing' or not indicated either way. For my case, and I believe for others as well, it would seem best to have these classes explicitly use 'inherited sharing' so it is clear that the sharing settings will be done elsewhere (and to allow for elevated context in parent classes).

• fflib_QueryFactory [add 'inherited sharing']
• fflib_SecurityUtils [add 'inherited sharing']
• fflib_SObjectDescribe [switch 'with sharing' to 'inherited sharing']
• fflib_SObjectDomain [switch 'with sharing' to 'inherited sharing']
• fflib_SObjectSelector [switch 'with sharing' to 'inherited sharing']

The remainder of the files are explicit with their use of 'with sharing'. Welcome feedback if this is a 'bad move' and, if applicable, am wondering if this can be made part of native package. Thanks for your consideration!

[daveespo]

Backwards compatibility is a heavy cross that this project needs to bear. We can't change the sharing clauses on existing classes (notably the ones that are declared with sharing need to remain that way)

There is some interesting commentary on #199 and #262 -- we introduced a backwards-compatible way to work around the with sharing declaration on fflib_SObjectSelector

Having said all that, we believe that sharing clauses are in the rear view mirror. With the introduction of User Mode in #419, you can now explicitly control CRUD/FLS/Sharing enforcement via arguments to the constructor of fflib_SObjectSelector. This makes the behavior of the Selector much easier to reason about versus trying to trace through execution paths to determine which stack frame changed the execution context's sharing enforcement. Please consider using the constructor overloads that take DataAccess as an argument for all future work.

[jeffolmstead]

Sorry for delay in getting back to you @daveespo and thanks for your feedback - that makes perfect sense.