CanTheUser/Safely is a delightful and elegant way to handle CRUD and FLS Checks. It comes in two parts: CanTheUser, and Safely. CanTheUser is focused on determining if a user can do a given CRUD operation, and whether or not the user has access to specific fields via Field Level Security (FLS). Safely, on the other hand, is dedicated to wrapping DML methods that enforce user FLS and Crud Checks. Safely, in part, relies on parts of CanTheUser, so these are shipped together.
CanTheUser/Safely is a library extraction from Apex Recipes
Contributions are always welcome!
See contributing.md for ways to get started.
Please adhere to this project's code of conduct.
To install or deploy CanTheUser/Safely you have three options:
- SPM Install: This is the preferred method, but it requires SPM. Find out more here.
sfdx spm:install -n 'CanTheUser' - Package Link: Click this link to install the CanTheUser/Safely unlocked package in your org.
- Git Clone: This is an exercise left to the reader.
CanTheUser is designed to be intuitive and easy to read and use. At a high level, it consists of CRUD checking methods that largely follow the permission names whenever that permission name is not an apex reserved word. For instance: the Read permission is checked with the Read() method. Sadly, delete is a keyword, so the delete permission is checked with destroy(). Each of these methods requires either an sObject to check or a list of sObjects to check. However, be careful when using mixed sObject lists (ie: list<Sobject>) rather than list<ConcreteSObjectType> as the list accepting variants use the first item in the list for checking.
Check for CREATE permission on Account
CanTheUser.create(new Account());
or
CanTheUser.create(accountList);
Check for READ permission on the Account object
CanTheUser.read(new Account());
or
CanTheUser.read(accountList);
Check for EDIT permissions on the Contact object
new CanTheUser.edit(new Contact());
or
new CanTheUser.edit(contactList);
Check for DELETE permissions on Contact object
new CanTheUser.destroy(new Contact());
or
new CanTheUser.destroy(contactList);
FLS checks are based on a given Object, Field and a calling-method-name implied FLSType enum - with values of Accessible and Updatable
For instance, to check if the current user has access to update the TradeStyle field on the Account object, you'd call
CanTheUser.flsUpdatable('Account', 'TradeStyle');
Likewise, to check for accessibility use:
CanTheUser.flsAccessible('Account', 'TradeStyle');
Like CanTheUser, Safely is intended to be clear, succinct and largely self-documenting through intuitive method names. It utilizes a Fluent interface, that allow you to define the behavior of Safely inline with your DML. Beyond the constructor, there are currently two fluent methods to enable options:
.allOrNothing()- When called, this sets allOrNone flag on the underlying Database.* calls Safely makes..throwIfRemovedFields()- When called, this causes Safely to throw aRemovedFieldsExceptionwhenever the SObjectAccessDecision calculation indicates that fields were removed. If this method is not called, the records, and fields permitted by the SObjectAccessDecision are passed to the indicated Database.* call.
Note: Safely fails safe - meaning that there is no way to invoke it's DML methods in a way where CRUD and FLS are not enforced.
To safely insert, with AllOrNothing set, throwing if there are removed fields:
new Safely().allOrNothing().throwIfRemovedFields().doInsert(List<sObject>);
To safely insert, removing fields the user has no access to:
new Safely().doInsert(List<sObject>);
To safely update, with AllOrNothing set, throwing if there are removed fields
new Safely().allOrNothing().throwIfRemovedFields().doUpdate(List<sObjects>);
To safely update, removing fields the user has no access to:
new Safely().doUpdate(List<sObjects>);
Likewise, you can call doDelete, doUpsert similarly.
Finally, you can execute SOQL / SOSL queries by calling new Safely().doQuery(queryString)