User Details
- User Since
- Oct 8 2014, 11:22 PM (517 w, 1 d)
- Availability
- Available
- LDAP User
- Ejegg
- MediaWiki User
- EEggleston (WMF) [ Global Accounts ]
Yesterday
Tue, Sep 3
Wed, Aug 28
Hi @krobinson, @AMJohnson , @EMartin and everyone else following! We just deployed the iDEAL 2.0 changes to production. The first time I loaded the form it took ten seconds or so (I think for the payment method lookup call we make to Adyen). On subsequent loads our name/email form loaded rapidly.
Tue, Aug 27
Update - looks like last year's stats are the outlier. Looking at July for 22-23 we see similar numbers to this year.
Some of those new ones are still a bit hazy on where the process breaks - at least one says PayPal is not working, which would mean they likely can't load paymentswiki at all. But at least one mentions filling out their name and choosing a bank before the process fails. That could point to iDEAL 1.0 problems. We have some changes in review to implement iDEAL 2.0, but nothing deployed yet.
Thu, Aug 22
OK, I've just updated the trxn_id on those two recurring subscriptions and re-sent the damaged messages from July and August.
Hi @AMJohnson, they should indeed be 'cancelled by merchant'. Here's one we cancelled this morning after not getting any donations since May 22: https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=60859723&selectedChild=contributions
Wed, Aug 21
Tue, Aug 20
Looks like there are just 2 subscriptions getting these issues - maybe just update the data to match the subscr-id in the IPNs
So the big difference with payments-wiki is that we only serve it over IPv4, not IPv6 - we might need to revisit that decision.
Hah! Nice catch, @Pcoombe.
Fri, Aug 16
Thu, Aug 15
This is deployed - now we watch for failmail!
I'll try to get a patch ready to add more fields to contribution_extra (see T372468: Finalizing Gravy fields in Civi)
Wed, Aug 14
@MSuijkerbuijk_WMF this is available for testing at
@MSuijkerbuijk_WMF this is available for testing at
Mon, Aug 12
Hmm, we had some code to truncate before we tried to create the entities in the Civi API, but that code was removed in the big queue refactor. Maybe we need to add it back?
I reopened the original issue we filed for that: https://phabricator.wikimedia.org/T205316
New UI has the same issue
I had requeued the failed job using the damaged message interface, but since there was a nested array that interface broke it. We would need to update the damaged message UI to fix that.
I just checked recurring record statuses for all the failed rescue IPNs from this month, and they are all cancelled. Closing as done.
It looks like this year's banners have the 'already donated' link which I didn't see in one of the banners from last year. That link seems to set a week-long banner-close cookie rather than the hour-long banner close cookie set by the close button.
So this query seems to be focused on just the last entry in the log: I see a lot of
event.l[cardinality(event.l)]
Aug 6 2024
OK, this script has been run. All were successful except for the ones that were already refunded or charged back.
Aug 5 2024
@MSuijkerbuijk_WMF one more thing we'll need before this goes live: T371848
Waiting for DLocal to reply to an email asking about format to send state to API.
So we want a state dropdown for India, I guess. I'll use the list I found here if that looks good: https://www.drupal.org/node/2471497
The donation also seems to be recorded already, directly from the recurring charge job. We could also check whether the gateway_txn_id exists in Civi before throwing this error.
Aug 1 2024
Jul 31 2024
Screen if they click the 'No, but I'll set up an annual gift':
Jul 29 2024
Yep, those are all-time counts
Jul 23 2024
@Dwisehaupt this might be a fr-tech-ops task. looks like the batch input screen might just post back a zillion POST vars (#_of_columns x #_of_donations). Do you have any concerns with setting that PHP variable limit higher in php.ini, to e.g. 2000?
@krobinson Here's what I can get for languages with a quick query on the contribution_tracking table:
select language, count(*) from civicrm_contribution_tracking where utm_medium='endowment' and contribution_id is not null and language <> 'en' group by language order by count(*) desc;
language | count(*) |
sv | 21476 |
ja | 375 |
fr | 94 |
it | 35 |
es | 34 |
cs | 31 |
es-419 | 16 |
pt-br | 15 |
da | 10 |
de | 8 |
nb | 7 |
nl | 6 |
he | 3 |
pt | 3 |
ru | 3 |
ro | 2 |
zh-hans | 2 |
en-gb | 2 |
ca | 2 |
Jul 22 2024
Sorry for the delay reviewing that merge! I've finished looking it over and smoke testing locally, and have given it C+2.
For a few years now, we have been running a daily job that marks any active PayPal recurrings as 'Cancelled' if they haven't received any donations in 90 days. We wrote that before we had the ability to connect to PayPal and actually cancel it on their end.
Jul 19 2024
Jul 18 2024
Jul 15 2024
OK, the logic is deployed to make sure they all are tagged with the main org record for PayPal Giving Fund (3729480). I started using the 'Move contribution' action from the ... menu on the contribution list, to move the existing donations. I moved all the ones from this year. Do we need all the previous ones moved too?
Jul 11 2024
We tested this a bit in tech talk yesterday and Eileen posted some feedback upstream: https://lab.civicrm.org/dev/core/-/issues/5340