Recurring Donations Batch Filtering #6971
Conversation
| Integer dateRange = getOpportunityModifiedDateRange(); | ||
| Date earliestModifiedDate = currentDate.addDays(-dateRange); | ||
| rdFilterWhereClause = 'Id IN (SELECT npe03__Recurring_Donation__c' | ||
| + 'FROM Opportunity WHERE LastModifiedDate > :earliestModifiedDate)'; |
There was a problem hiding this comment.
Hi @lparrott - any chance we can switch this to use SystemModStamp instead of LastModifiedDate since SystemModStamp is indexed?
There was a problem hiding this comment.
Definitely, I have a list of questions to ask you and JJ, one revolves around potentially reusing the "Incremental Mode Field Override" setting for this query, which defaults to SystemModStamp. One downside: since there's only one field, it would be used for all incremental batches.
…lesforceFoundation/NPSP into feature/240__rdBatchFiltering
lparrott
changed the title
… ensure that Time Bound rollups are handled correctly
force-app/main/default/classes/RD2_OpportunityEvaluation_BATCH.cls
Outdated
Show resolved
Hide resolved
force-app/main/default/classes/RD2_OpportunityEvaluation_BATCH.cls
Outdated
Show resolved
Hide resolved
force-app/main/default/classes/RD2_OpportunityEvaluation_BATCH.cls
Outdated
Show resolved
Hide resolved
...tomizable_Rollup_Settings__c/fields/Limit_Recalculated_Recurring_Donations__c.field-meta.xml
Outdated
Show resolved
Hide resolved
…lesforceFoundation/NPSP into feature/240__rdBatchFiltering
There was a problem hiding this comment.
Thanks for making the previous set of changes. Two comments/questions related to the custom settings fields and possible null values. I'm pretty sure I remember that null custom settings fields - mainly after adding new fields - used to cause null pointer exceptions for existing customers. It's been a while, but I think this might still be true. Some form of null check (and/or the new null-safe operator) might be useful.
|
@npsp-reedestockton @force2b I had to commit a change on this PR to resolve a query exception that was occurring in the |
| @@ -121,6 +121,7 @@ public with sharing class STG_PanelRDBatch_CTRL extends STG_Panel { | |||
| if (isRD2Enabled) { | |||
| RD2_OpportunityEvaluation_BATCH rdBatchJob = new RD2_OpportunityEvaluation_BATCH(); | |||
| Integer batchSize = rdBatchJob.batchSize; | |||
| // rdBatchJob.closedFilterEnabled = false; | |||
There was a problem hiding this comment.
Is there a reason this line is commented out vs. just removed?
There was a problem hiding this comment.
This is for 2GP testing since we can't execute the batch from anonymous apex and only from NPSP Settings. I plan to uncomment this once 2GP testing is completed. We didn't want the batch filter to apply when running it from NPSP Settings which is why we are setting to false here.
| <?xml version="1.0" encoding="UTF-8"?> | ||
| <CustomField xmlns="http://soap.sforce.com/2006/04/metadata"> | ||
| <fullName>RecurringDonationLastNDays__c</fullName> | ||
| <defaultValue>31</defaultValue> |
There was a problem hiding this comment.
Not sure 31 is a good default value for this. Most RDs are monthly, and If a customer is using Enhanced RDs there will usually be one Opportunity that has been updated in the last 31 days. Most of the RDs that will be bypassed with this default will be closed RDs. If that's the intent, cool, otherwise this is too high for the default incremental mode value.
There was a problem hiding this comment.
@danielfuller0814, please let me know if you change the Default Value from 31. Thanks!
…r testing purposes in 2GP context" This reverts commit b660cc5.
…lesforceFoundation/NPSP into feature/240__rdBatchFiltering
|
@ErinWiedemer we decided to keep the default value at 31 |
Critical Changes
Changes
Issues Closed
Community Ideas Delivered
Features Intended for Future Release
Features for Elevate Customers
New Metadata
Deleted Metadata