Custom Settings to Disable Triggers (via hier custom settings)

[bjanderson70]

Need the ability to disable triggers via Hier. Custom Setting. I am planning on creating a sub-dir framework-application-configuration to contain IApplicationConfiguration that allows one to get the IDomainConfiguration, ISelectorConfiguraiton and IServiceConfiguration. Why 3? Interface Segregation. Will start w/ IDomainConfiguration would initially define the following:

 // is the sobject triggers enabled (i.e. 'Account', 'Contact', or 'All' ...) [_default impl, returns true_]
 boolean isTriggerEnabled(string sobjectName);
 // trace/debug information wanted ... instead of 'system.debug'; use a configuration to turn on/off
 // this cross-cuts other configurations but here for completeness [_default impl returns false_]
 boolean isTracing();

So why this way instead of active/de-active in the CMT ? Bec/ different users/profiles will have different needs. For example, a system integrator performing bulk loads may run under a profile that wants triggers disabled. For others, the triggers are enabled.

If you have any comments/issues please let me know ... WIP.

[ImJohnMDaniel]

@bjanderson70 -- The ability to "disable triggers" is embodied in the ability to, not so much disable the triggers, but rather the ability change the "IsActive__c" value in the DomainProcessBinding custom metadata records. Check out these examples:

• DomainProcessBinding.FishCompanySlogans10_10Criteria.md-meta.xml
• DomainProcessBinding.FishCompanySlogans10_20Action.md-meta.xml

So effectively the triggers are not disabled but rather the actions that they take are disabled. This provides greater flexibility in that you are able to disable some or all of the actions that the trigger takes.

[ImJohnMDaniel]

You could also program the functionality to pivot by custom setting into the Domain Process actions.

[bjanderson70]

Thanks John ... that does not appear to be tied to different profile or user. The isactive can be come very cumbersome for a large Org ( given the granularity of Before/After events). Thus, bec/ we can have system integrator(s) or tailored to a specific SObject.

[bjanderson70]

It would appear to be cleaner to modify the ctor (ApplicationSObjectDomain) ... and enable/disable trigger via the Hier. Custom Setting ... something like ....:

          // disable configuration based on hier. custom settings
          if ( !this.DomainConfiguraiton.isTriggerEnabled(sobjectName) ){ 
	    fflib_SObjectDomain.getTriggerEvent(objectClass).disableAll();
          }

Within IApplicationSObjectDomain ... I would modify and configuration interface (i.e. IDomainConfiguration). Using DI, grab a configuration ( would default to a base configuraiton, if not defined) ...

[ImJohnMDaniel]

I hear ya and it was deliberately designed to not disable at the trigger level.

The alternate suggestion I mention here. That would work for your needs unless I am missing something.

Just let me know.

[bjanderson70]

Hmmm ... if you are referring to the alternate suggestion:

      _'You could also program the functionality to pivot by custom setting into the Domain Process actions.'_

that would appear to be late in the process. This way I avert the overhead of calling 'getDomainProcessCoordinator' and any other sub-process. Unless I am mistaken in your suggestion?

[ImJohnMDaniel]

No, you see what I am talking about. I am not certain that you would be saving much time though and it would be a big, blunt kill switch -- kinda opposite direction that we took with this design.

[bjanderson70]

I think I can still perform the following (interfaces, di and base classes in a sub-dir); deferring at this time the handling of custom settings ( whether via the ApplicationSObjectDomain via the DomainProcessCoordinator). However, note, if it is done in the DomainProcessCoordinator it does not close the door down as ApplicationSObjectDomain (being an abstract class) allows the trigger events to be overridden. Thus, if someone inherits ApplicationSObjectDomain , they can override any of the handle (i.e., handleBeforeInsert).

[ImJohnMDaniel]

So, are you proposing a single hierarchy custom setting to control all triggers? How would you delineate between deactivating one trigger verses another?

[bjanderson70]

Without getting to fancy ( include or exclude sobjects or support of regex). For example, in custom setting field , create a field disableTriggerByDomain. This is would be a (comma, semi-colon or whitespace) delimited field of Domains to disable (i.e. disableTriggerByDomain='All' or disableTriggerByDomain='Account, Contact', 'Lead', ...); For profile integratorA,they may be installing a varied amount of SObjects and need, disableTriggerByDomain='All' , thus any domain trigger gets disable for that bulk integrator. For profile integeratorB, they may ONLY be loading Account and Contacts for example, disableTriggerByDomain='Account, Contact'. If the value, disableTriggerByDomain, is empty, it follows the same flow you have now. Thus, you can have more than one behavior based on profile or user running at the same time. It is not perfect but this is a common occurrence dealing with integration. If there is a simpler way, I'm all ears.

[bjanderson70]

OK ... the disableAll in fflib (fflib_SObjectDomain.getTriggerEvent(domainClass).disableAll(); did not disable invocation for all when coming thru the ctor. As a result, after reading the custom setting, I set a flag and check subsequent calls. Bec/ the class (ApplicationSObjectDomain) is abstract and can be inherited, there needed to be a check in each handler method.
The bulk of it is here ( https://github.com/bjanderson70/at4dx/tree/master/sfdx-source/core/main/classes/framework-application-config ). I added a rudimentary tracer ( to better control the spew). I can do a pull request ... if that is easier