Releases: jamessimone/apex-rollup
Bugfixes for AVERAGE
- Fixed a bug with
AVERAGE
where not all calc items were being applied to the denominator when a where clause had been passed - Fixed a bug with
RollupEvaluator
where "special" phrases ("in" / "not in") were being taken out of context when filtering SObjects
Easier imperative Apex, fix truncation on update
- Fix for #49 by enabling truncation on update
- Fix for #48 by exposing
runFromApex(List<SObject> records, TriggerOperation rollupContext)
method - possible values for therollupContext
argument are:
- TriggerOperation.AFTER_INSERT
- TriggerOperation.AFTER_UDATE
- TriggerOperation.BEFORE_DELETE
- TriggerOperation.AFTER_UNDELETE
Stable For Custom Objects / Custom Fields
- Actual fix for #45 (support for custom objects)
- Fixed issue where averages could blow up when a null value was present
- Fixed a potential concat issue caused by trailing delimiters, added additional integration tests.
- Fixed an issue with usage of
RollupFlowBulkProcessor
invocable where an inner exception could get inadvertently eaten, reporting success when the actual staged rollup had an error. TheisSuccess
flag andmessage
fields on the flow output(s) now properly update accordingly. - Standardized how
Rollup__mdt
records are retrieved, fixing for good the issues present with custom fields/objects being used inRollup__mdt
entity definition and field definition fields
Rollup from parent records & Record Triggered Flow documentation update
Fixes #25 by allowing rollup operations to start from the parent records by:
- adding
Rollup__mdt.IsRollupStartedFromParent__c
field to allow CMDTRollup
users to flag rollups started from the parent - for
RollupFlowBulkProcessor
invocable, also addedCalc Item Type When Rollup Started From Parent
because we need to know the child SObject name whenIs Rollup Started From Parent
is checked off on theRollup__mdt
record - for
Rollup
invocable, in addition to theCalc Item Type When Rollup Started From Parent
field above, also addedIs Rollup Started From Parent
to mirror the approach taken from CMDT
Breaking change for Record Triggered Flows (also added to Readme):
A patch to the Spring 21 release at the end of February introduced a breaking change in the way that the Flow engine hands off Invocable variables to Apex. Currently, if you are using a record triggered flow, you have to use Get Records
using the current record's Id in order to populate the Records To Rollup
argument properly for both invocables. I will remove this notice when the functionality has been fixed, but there is a bug with simply adding the current record to a collection variable and passing that to the invocable action accordingly. Thank you for your attention to this notice!
Deferred Flow Rollups & CMDT driven flow rollups
- Fixes #26 by adding CMDT-driven flow rollup support
- Fixes #38 by adding support for deferring rollups entered in Flow with both
Perform Rollup__mdt-based rollup
andPerform rollup on records
actions when theDefer Processing
property is set to{!$GlobalConstant.True}
. Rollups deferred in this way must call theProcess Deferred Rollups
invocable action
Update
- Removed required attribute from
Records to rollup
on base invocable to fix issue in Flow engine where if filter criteria are used in aGet Records
action and there are no matching results, the Apex action throws an error for the input being null (when it really should be empty). The null check is handled in Apex instead, removing the need for the Flow builder to explicitly check for null on the returned collection.
Batch Chunk Size & Bugfixes
- Fixed an issue with CMDT being read-only when retrieved from the cache, and consolidated how CMDT was being treated in this respect so that the "fix" didn't need to be all over the place
- Added
RollupControl__mdt.BatchChunkSize__c
to allow configuration of how many records are passed into each batch job
Query Archived Records & Scalability Improvements
- Fix #35 by adding ALL ROWS support for Task/Event objects
- Improve scalability by examining current queries issued - add two fields on RollupControl__mdt, MaxQueryRows__c and MaxRollupRetries__c to aid in configuration related to this change
Increasingly, the Rollup
class itself functions effectively as a Facade for rolling up, with much of the work delegated to RollupCalculator
and the other, smaller classes. This paring down of the globally exposed class left room for scalability improvements; in addition to deciding dynamically when to go batched versus queueable, Rollup
now can restart itself if it is close to imposing upon default sentinel query limits. This release solidifies the "infinite scaling" that Rollup
is capable of.
First / Last Operations
- Updated README with Entity Definition limitations of CMDT (can't be used for Task/Event/User objects; workarounds are provided)
- Bump API version to 51 uniformly
- Add VS Code settings for spaces to aid with local development across machines
- Fixes #34 by adding support for first/last operations.
- Update Contributing guidelines and bump version
- Address issue with #38 by exposing first/last operations via global static Apex methods, as well as allowing for the use of default values from those code paths, which had unintentionally deviated from the behavior present on the CMDT-based route
Reparenting Support & Rollup Control
This is our first medium release for Rollup
, and I'm happy to include the fix for #7 (via #28 ) by none other than Salesforce legend @jongpie - no small feat to come into a big project like this and add such complicated functionality into the equation.
Additional changes:
- Deprecate RollupLimit__mdt
- Added new CMDT, RollupControl__mdt
- Rollup__mdt now has a lookup field for RollupControl__mdt, allowing for Rollup Control records to have a 1:many relationship with Rollup__mdt records (fixes #29)
- Deprecated Rollup__mdt.RollupType__c in favor of Rollup__mdt.RollupOpreration__c, allowing for a field-change to picklist (fixes #33)
Updated CMDT page layouts - Fix #27 by adding support for multi-select picklist includes / excludes criteria in where clause
- Org Default record for RollupControl__mdt included now by .... default
- Various bugfixes for an edge case with #7 where the rollup evaluator being used might not correctly detect reparenting if a custom Rollup.Evaluator interface was supplied
- Fix #30 by changing the "Should Run As ...." checkbox fields to a single picklist field with options for Queueable, Batchable, and Synchronous Rollup
- Some inner enhancements made to the RollupEvaluator class, saving a few CPU cycles on some operations by correctly breaking early out of two loops when a sentinel value is encountered
- Now that the API for Rollup__mdt has grown more solid, moved some fields out of Admin.profile and made them required by default
- Added support for legacy
combobox
type fields - Fixed a bug in SOQL where clauses when a picklist field had parenthesis in the API name
- Fixed another SOQL where clause bug caused by the conditional operators (or, and) existing in API names