RollupDateLiteralTest Failing at Fiscal Quarter #325
Comments
|
Jotting down some notes as I was able to take a quick look at this on Friday - I doubt the fixes will make it into the next version, but it will be my priority to fix this once the latest version has been released. |
|
Making progress on this issue. I've found a number of edge cases with the existing TL;DR - progress is being made, but slower than I would like and, if there continue to be other fixes being pinned to |
…iteral, which helped to pinpoint the various edge cases with respect to date/time that weren't previously handled
* Fixes issue reported by @solo-1234 where occasionally full recalcs could fail if all fields on a set of calc item weren't queried properly * Fixes #331 by properly handling unfilterable fields in RollupParentResetProcessor * Fixes issue found while investigating FIRST/LAST appending first day of UTC time in some full recalcs reported by Katherine West * Adds the ability to stringify non-text fields in order to write them to text fields * Cleaning up deferred full recalc logic and how updates work to avoid competing async record updates - reported by Katherine West * Cleaning up RollupCalcItemReplacer logic surrounding when base fields need to be requeried taking advantage of SObject.isSet function * Adds new field, RollupControl__mdt.OnlyRunInFlowContexts__c to allow for finer-grained control over when flow rollups should run. Requested by @solo-1234. Still TODO - adding this as an optional property to the base invocable (currently only supported for the CMDT-based rollup) * Fixing an issue where the parent reset processor would run too soon when a full recalc operation was deferred * Fixes #325 by creating a massive automated test suite for RollupDateLiteral, which helped to pinpoint the various edge cases with respect to date/time that weren't previously handled * Fixing an issue reported by Katherine West where it was possible to throw an exception when calc items of different types are part of the same overall rollup operation
Discussed in #324
Originally posted by shane-saltbox May 24, 2022
@jamessimone I'm attaching a quick analysis of what we found while trying to manually implement the test coverage for the package. We'd like to be able to use the plug-in now that I know it's there, but suspect that'll fail until we're able to address the issue we found.
For context, our business starts it's fiscal year in February, which has also been updated on the 'Fiscal Year Starts In' value to February.
While going through the install of the test classes several methods in
RollupDateLiteralTestfailed due to the use ofTHIS_QUARTERinstead ofTHIS_FISCAL_QUARTERfor example. We were able to get around most of them quickly by utilizing the fiscal date, but also had to make a few other changes / comment a few sections out. At the end of the day there was still a good code coverage after these changes.I'm attaching a quick diff so it's easy for you to find what changes we had to make.
The text was updated successfully, but these errors were encountered: