Thanks @AMJohnson, that is good information.

Thanks for checking @ppenloglou! So I wonder how that full real URL gets translated to the long gibberish links.email.wikimedia.org URL that we see in the screenshot, and how the long URL gets translated back to the one with the full params. If it's something dynamic I guess it's possible that Acoustic could break a link after send. Could it have to do with the fact that their email address isn't in Acoustic?

For donor 397205, it does look like a bad link. That screencap seems to be the text-only version of the email. Has that been QA'ed? Can we check that the checksum token is there in the text-only version?

Oops, we added this to the IPN listener but now the Civi queue consumer doesn't know what to do with it: https://civicrm.wikimedia.org/civicrm/damaged/edit?id=619453

@AKanji-WMF it would be nice, but maybe next sprint. The checksums shouldn't expire for 30 days, so this feature can wait a little bit

Oho, our RecurUpgradeMessage is not the culprit here.

Just to follow up, we were able to change the viewport in the rendered HTML, and that change went out today.

No issues, this looks fine

OK, I have deployed the fixes to track the parameters when they decline and to pass the parameters along to the TY pages.

Nice @SHust, glad to hear you were able to fix i!

Still trying to replicate this on dev - I created two recurring donations with the older one a braintree one, then upgraded the second. The email correctly referred to the upgrade amount of the second donation, not the first.

It'll probably be an improvement for the EmailPreferences page too! I'll see what the best way to change that in the rendered HTML is so we don't get a restyling flash when the JS runs.

@ehughes thanks for the new CSS! I've just deployed it along with the uploaded image.

This is deployed to track the wmf_ parameters when they accept the upgrade, but doesn't yet work to track the parameters when they decline the upgrade. I'll try to get that done tomorrow. Also still in the works: passing the parameters along to the TY page.

In Tech Talk we just decided it's OK to add these as activity custom fields.

OK @ehughes , that change is live on the recurring upgraded form. It should only pass through the YYYY-MM-DD now.

Hi @ehughes, I've got a patch in review to strip the time off and just send those first ten chars: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/1010700

@MSuijkerbuijk_WMF we don't have any company cards to test with, so when we QA things the testers just make a small donation (which Donor Relations can later refund), then use their own Civi record.

You can get links from a donor's CiviCRM contact summary page (I'm not pasting mine publicly as it'll let anyone reading this change my donation amount) on the right column in the 'Donor Prefs Links' section. The format will be:

https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&contact_id=CIDTOKENGOESHERE&checksum=CHECKSUMTOKENGOESHERE

OK, the redirect part of this is done - either outcome on the form (upgrade or cancel) now redirects to ThankYou wiki with the params we discussed

Related: T263282: Handled delete deleted contacts when they have contributions - eg. cid 30379649 and T205941: Investigate/ repair deleted contacts with contributions

@ehughes, when they decline to upgrade, we just send recurUpgrade=0, right (and maybe the country)? No need for date or amount in that case?

OK @ehughes, I'll pass in e.g.

@MSuijkerbuijk_WMF, I have some problems with that copy - the 'due to a technical error that affected a small number of donors' seems misleading since the failures were due to their card being declined. And the vast majority of the charges are likely to fail again, so do we really want to say we have restarted their charges and will continue charging them, when for most we will just try once more and consider them permanently failed?

Looks like @ehughes is going to make these on thank-you-wiki. The task to make our form redirect to this page is here: T359578

The real issue was with the status - should have been 'NOT IN' rather than 'IN'

OK, there were 4196 Ingenico recurrings that

• failed in Oct-Dec
• were possible to migrate from the Ingenico expots
• whose contacts did NOT have a currently active recurring

Those are attached to 4082 contacts, who I have added to the CiviCRM group 'Ingenico Q2 cancels'

Perhaps the number formatting is better done in the Acoustic UI? Or is that very difficult?

@ehughes I was just in a meeting with @MSuijkerbuijk_WMF and she brought up the fact that the TY page can set cookies to hide banners, so I guess that makes it the better option.

Oops, sorry for the mixup @ppenloglou. We're trying to get it deployed soon!

@MSuijkerbuijk_WMF I'm waiting for review on some patches before I can deploy the version with the amount and next date. If we're going to see each other in a meeting later today I can demo it from my computer!

@MSuijkerbuijk_WMF and @ppenloglou we have a simple success page as part of the flow that will have the amount and the next date on it. If you want to redirect the donor to another page, we could do that and put the date and the new amount on the URL. Or we could take the HTML you're working on and just use it to replace the simple page in the existing flow.

@ehughes I'm also going to tweak the supplied CSS a bit to make the submit button greyed out until the donor selects a valid amount

@ehughes, one question on how the form is supposed to work. There is a bit of text that is initially hidden with the NEW amount and charge date. This seems like it's supposed to appear as soon as the donor selects an amount (before they have actually submitted the form).

Thanks @ehughes, those files are perfect. I've started to adapt them for use with the dynamic content.

There's now an option to make it wait, though we haven't turned it on.

Nora, I'm reviewing Eileen's patch and I just wanted to double check what you meant by Source/Reasons. Are those two fields or one?

OK, there really is something wrong with the coworker jobs - I just noticed they're each running over and over again till they hit the limit of 50 runs and are shunted to the omni-snooze/damaged queue. There are no obvious errors in the logs. I'll try to debug locally.

I've tried running the underlying API call using e.g.

echo '{"version":4,"databaseID":9644238,"email":"ejeggleston+checkouttest2@gmail.com", "checkPermissions":0,"values":{"snooze_end_date":"2024-03-15 00:00:00", "activity_id":207627336}}' | /usr/local/bin/drush @wmff cvapi Omnicontact.create --in=json

And it seems to snooze that email in Acoustic. I'm still figuring out what makes coworker pick up 4 items from the Data Axle queue to every 1 it picks up from the snooze queue.

Hmm, looks like maybe some of these are piled up behind the data axle import job. I'll see if I can increase the priority for the snooze jobs

OK, they are deleted