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.
Tue, Jun 12
Mon, Jun 11
Wed, Jun 6
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.
Tue, Jun 5
Mon, Jun 4
No longer using the old ingenico audit processor, and the new one has cleanup logic.
Think we've worked this all out!
Tue, May 29
Fri, May 25
Thu, May 24
Note that fundraising is moving to REL1_31 soon, so it's not worth TOO much trouble fixing our REL1_27 branch
Wed, May 23
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.
Tue, May 22
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
Sun, May 20
May 10 2018
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.
May 9 2018
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.
May 8 2018
May 2 2018
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?
May 1 2018
Just deployed @Eileenmcnaughton's fix, and it looks like this is working!
OK, this is deployed and a test send looked good
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!
Apr 30 2018
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
Apr 29 2018
Hmm, this sounds like it would require a per-user setting to whitelist certain sources
Apr 27 2018
Apr 26 2018
@Eileenmcnaughton There was an example in the documentation - I'll forward you the email
Apr 25 2018
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.