"Database operations: sharing" needs to be more robust

We need to be able to configure the “Database operations: sharing” rule to do the following:

  1. Trigger handlers (Classes used in triggers) need to use “without sharing”. Because triggers run without sharing, so a Trigger Handler that uses “with sharing” alters that functionality.
  2. Batch or Schedule classes can use any sharing, because they are typically ran by a System Administrator and access can be easily controlled.
  3. Handler and Utility classes (classes with data access) need to use “inherited sharing”, because they should be written to be reused by any type of class.
  4. Controller classes (classes with auraEnabled methods, are used in VF pages, or expose APIs) need to use “with sharing” because that is the interface with the user.

Right now Controllers and Handlers are in the same group, and Trigger Handlers, Batches, and Schedules are all the same group.

1 Like

Thanks for your feedback Andrew!

We are updating how this rule works in our updated engine. The key idea here is that sharing should be intentional, so we’ll flag only instances where it’s omitted (but shouldn’t be) as problems.

Would that be sufficient or you still need a way to enforce certain conventions?