Great, thank you @Pcoombe! @mepps shall we switch those settings over Wednesday?

We're also getting these from the audits. Not sure what the solution is there. Maybe we could go so far as to make the 'tokenizePayment' call from the Civi importer when it sees one of these?

Or we could add parameter maps to SmashPig for the necessary functions and cut out DonationInterface entirely :)

Oho, do we need to export it specifically in DonationInterface's composer.json? I think that lists a few of the other adaptors.

Let's just do some checking first to make sure all the cookies are being sent in as many browsers as we can, then we can set it in prod whenever.

No longer using the old ingenico audit processor, and the new one has cleanup logic.

Think we've worked this all out!

Note that fundraising is moving to REL1_31 soon, so it's not worth TOO much trouble fixing our REL1_27 branch

There's no traffic directed at the gateway just yet, so I just hit it with a few test requests. Seems to be working!

As far as I know, it has to do two things:

• Set hide cookies for the main project domains
• Localize and not look broken in any of the languages it supported before

OK, that fix seemed to do the trick. After re-running, the audit files logs for the first few days of May now show no missing transactions.

Think this might be it: a bug specifically affecting audit entries on the last day of the month:

Huh, there seems to be logic in the audit parser to add 1 to the final date for the logrotate stuff, which should make it search in 20180501: https://github.com/wikimedia/wikimedia-fundraising-crm/blob/master/sites/all/modules/wmf_audit/BaseAuditProcessor.php#L633

Looking at 9805352916 - so far:
confirmed still not in Civi
confirmed exists in audit file: wx1.000000657020180503.010234.xml.gz
confirmed lines exist in log file: payments-globalcollect-20180501.gz

So this is an opportunity to make the Amazon flow more like the Adyen flow, where we combine the donor details from the pending DB in a separate job before sending the data to the donations queue. The Amazon version of the RecordCapture job should first look in the pending DB, then if the details aren't there, ask Amazon.

Argh, unfortunately the re-parsed refunds are all going right back to the original installments. I think that last patch ^^^ will associate them correctly.

OK, all the first installments are un-refunded, now to re-run all the audit files for the last couple months.

Great, glad to hear it!

@jrobell I'm getting the new one. I just sent you another (marked as recurring) from https://civicrm.wikimedia.org/admin/config/thank_you/test . Are you still seeing some of the old text? What did you use to send the earlier one?

Just deployed @Eileenmcnaughton's fix, and it looks like this is working!

OK, this is deployed and a test send looked good

Hi @jrobell or @Pcoombe, I had to make one tiny correction in the unsubscribe tag - could one of you set that to 'published' please?

I added the privacy summary in the footer, and that might be all I can do.

@jrobell, Looks like we lost a LOT of the tags in the various translations of the latest thank you letter.

Thanks for the 'Beste' update @jrobell, but it looks like we lost the 'if' logic around it!

Also: check if the report-only version of the header still lets us catch the sources

@cwdent we formerly had silverpop-hosted urls in the email links, and lots of people thought they were phishing spam

Hmm, this sounds like it would require a per-user setting to whitelist certain sources

@Eileenmcnaughton There was an example in the documentation - I'll forward you the email

We seem to have settled on doing this on payments1004

Related to old audit parser, now using WX parser

OK, so one more thing happening here: When the audit script got a refund for e.g. payment 777 installment 5, it was smart enough to look at payment 777 installment 5 and see that it wasn't refunded, then send a message to the refund queue. Unfortunately, the process pulling that message into Civi would refund payment 777 installment 1. Then the next time the audit script ran, it would see that 777 installment 5 still wasn't refunded, and send another message. With all these duplicate messages, the refund queue crept up to 84,000 messages, which is probably why some still haven't gotten into Civi at all.

So, looks like in Civi all the recurring globalcollect refunds are marked incorrectly :(

Weird, those two users with anime avatars subscribe to all the Unbreak Now tasks?

Dang, this is also affecting the Ingenico recurring charge jobs. Those might be more serious - I'm afraid that if we fail inserting those donations, the next run will try to charge them again. Turned that job off for now, but we need to fix this ASAP.