Version 1.2.7

Better late than never, this fixes a problem that arose when handling Custom Platform Events with the Framework. During Trigger Collection creation, I try to check if we are in an After Context by checking the Id field of Records. As this field doesn't exist with Platform Events, it becomes problematic during productive use.

The record type filter passage is skipped for Platform Events therefore. A new test now checks that this doesn't get broken again.

Version 1.2.6

This release I tried to improve performance of the Record Type Filter functionality. This works by assigning the Records in the Trigger Execution before executing handlers, so that the handler can simply get the Records that conform to the Record Types filtered.

1.2.5

What's Changed

• Stabilize Test Runs for Orgs without Trigger Factory Settings and without Record Type Filters by @dschibster in #7
• specify ascending sorting by @dschibster in #8
• Fixed a bug where the OoE does not represent the actual order of MDTs… by @dschibster in #9

Full Changelog: 1.2.3...1.2.5

Version 1.2.3

Stable Test Classes

I realized that when installing the Framework on a fresh org, there are tests that rely on the unpackaged metadata in this Repo to run smoothly, and that hindered both TriggerMapping and the record type filter functionality of TriggerHandlerExtension to fail. This is now fixed by checking if the necessary Trigger Factory Settings exist and by mocking the Record Type Filter functionality by checking the Id of a newly inserted Lead.

Version 1.2.2

Now includes mkdocs documentation found on https://dschibster.github.io/sfdx-trigger-factory

During the documentation I realized a potential performance optimization, relevant for when a Trigger is actually disabled.

Version 1.2.1

Fixed a small bug in the assignment of Layout for the Trigger Factory Setting

Set up MkDocs for Documentation purposes

Version 1.2

Introducing Record Type Filtering directly on the Trigger Factory Setting Level

Allows you to run selective logic across a multitude of Trigger Handlers, so that only the records you actually need go through your desired automations.

Version 1.1

Significant trimming down of unnecessary fat.

• The ITrigger Interface is no more. All inheritance is done via TriggerHandlerExtension
• TriggerSetting__mdt was too performance hungry, instead we are now either
  • able to disable a Trigger Factory Setting altogether
  • able to disable Objects / Handlers in a Custom Setting