Change #1127941 had a related patch set uploaded (by Wfan; author: Wfan):

[mediawiki/extensions/DonationInterface@master] When checksum invalid like empty, let them get update link instead of return error

https://gerrit.wikimedia.org/r/1127941

Thanks @Cstone

Some donors are still running into issues with the 'other' box, but when asked for more information, one got back and told me they retried without the $ sign and it worked.

Can I confirm: Will the other box only accept number format (no currency symbols)? As that may be counterintuitive for donors and could be the root of the error for some of those who have reached out.

Thanks for any insights you have!

Thanks @Cstone for looking into this.
Please let the Email team if this is a coding fix needed so we can record it for next upgrading activities.

In T388912#10640570, @krobinson wrote:

Thanks @Cstone

Some donors are still running into issues with the 'other' box, but when asked for more information, one got back and told me they retried without the $ sign and it worked.

Can I confirm: Will the other box only accept number format (no currency symbols)? As that may be counterintuitive for donors and could be the root of the error for some of those who have reached out.

Thanks for any insights you have!

Ok, I see what's confusing here. Thanks for the detail on this also! I've created a separate ticket for this here T389066: Fix validation for currency-prefixed amounts in the "other" donation field as it's a separate issue from the missing checksum stuff we found on Friday.

When you enter an amount prefixed with a currency symbol, you still get the green tick, although that's actually an invalid value. However, the tick is being shown due to the selected option, but it's also implying the input added to the field is valid, so it's confusing. If you try clicking 'Update my gift' after adding a currency prefix, you won't be able to submit the form due to the invalid characters.

We can fix this to improve the user experience.

This issue has also highlighted that there may be a bug in how we generate and send checksums and contact IDs to Acoustic. We're perhaps failing to produce or export them in certain scenarios. This issue could exist in the underlying SQL responsible for generating the Acoustic export data. We can confirm that by checking the exports for the affected period.

Yes! @jgleeson you've nailed it - that is what donors were saying, the button didn't work when they tried to submit. can we fix, as we have invited a bunch to retry with the correct link from their Civi (assuming that was the issue) and some have then come back saying it still didn't work. I feel we need to fix this as it's counterintuitive not to include the currency prefix if the other amounts listed include it.

In T388912#10641696, @krobinson wrote:

Yes! @jgleeson you've nailed it - that is what donors were saying, the button didn't work when they tried to submit. can we fix, as we have invited a bunch to retry with the correct link from their Civi (assuming that was the issue) and some have then come back saying it still didn't work. I feel we need to fix this as it's counterintuitive not to include the currency prefix if the other amounts listed include it.

@krobinson, @Cstone just wrote a fix, which was just approved now and should go out shortly!

@krobinson the $ fix has been deployed

Looks like we have donors that don't have a hash set in civicrm_contact in the first place. When the silverpop export took the hash to calculate the checksum to export, it calculated an empty checksum and that's how it got to acoustic.

There are 400k contacts in civi without a hash resulting in 100k acoustic entries without a checksum.

Also looks like it only affected older contacts, anyone created after 2014 had a hash generated automatically. We ran a script on our end and everyone in the civi database now has a hash.

In T388912#10648550, @Cstone wrote:

Looks like we have donors that don't have a hash set in civicrm_contact in the first place. When the silverpop export took the hash to calculate the checksum to export, it calculated an empty checksum and that's how it got to acoustic.

There are 400k contacts in civi without a hash resulting in 100k acoustic entries without a checksum.

Makes sense!

Hi @Cstone and @jgleeson Circling back on this one - I wanted to make sure that nothing needs to be changed or added when we code emails for upgrading purposes.

@MSuijkerbuijk_WMF I checked with @NNgu-WMF and right now the only records in acoustic without a checksum are SMS contacts which won't have one until they make a donation.

Going forward for any emails that will be about updating data (recurring upgrade, email preference center, donor portal) we should add a check for the checksum being there in the acoustic query

Thanks, makes sense. @NNgu-WMF do you mind adding this to our Agreements tab for targeting and as a learning/reminder at the top in the Upgrading Year 2 data brief? Thanks

Change #1127941 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] When checksum invalid like empty, let them get update link instead of return error

https://gerrit.wikimedia.org/r/1127941