Yep, the payments cluster, including our CiviCRM box, is stuck on 7.0 till at least the end of the year.

I had the file with these symbols open and it was one keystroke to fix, so bringing this into sprint.

Hi @CCogdill_WMF - This was added to the existing job that fetches the recipient information, so it should run every 10 minutes. That job sometimes fails for a bunch of consecutive runs when API calls time out, and that would cause all recipient data including queries to be up to a few hours behind.

Adyen

• only needs connectivity from the IPN listener and from civi1001 - on the payments-wiki side we just make the donor's browser POST to a URL on live.adyen.com with some signed parameters.
• Civi and maybe the listener need access to https://pal-live.adyen.com/pal/Payment.wsdl

In the interests of using the same template for the automated email and the on-demand email, the idea would be to implement this button using the wmf_eoy_receipt code. Once Civi core has better multilingual messaging we can look at moving templates for both into a real Civi extension.

OK Camille, I deployed the change. Thanks for finding & fixing it!

Here are the language statistics for people with a recurring donation active this year (only including languages with at least 100):

So you can submit the fix to gerrit, it's just that for now someone in fr-tech will have to pull the fix on to staging to send a test email.

Resolved with a change to the batch entry profile to show the 'no thank you reason' field - not quite a checkbox, but with the batch interface's button to copy the first value to all rows, it's not too much work to use.

@MNoor and @CCogdill_WMF : Do we need to omit endowment donations from these roll-up totals, if a recurring donor has also given to the endowment in the same year?

Possible upgrade for PHP-Queue: use a lua script to temporarily move data to a different structure while processing a job, then only delete the data from there when finished, a la https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/jobqueue/JobQueueRedis.php$261

Are they currently skipping the thank you email by adding a no_thank_you column to the import, or are we currently sending emails?

Hi @CDenes_WMF ! We could do the old process of pulling the translation from meta, but if you'd like, you can also use the process we've been practicing in meetings to submit a the fix as gerrit change yourself.

https://wikitech.wikimedia.org/wiki/Analytics/Data_access

@EYener to make DB queries you need to ssh into frdev1001 as eyener, authenticating with your ssh key and the yubikey (first your keychain manager will prompt you to unlock your ssh key, then when you see a password prompt in the terminal use the yubikey) . From there you should be able to use the mysql command-line client to connect to the following databases

• civicrm (a real-time, read-only replica of the main civicrm database)
• drupal (a real-time, read-only replica of the main drupal database)
• fredge (a real-time, read-only replica of the main anti-fraud database)
• dev_ prefixed versions of the above three, which are writable (by the appropriate users) and power the staging copy of civi. The dev_ copies have real donor data, but are out of date, generally by a few months.
• pgehres (a realtime replica of the main db containing banner and landing page views, named after a former analyst)
• silverpop (a database used to stage data exports to our bulk mailing house) Has some potentially interesting totals aggregated by email address, but only for donors who haven't opted out of bulk mailings.
• eyener (your own personal DB, where you can create tables)

Yep, those contribution tracking IDs look like they hit the IP Velocity Filter.

Hi @EYener, I just set up an account in Civi for you. You should be able to use the 'request new password' link to get in. Welcome to the team!

We're basically using exactly the CSS that trilogy provided - nothing is set in stone if changing it makes the donor experience better!

Ooh, funky - I guess we automatically focus the cursor there when we load the donation form. Maybe we can move that focus on loading the updonate form.

I can't replicate this on the current code.

Oops, sorry, I misread the bug report - recurring $4 donation on $10 should definitely be allowed

I'm pretty sure this is a limitation of the platform - once you create a tokenized payment, you can only use that token to charge up to the same amount.

They look interesting, but I'm not sure what they all are! Can you share what the queries look like?

@mepps That patch was mostly just an experiment - I'm not currently working on this one.

Cool, that will be helpful for generating the text-based emails. There's a German 'donation receipts' extension that has a bunch of other useful functionality, like automatically sending batches of receipts. Unfortunately, it's also focused on generating file attachments (PDF or CSV) rather than sending the receipt in the text of the email.

OK, this is deployed to production

I just reviewed the CDN Tax receipts extension to see if it would be suitable for this purpose. Looks like it's a bit too narrowly focused on Canada for our purposes, and seems to generate the receipts as PDFs.

Thanks @Trizek-WMF !