Proposal for integration of native Apex User Mode Operations

[daveespo]

Overview

Salesforce introduced native support for enforcing CRUD, FLS and Sharing within Apex in the Summer '22 release (Beta). It is scheduled to be a GA feature in Spring '23 (Feb 2023).

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_enforce_usermode.htm

The AEP project has always had a robust method for enforcing CRUD and FLS on SOQL (read operations) in fflib_SObjectSelector and has points of extensibility for enforcing CRUD and FLS in DML operations in fflib_SObjectUnitOfWork.

The enforcement of CRUD and FLS on SOQL is computationally expensive and laborious to maintain and understand. The enforcement of CRUD and FLS on DML requires a custom implementation of an fflib_SObjectUnitOfWork.IDML and a third party library (such as DMLManager) to do the heavy lifting.

We want to phase in optional support for the native User Mode Database Operations in AEP.

Background

As most Apex developers know, Apex always runs in system mode*

That is to say: Create/Read/Update/Update (CRUD) permissions on Objects and Fields are not enforced.

System mode is often a necessity for business operations that need to complete regardless of the user that started the transaction. An example of when system mode is ideal and desired: A low privileged user updates the Stage of an Opportunity and that causes a trigger to fire which computes a lifetime value on the parent Account. The user may not have access to Read or Update the parent Account but the rollup operation should still complete.

Other operations should honor the intent of the Admin and enforce the permissions of the running user. An example: a LWC controller action (@AuraEnabled method) that allows the user to update fields on a record should ensure that the user has permission to update those fields.

Up until the Summer '22 release, the only method for enforcing CRUD and FLS within Apex was with laborious code that uses the SObject Describe methods. In the AEP project, the fflib_SObjectSelector and fflib_QueryFactory has several constructor overloads that allow the developer to decide to enforce or disable enforcement of CRUD and FLS.

Additionally, the enforcement of Sharing was controlled by a "with sharing" or "without sharing" declaration on the Apex class that invoked the SOQL query. This makes it difficult to optionally enforce CRUD/FLS/Sharing without creating duplicate class implementations that only vary by their sharing declaration.

* ISV developers are the ones most familiar with the topic of user mode and system mode because the security review team scrutinizes the Apex code to ensure user mode is used generally and only elevated to system mode with justification.

Desired Outcome

Developers should be able to enable "user mode" without much understanding of the internals of AEP.

Increase the computational efficiency of using Selectors (or fflib_QueryFactory directly) by avoiding the laborious loops and method calls to resolve field and object Describe information.

Set the expectation that in the future, the legacy methods for optionally turning CRUD and FLS enforcement on and off will be removed from the project.

Backwards Compatibility

By default, fflib_SObjectSelector has the following behavior:

• Enforce CRUD = true
• Enforce FLS = false
• Enforce Sharing = depends on the declaration in your SObjectSelector subclass

This default behavior can't change -- enabling user mode must be done with explicit intent by the developer.

Implementation Plan

There is a strawman branch open that has a draft PR against it.

https://reviewable.io/reviews/apex-enterprise-patterns/fflib-apex-common/420

Or if you're not using Reviewable, here's the native PR:

#420

This is where we'll discuss the implementation plan and we'll update this section based on what we decide on the PR.

Feedback from the community is welcome -- but remember, this is a proposed design, not a final product so we're looking for high level feedback.

[daveespo]

To anyone following along at home over on #420 -- we're close to ready to merge the support for native User Mode operations -- the last rounds of "real world" testing uncovered a few bugs that have been fixed.

If you have any ability to take this branch and deploy it in your project and update your usages of SObjectSelector to construct them using the new DataAccess argument, and run your test suite, it would be much appreciated!

[daveespo]

The PR #420 was merged just now. The notable changes are as follows:

New constructor and instance method for fflib_SObjectSelector as follows:

public fflib_SObjectSelector(Boolean includeFieldSetFields, DataAccess dataAccess)

public fflib_SObjectSelector setDataAccess(DataAccess access)

The following constructor and instance methods that manipulate CRUD and FLS are considered deprecated (they will be supported for the foreseeable future but will fall out of favor as we further enhance the AEP project and will ultimately be removed)

public fflib_SObjectSelector(Boolean includeFieldSetFields, Boolean enforceCRUD, Boolean enforceFLS, Boolean sortSelectFields)

public fflib_SObjectSelector enforceFLS()  //Use setDataAccess() instead

public fflib_SObjectSelector ignoreCRUD() //Use setDataAccess() instead

public Boolean isEnforcingFLS() //Use getDataAccess() instead

public Boolean isEnforcingCRUD() //Use getDataAccess() instead

For fflib_QueryFactory the following method was introduced:

public fflib_QueryFactory setEnforceFLS(FLSEnforcement enforcement)

The following instance method is now considered deprecated:

public fflib_QueryFactory setEnforceFLS(Boolean enforce) //Use setEnforceFLS(FLSEnforcement enforcement) instead

In fflib_SObjectUnitOfWork a new implementation of the IDML interface was created: UserModeDML. UserModeDML, by default, operates in USER_MODE but has an additional constructor to allow it to be instantiated using SYSTEM_MODE so that you can benefit from clarity of intention by running your DML operations in System Mode WITHOUT respecting Sharing.

You can construct an fflib_SObjectUnitOfWork by using the overloaded constructor as follows:

fflib_SObjectUnitOfWork uow = new fflib_SObjectUnitOfWork(new List<SObjectType>{Contact.SObjectType},new fflib_SObjectUnitOfWork.UserModeDML(AccessLevel.SYSTEM_MODE))

Or if you're using the fflib_Application factory pattern:

fflib_SObjectUnitOfWork uow = fflib_Application.UnitOfWorkFactory.newInstance(new List<SObjectType>{Contact.SObjectType},new fflib_SObjectUnitOfWork.UserModeDML(AccessLevel.SYSTEM_MODE))

It is improbable that we will ever change the default behavior of fflib_SObjectUnitOfWork to use native SYSTEM_MODE by default given the very subtle change in behavior between SYSTEM_MODE and a pure insert (the former ignores sharing rules, the latter honors sharing (with, without or inherited))