Global Bypass

[parsam97]

Hello!

I was just wondering, why I couldn't find any way to globally bypass all triggers for the transaction.

This is particularly useful for test classes. Let's say I forked fflib-apex-common, which inserts some accounts, contacts, etc. Of course I could simply bypass those sObjects, or if I really wanted to I could do a global describe and bypass all sObjects in a loop. But shouldn't the framework provide such functionality?

Thanks!

[benjaminloerincz]

I like that idea. Either introducing a new private static Boolean in class TriggerBase called allBypassedand referencing this in relevant places of the framework or this method could do the job:

for (sObject_Trigger_Setting__mdt setting : [SELECT Object_Namespace__c, Object_API_Name__c FROM sObject_Trigger_Setting__mdt]) {
	String sObjectToBypass =
		(String.isBlank(setting.Object_Namespace__c) ? '' : (setting.Object_Namespace__c + '__')) +
		+ setting.Object_API_Name__c;
	TriggerBase.bypass(sObjectToBypass);
}

This piece of logic could be used in the meanwhile as well.

[parsam97]

Right of course! Didn't think to query the metadata object directly. Much better than global describe.

Glad you like the idea :)

[mitchspano]

We could also just have a key word: all which is used with the existing mechanisms to bypass everything.

[parsam97]

Would you have anything against it if I develop the changes for this and submit a PR here?

Otherwise if you guys have your own processes and everything, I totally understand! It's just, I've used this framework heavily and would love to contribute to it, if I can.

[mitchspano]

Please sign the CLA and submit a PR!

[benjaminloerincz]

@parsam97 Oh, I just read your comment. I just finished a first draft for this, see benjaminloerincz@7e06281.
While coding I wasn't sure if my approach is the way we should go. Feel free to deep dive here, contributors are always welcome ☺️

[parsam97]

@benjaminloerincz I did a deep dive :D

Honestly, I've retyped this message several times now. Instead I'm just gonna say this. I started out by looking at the changes in your commit, and for the flow invocables, I noticed that

// TriggerActionFlowClearAllBypasses.cls
protected override void processAllBypasses(String name) {
    TriggerBase.clearAllBypasses();
}

// TriggerActionFlowBypass.cls
protected override void processAllBypasses(String name) {
    TriggerBase.bypassAll();
}

...the execute method in the abstract TriggerActionFlowBypassProcessor is passing requestName to processAllBypasses, mostly because we are collecting that data in the invocable as part of the bypass request, but we never actually use those values for bypassAll. For the existing code, that made sense, but for bypassAll, it feels like it's starting to break pattern. And this is just on the flow side. With Apex, it's generally fine.

A bit pedantic I know, but then one thing led to another, and I ended up with this rough idea, with which some inconsistencies fall back into place, at least in my head:

Granular Bypass Control
----------------------

Bypass control in decreasing levels of granularity:

1. an action 
  (opp_flow_doThis.mdt) <-- `TriggerActionFlow.bypass(opp_flow_doThis);`
  (opp_apex_doThis.mdt) <-- `MetadataTriggerHandler.bypass(opp_apex_doThis);`

2. an action type for an object (spans multiple actions)
  (flow, opportunity)   <-- missing, likely in `TriggerActionFlow`
  (apex, opportunity)   <-- missing, likely in `MetadataTriggerHandler`

3. an object (spans multiple actions and action types)
  (opportunity)         <-- `TriggerBase.bypass(Opportunity.SObjectType);`

4. action type (spans multple actions and objects)
  (flow)                <-- missing, likely in `TriggerActionFlow`
  (apex)                <-- missing, likely in `MetadataTriggerHandler`

5. all actions (spans multple actions, action types, and objects)
  (none)                <-- `TriggerBase.bypassAll()`

I very much suppose this level of granular control in the bypass mechanism is for the majority of people unnecessary 😆
Also that it increaases the scope of this feature a lot. I tried to code out something rough, but I think done right, it would amount to a lot of changes. I could be wrong though.

Like I said I realize this could be overkill, and your changes definitely produce the global bypass I actually need. I just thought I'd share. What do you think? Is this something that might be interesting for the framework?