Add support for grandchild to grandparent rollups (and potentially more) #46
Labels
enhancement
New feature or request
Comments
|
One additional thought on this - since rollup now supports initiating rollups from parent records (PR #43), it probably makes sense to do the same for grandparent records, i.e., allow rollups on a grandparent record to trigger recalculating rollups that are driven by grandchild records. |
jamessimone
added a commit
that referenced
this issue
Mar 12, 2021
…ldFinder to larger Rollup framework
jamessimone
added a commit
that referenced
this issue
Mar 13, 2021
…do related to re-queueing and avoiding duplicate queries
jamessimone
added a commit
that referenced
this issue
Mar 15, 2021
…ldFinder to larger Rollup framework
jamessimone
added a commit
that referenced
this issue
Mar 15, 2021
…do related to re-queueing and avoiding duplicate queries
jamessimone
added a commit
that referenced
this issue
Mar 15, 2021
…ldFinder to larger Rollup framework
jamessimone
added a commit
that referenced
this issue
Mar 15, 2021
…do related to re-queueing and avoiding duplicate queries
jamessimone
added a commit
that referenced
this issue
Mar 16, 2021
…ldFinder to larger Rollup framework
jamessimone
added a commit
that referenced
this issue
Mar 16, 2021
…do related to re-queueing and avoiding duplicate queries
jamessimone
added a commit
that referenced
this issue
Mar 17, 2021
…hipFieldFinder, and added test proving it works
jamessimone
added a commit
that referenced
this issue
Mar 19, 2021
* Deprecated `RollupControl__mdt.MaxLookupRowsForQueueable__c` in favor of `RollupControl__mdt.MaxParentRowsUpdatedAtOnce__c`. Previously an exception was being thrown if there were too many parent records getting updated, but we can just chunk the updates. Started investigating why MaximumRollupRetries__c is not being used. Current status - fixing `shouldDeferUpdateWhenMaxParentRowsLessThanCurrentUpdateRows()` test * got tests back to green after `MaxParentRowsUpdatedAtOnce__c` addition * begin refactor toward usage of `QueryWrapper` object to prevent string overflow for full recalculation query string * Added parent recalc integration test with custom fields * Actually make use of `stackCount` variable * First pass at fixing `RollupRelationshipFieldFinder` to actually traverse up the object chain to retrieve the ultimate parent records. * Major cleanup of `RollupRelationshipFinder` and tests, added in ability to determine if the ultimate parent of a record has changed * Updating test/build script to properly take into account test command not exiting process * Further progress on #46 - start of work to wire `RollupRelationshipFieldFinder` to larger Rollup framework * Added further sanity tests for `RollupRelationshipFieldFinder` validating that it uses the where clause effectively (may still need more testing here), and that a singular parent tied to multiple children is tracked correctly * Got rid of flow and flow test now that patch 230.12.2 has hit and fixed the reflection issue with flow engine and SObject collections * Started wiring up `Rollup` to `RollupRelationshipFieldFinder`, added `Rollup__mdt.GrandparentRelationshipFieldPath__c` * First passing integration test for #46. still some cleanup/tweaks to do related to re-queueing and avoiding duplicate queries * Cleaning up grandparent rollups, bulk optimization for grandparent rollups, updated Readme documentation, bumped medium version, replaced local variables where they were shadowing class variables * Added passthrough / grandparent functionality to each invocable. Proper encapsulation for `traversal.isFinished` * Nearing completion - added `traversal.getOldUltimateParent()` method so that grandparent items can eventually compare whether or not the old value changed during reparenting; it will also be necessary to test that this works on the non-reparenting route * Got reparenting for grandparent rollups working! * Fixing cached testing metadata issue, updated folder directory in `extra-tests` to put triggers at top level * Updating comments * Parent-initiated grandparent rollups now working, with the caveat that these have to conform to the SOQL max object jumps of 5 * Final updates for #46 - fixed recommencement bug with `RollupRelationshipFieldFinder`, and added test proving it works * Updating readme with parent-initiated great-grandparent rollup note * Excellent feedback from @jongpie - made `Traversal` constructor private, added better clarity surrounding when `RollupRelationshipFieldFinder` uses the simple out of lookup ids changing for reparenting, reverted an unnecessary change from null to empty string in `RollupTests`, and removed the unnecessary `System` namespace prefix from the Formula method in `RollupEvaluatorTests` * Fixing last of the feedback from @jongpie - if intermediate parents are legitimately updated, Rollup now properly recalculates grandparent rollups * Fixed `README` typo, added comment explaining non-idiomatic CDC behavior * Prettier formatting
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This feature request from @elements:
Currently, rollup assumes that the only
1 : manyrelationship is from the parent to each "child" object in the hierarchy - but it would be great to allow something like rolling up fields from Opp Line Items straight to Account, for example; cutting out the Opportunity middleman.For multiple "jumps" between objects, the relationship between the "lookup field" (since it can be a string or Id) to the parent object would have to be established (possibly using "Apex map" syntax a la @tsalb's Custom Column Labels in lwc-utils, or with another CMDT that's related to
Rollup__mdt). Being able to use filtering criteria on the in-between objects should also be supported.The text was updated successfully, but these errors were encountered: