@Tsevener can you point me to the dev / ops person or group you worked with to get the apple-app-site-association file added to the main cluster for the encyclopedias?

@AndyRussG suggests that it could be data related. We could add a try-catch around the push() and log the problematic line, or at least try moving the newer audit files out of the dir and running makemissing on some old ones to see if the problem continues.

@Dbrant I just noticed in the Android code that it was only bouncing 'donate.' subdomain links back out to the external browser. I just made a pull request in GitHub to do the same with 'thankyou.' subdomain links as well. Perhaps the 'thankyou.' subdomain also needs redirects in iOS?

Thanks @LGoto, it looks like the only thing left to do is @Tsevener 's suggestion here: https://phabricator.wikimedia.org/T259312#6361482

I did a couple chore-like things this sprint

• trawled the error logs and found unsubscribes that needed requeueing, sent those back up
• re-queued deadlocked stuff from the damaged message table

Sent an email to Evelyn with our API calls and responses. The initial communication from Ingenico sounds like they're confused about what API we're using:

Oops, good catch @MNoor_WMF. I think this will be a quick fix - we're probably pulling the 'id' column of the new table as opposed to the 'entity_id' column which links to the employer's ID in the contact table.

the first 10 or so rows all have integers with no decimal point in the 'all_funds_donation_count' column

@KHaggard that first one failed, but I kicked it off again and it uploaded correctly the second time.

@DStrine I think it's just the extra javascript that @Pcoombe mentions above.

After a quick chat with @LGoto and @JMinor we decided it would be best to prevent the whole thankyou.wikipedia.org subdomain from opening in the app. @JMinor says for iOS it will be best to try editing the entitlements file first. I guess with Android it would have to be in the manifest.xml?

I talked this over with the fundraising tech team, and we'd prefer not to change our workflow. It might be a longer command-line than usual, but if we can specify all the configuration with --project-branch options, we'd prefer to keep developing and testing against the 'master' branch of DonationInterface and FundraisingEmailUnsubscribe.

After cherry-picking the PHPUnit updates to REL1_35 of FundraisingEmailUnsubscribe, the 'check experimental' on the merge from fundraising/REL1_35 back to master is closer to passing:

It seems a bit odd to create fundraising/* branches of ParserFunctions and Vector, which fundraising has never customized. And I think the FundraisingEmailUnsubscribe fixes for the updated PHPUnit should be merged into the REL1_35 (non-fr) branch, since they're necessary to work with the version of PHPUnit that's in REL1_35 of core.

I went ahead and deleted the current blank rows. Here's the task to make sure new ones don't creep in: T264944

Here's a first stab at it: https://frmon.frdev.wikimedia.org/d/Pq1YNMviz/fundraising-overview?editPanel=35&viewPanel=35&orgId=1&refresh=1m&from=now-90d&to=now

Looks like this might be gone in a future version of cURL, but we probably have to do something about this in the meantime.

We should be able to restart them - just looking at the first donor you list I see the contribution_recur row has a NULL in the next scheduled contribution date column, which is weird. Tomorrow we can try to find all the affected ones and restart them, as well as try to figure out how they got into that state.

We see 742 successful transactions in a recent run, so they're not all failing. I do see some errors in that log that are worth more investigation, like this one:

Hmm, looks like the blanks are actually stored in the DB rather than being introduced in the export. I can probably just delete those rows, then look at the process that pulls the info in from HEPdata to see about discarding them on the way in.

I'll keep looking at why we might have completely blank rows.

We just deployed the column change today, so the export tomorrow morning will have the 'subsidiaries' column deleted and will have the ID and Name columns prefixed by employer_.

Hi @MNoorWMF - So a lot of those 'bad links' are actually working. Spaces are valid characters in URLs, though they can confuse Phabricator's auto-linkifier.

There's some feature detection in the CentralNotice.kvStore library, but it's not fully exposed:

I see there's some inline style with this:

For testing purposes, this link should give the mobile-ified version of the page:

We hardly ever use postal code, so I think it's OK if we either just filter out invalid chars or just blank the field when it's invalid. We shouldn't let it stop the imports.

As @Pcoombe said in IRC, qqx is a message testing language code - uselang=qqx will show the message keys instead of the translations.

Probably has to do with the logging context we initialize when we start the recurring payments charge job. I think we might not have changed that when we added Adyen charges into the mix.

The fix has been deployed, but it looks like Carte Bancaire isn't actually working on the Adyen side, so we've disabled the button for now.

Same cards in each country as Ingenico?

@MNoorWMF if you have an example of a bad link handy, could you paste it here?

Thanks @JMinor ! I think we're going to be fine with opening the TY page in the app (assuming RESTbase is now working). I'll look into updating that file server-side too.

Deployed and tested to be working.

After rolling back @mepps's DonationInterface change and leaving the updated skin on Adyen Live, I see a cleaned up one-step form. Still has some logos we might not want.

I published the latest skin to live from the Adyen side and now step 2 looks a lot better but there's still a step 3.

This is deployed, but there does seem to be a step 3 added now:

@EMartin - from the code it looks like you should only need the base 'Access CiviCRM' permission to hit the CSV upload form you've been using at /civicrm/fredge. What does Thomas see when he tries that? Does he have a Phab username?

Oh darn - I just realized that minor patch doesn't actually solve the problem. Those limits are only applied to staged_data, and that doesn't include the 'values' part of the array set in define_transactions, where this string is coming from.

Two modules that occur to me as easy-ish to start with would be the exchange rates updater and the large donation notifications.

Ah yeah, the idea was to make that work as a batch but we never quite coded it up. The only batch action that actually works is deletion.

The API documentation describes the limit as 256 chars: https://epayments-api.developer-ingenico.com/s2sapi/v1/en_US/java/hostedcheckouts/create.html?paymentPlatform=ALL#hostedcheckouts-create-payload

OK, I tested locally and was able to reproduce the error locally with the patch rolled back, then check that it works with the patch applied.

Just going to re-open this till we can reproduce the error and check that the patch actually does fix it