Looks like it's missing a table name - note that civicrm. entity_log_civireport has a space after the '.'

INSERT IGNORE INTO civicrm_temp_civireport_logsummary
SELECT entity_log_civireport.id as log_civicrm_entity_id, 1,
 entity_log_civireport.log_action as log_civicrm_entity_log_action,
 '' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id,
 entity_log_civireport.log_date as log_civicrm_entity_log_date,
 modified_contact_civireport.display_name as log_civicrm_entity_altered_contact,
 modified_contact_civireport.id as log_civicrm_entity_altered_contact_id,
 entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id,
 modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted,
 altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM `civicrm`. entity_log_civireport
INNER JOIN civicrm_contact modified_contact_civireport ON (entity_log_civireport.entity_id = modified_contact_civireport.id )
LEFT  JOIN civicrm_contact altered_by_contact_civireport ON (entity_log_civireport.log_user_id = altered_by_contact_civireport.id)
WHERE ( modified_contact_civireport.id = XXXXXXXX )
AND (entity_log_civireport.log_action != 'Initialization')
GROUP BY entity_log_civireport.log_conn_id, entity_log_civireport.log_user_id, EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date), entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC

Oh hey, this is done.

Legacy PayPal IPN listener can RIP. Now using SmashPig like all the rest.

Oops mepps, looks like eileen beat us to it: https://gerrit.wikimedia.org/r/427591

Instructions copied to https://www.mediawiki.org/wiki/Fundraising_tech/tools#Silverpop_Export for posterity

Dang. We need to add a whole nother section in silverpop_export.yaml (and all of the other tools yaml files) for the logging. Depending on your rsyslogd configuration, you may need to change the handlers/syslog/address key.

To test this locally, you'll need a settings file for silverpop_export. All of the python tools look for settings files in /etc/fundraising, overridden by settings in $HOME/.fundraising/.

We should regenerate all the triggers on prod with this, right?

This seems to be working fine. I deployed the settings changed and tested at least as far as making the setup calls. I got a successful redirect using the MX credit card form (which doesn't validate tax ID numbers).

Aargh, sorry, this is still waiting for the related firewall update: T191669

Here's the header currently in use on foundationwiki:

Nothing to worry about, it was just a maintenance outage on their side!

conflict between email and new dev page (https://dlocal.com/documentation.php?sec=full-api#environment)
do we use

The logic is mostly there for variable dates and target revenues. We'd have to make the country filters configurable, and store the different configurations in the db rather than a list in the code. Probably about 6 points of work total.

@Ppena, the integrations described in the links look pretty hefty, with front-end form logic and IPN listeners. Did you say there was a redirect-and-spreadsheet option too? Where is that described?

Looks like this was resolved

@Eileenmcnaughton the .htaccess changes look fine - just allowing access to the .well-known directory, and updating the auth syntax to support both Apache 2.2 and 2.4

@XenoRyet LMK when you're available, I'll show you how to suture those two files together.

@XenoRyet, the ur2oidswithmerchref file is on frdev1001. It's sorted by order id and effort ID, but it only has those two columns plus merchant reference.

@XenoRyet There are a bunch of order IDs in that file which have effort id 3 listed to refund but not effort ID 2. For example, OID 1000103169 and 1038197662. Is that intentional?

Payments-wiki will tokenize the payments up front, and add a recurring_payment_token to the queue message. The DonationQueueConsumer currently requires a subscr_id on any queue message where recurring=1. We should make it require EITHER the subscr_id OR the recurring_payment_token.

If the core CSP patch is going to take months, we certainly COULD use the attached patch and just add a new config variable with the whole set of CSP headers.

@Ottomata oh right, that might be the way to go now. Our current process does a little bit of filtering via a python script before dumping into mysql, mostly dumping bots. Can the kafka->mysql loader do some filtering?

Yeah, another instance would be great. We'd like to run both in parallel for a while to compare the numbers.

There's a core patch to calculate all the headers: https://gerrit.wikimedia.org/r/253969

That schema looks good, but I think we need to add the page title in there, unless it's already gathered as part of EL.

More notes from the user who reported this in Seamonkey (Version: 2.49.1):

Seems to be working correctly in a non-private browsing session on Firefox 58.0b14.

Postmortem: We need to have some alerts (and good filters) on our error streams. Client-side errors like these are actually showing up in payments.error now.

@Pcoombe thanks for noticing this! It's all set now - looks like they refactored the widget JS so that the loginReady event is called before the widget scripts are loaded.

But clicking on the CC type breaks. Looks like it's not finding the HostedCheckoutProvider class. Maybe this case change fix will help: https://gerrit.wikimedia.org/r/419947

Just turned the gateway on and whitelisted the page in prod. It shows up fine...

Regarding the GC refunds - all were successful except for 3 associated with a single order id. That's order 4576470192, effort IDs 2, 3, and 4. The DO_REFUND calls for those came back with code 300450, ORDER WITHOUT REFUNDABLE PAYMENTS.

The refunds for individual contributions will only show up in Civi after we get a new audit file from GC and process it.

docker-1002 now also cleaned up, but also had the 5G android test dir on a 21G disk. Seems like the out-of-space errors kicked in at 3G free too, so maybe we could dial down the reserved space from 15%.

OK, jessie-1002 and jessie-1001 are cleaned up. Was getting some untar errors on docker-1002 too, so I'll see if I can clean that up.

The biggest dir in /srv/jenkins-workspace/workspace took almost 5G (apps-android-wikipedia-test), while the whole /srv disk is only allocated 21G.