This is an easy, low-risk fix. Bringing it into sprint.

OK, this looks good. I donated at payments with utm_medium=endowment, and all the conditions were fulfilled:

• showed endowment logo on payments
• did not automatically send TY letter (used no_thank_you=Endowment Gift)
• tagged donation as financial type 'Endowment Gift'
• skipped calculating roll-up fields in wmf_donor (see /civicrm/contact/view?reset=1&cid=27211539)

Did I really say 'pretty straightforward' on a human-language-related issue? :P I think @awight approached this before and decided we should be using the language tags internally. Looks like we've got a repo set up for a fork of a package to handle BCP-47: https://phabricator.wikimedia.org/diffusion/WFLT/

So, the IANA subtag registry has an entry for 'yue' with propery 'macrolanguage: zh'.

Oh hey, we're getting some errors where the language code sent was 'yue', staged to 'yue_CN' then trimmed to 'yue_C'... Will need a slightly different fix for that one. Apparently yue should mean Cantonese, and is often encoded as zh_HK according to http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/05/picking-the-right-cantonese-la.html

Getting lots of failmail. This should be pretty straightforward, so let's pull it into sprint.

Reply:

The 'locale' has to match the correct format which two lower case letters (LanguageCode ISO) follow by a '-' and then two upper case letters (Locale). For example, en_GB (English) and zh_CN (Chinese).

The script is run and these subscriptions have been marked as active. We asked them to re-generate the SAR file, and they did, but it still had the bogus rows. They'll escalate the issue, but we should follow up next week to see how they're doing.

Sent an email to merchantservices asking them to clarify

This is all deployed, just got to check on the triggers

Deployed the fix and re-sent the damaged message. It went through fine.

I think we've tested this pretty well. Looks like it works, i.e. doesn't cause any problems. It doesn't give any speedup on long-running tasks like the queue consumer, but it should help with UI performance during peak times.

...and the index data are mostly on tables that get manipulated during the tests. We just push a lot of data around to get realistic setup for complex scenarios, i.e. de-duplication.

OK, the logo is up - just stick &utm_medium=endowment on the end of any payments link to see it. Note that it should be sticky through the donor's session, so you might have to clear your session cookie to see the normal logo again.

So, the way to add criteria is just a comma and the next condition - here's a first and last name dedupe search.
civicrm/contact/dedupefind?reset=1&action=update&rgid=15&criteria={%22contact%22:{%22last_name%22:{%22IN%22:[%22Eggleston%22]},%22first_name%22:{%22IN%22:[%22Elliott%22]}}}&limit=1

Appears to be mostly indexes. Here's the output of the modified innochecksum util from here: https://bugs.mysql.com/bug.php?id=57611&files=1

@thcipriani thanks! It seems to help temporarily, but those files grow back to consume most of the disk pretty quickly. Any chance we can increase the quota on that partition? And maybe have a nightly job to clear that file out, since none of those dbs need to persist?

Good question - I don't see anything in the TY sender restricting it to non-deleted users! If there was still an email address attached, they might have gotten the TY mail.

Weird, https://epayments-api.developer-ingenico.com/s2sapi/v1/en_US/java/hostedcheckouts/create.html#hostedcheckouts-create-payload says that

If you submit a locale that is not setup on your account we will use the default language pack for your account.

but it's returning 400 BAD REQUEST in this case.

Looks like just updating the library fixed this error message

Might just need the embedded DonationInterface code updated to the latest, which has some handling for the same situation on paymentswiki (which happened when donors clicked the phantom cancel button)

Looks like the ibdata1 file is taking up almost all the space:
root@integration-slave-jessie-1003:/var/lib/mysql# du -sh *
1.3M civicrm_jenkins_wikimedia_fundraising_civicrm_7389_1
6.7M civicrm_jenkins_wikimedia_fundraising_civicrm_7389_2
2.4M civicrm_jenkins_wikimedia_fundraising_civicrm_7389_3
235M ibdata1
5.0M ib_logfile0
5.0M ib_logfile1
1.1M mysql
208K performance_schema

Hi @Pcoombe! I had pulled the patch in to the fundraising/REL_1.31 branch of mediawiki this summer, when it looked like we were going to pull of that upgrade before Big English. Since we're staying on 1.27 for the next few months, I'll see if it's easy to backport that patch. I think a couple files moved between the versions, but the changes in each were pretty small.

OK, I found a few successfully rectified orphans from last week's test. We could extend the time we wait to rectify an orphan, and potentially catch more of them (though we have a deadline of I think two hours with the new HostedCheckouts API).

This is all ready to go out, but I'm still trying to verify that the new orphan rectifier is doing its job. Ever time it ran today it didn't have anything to do, but maybe that's just the calm before the storm

OK @MNoorWMF, @CCogdill_WMF, @Pcoombe the new letter is deployed. All the amount / currency variations I tried look good in the subject line and the body.

We could use the payment_submethod - same field as distinguishes different credit card types. Currently Amazon donations don't have a submethod, just payment_method=amazon.

Yep! In the TY letters we send the amount through a special localization library that has a lot of symbols and rules built in.

Looks like we CAN do tokens in subject lines now :) I'll do some local testing to make sure those come out right.

Note: @Ppena reminded us that we should make sure the new Ingenico orphan slayer is working.

OK @jkim_wikimedia, the Stripe import should now take all the same custom columns as check and Benevity imports, including 'No Thank You' and 'Direct Mail Appeal'.

OK @Ppena, this is now available in the report dropdown.

no - I think it has to do with the way the old GC integration does recurring. All installments in a series get the same payment ID, but a different 'effort ID'. So we're apparently not finding the right installment with the code we've got now. It SHOULD be possible to recreate in a test, though.

I guess it isn't open to any changes at all without @cwdent or @Jgreen unlocking the dbs! And when they do temporarily open it up, I think they'll want it to be edited only from devs' or pcoombe's laptops. So the best thing would be to get someone to give us the HTML and CSS they'd want changed and we can add that either via deploying code or via temporarily unlocked dbs.

easier to do now than to prioritize :)

OK, I just figured out the issue with the TY letters - I just had to add a mapping for a column with header 'No Thank You' to the logic. I'll let you know when that's deployed. I didn't see any column mapping for 'Direct Mail Appeal' either, but that's simple to add.