Thanks @AMJohnson, that is good information.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 28 2024
Mar 27 2024
Thanks for checking @ppenloglou! So I wonder how that full real URL gets translated to the long gibberish links.email.wikimedia.org URL that we see in the screenshot, and how the long URL gets translated back to the one with the full params. If it's something dynamic I guess it's possible that Acoustic could break a link after send. Could it have to do with the fact that their email address isn't in Acoustic?
Mar 26 2024
For donor 397205, it does look like a bad link. That screencap seems to be the text-only version of the email. Has that been QA'ed? Can we check that the checksum token is there in the text-only version?
Mar 25 2024
Oops, we added this to the IPN listener but now the Civi queue consumer doesn't know what to do with it: https://civicrm.wikimedia.org/civicrm/damaged/edit?id=619453
Mar 19 2024
@AKanji-WMF it would be nice, but maybe next sprint. The checksums shouldn't expire for 30 days, so this feature can wait a little bit
Oho, our RecurUpgradeMessage is not the culprit here.
Just to follow up, we were able to change the viewport in the rendered HTML, and that change went out today.
Mar 18 2024
No issues, this looks fine
OK, I have deployed the fixes to track the parameters when they decline and to pass the parameters along to the TY pages.
Nice @SHust, glad to hear you were able to fix i!
Mar 16 2024
Still trying to replicate this on dev - I created two recurring donations with the older one a braintree one, then upgraded the second. The email correctly referred to the upgrade amount of the second donation, not the first.
Mar 15 2024
It'll probably be an improvement for the EmailPreferences page too! I'll see what the best way to change that in the rendered HTML is so we don't get a restyling flash when the JS runs.
Mar 14 2024
@ehughes thanks for the new CSS! I've just deployed it along with the uploaded image.
This is deployed to track the wmf_ parameters when they accept the upgrade, but doesn't yet work to track the parameters when they decline the upgrade. I'll try to get that done tomorrow. Also still in the works: passing the parameters along to the TY page.
Mar 13 2024
In Tech Talk we just decided it's OK to add these as activity custom fields.
OK @ehughes , that change is live on the recurring upgraded form. It should only pass through the YYYY-MM-DD now.
Hi @ehughes, I've got a patch in review to strip the time off and just send those first ten chars: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/1010700
@MSuijkerbuijk_WMF we don't have any company cards to test with, so when we QA things the testers just make a small donation (which Donor Relations can later refund), then use their own Civi record.
You can get links from a donor's CiviCRM contact summary page (I'm not pasting mine publicly as it'll let anyone reading this change my donation amount) on the right column in the 'Donor Prefs Links' section. The format will be:
https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&contact_id=CIDTOKENGOESHERE&checksum=CHECKSUMTOKENGOESHERE
Mar 12 2024
OK, the redirect part of this is done - either outcome on the form (upgrade or cancel) now redirects to ThankYou wiki with the params we discussed
Mar 11 2024
Mar 9 2024
Mar 8 2024
@ehughes, when they decline to upgrade, we just send recurUpgrade=0, right (and maybe the country)? No need for date or amount in that case?
OK @ehughes, I'll pass in e.g.
@MSuijkerbuijk_WMF, I have some problems with that copy - the 'due to a technical error that affected a small number of donors' seems misleading since the failures were due to their card being declined. And the vast majority of the charges are likely to fail again, so do we really want to say we have restarted their charges and will continue charging them, when for most we will just try once more and consider them permanently failed?
The real issue was with the status - should have been 'NOT IN' rather than 'IN'
OK, there were 4196 Ingenico recurrings that
- failed in Oct-Dec
- were possible to migrate from the Ingenico expots
- whose contacts did NOT have a currently active recurring
Those are attached to 4082 contacts, who I have added to the CiviCRM group 'Ingenico Q2 cancels'
Mar 7 2024
Perhaps the number formatting is better done in the Acoustic UI? Or is that very difficult?
@ehughes I was just in a meeting with @MSuijkerbuijk_WMF and she brought up the fact that the TY page can set cookies to hide banners, so I guess that makes it the better option.
Oops, sorry for the mixup @ppenloglou. We're trying to get it deployed soon!
@MSuijkerbuijk_WMF I'm waiting for review on some patches before I can deploy the version with the amount and next date. If we're going to see each other in a meeting later today I can demo it from my computer!
@MSuijkerbuijk_WMF and @ppenloglou we have a simple success page as part of the flow that will have the amount and the next date on it. If you want to redirect the donor to another page, we could do that and put the date and the new amount on the URL. Or we could take the HTML you're working on and just use it to replace the simple page in the existing flow.
Mar 6 2024
@ehughes I'm also going to tweak the supplied CSS a bit to make the submit button greyed out until the donor selects a valid amount
@ehughes, one question on how the form is supposed to work. There is a bit of text that is initially hidden with the NEW amount and charge date. This seems like it's supposed to appear as soon as the donor selects an amount (before they have actually submitted the form).
Mar 5 2024
Thanks @ehughes, those files are perfect. I've started to adapt them for use with the dynamic content.
Mar 4 2024
Mar 1 2024
There's now an option to make it wait, though we haven't turned it on.
Feb 28 2024
Feb 27 2024
Nora, I'm reviewing Eileen's patch and I just wanted to double check what you meant by Source/Reasons. Are those two fields or one?
Feb 26 2024
Feb 24 2024
OK, there really is something wrong with the coworker jobs - I just noticed they're each running over and over again till they hit the limit of 50 runs and are shunted to the omni-snooze/damaged queue. There are no obvious errors in the logs. I'll try to debug locally.
I've tried running the underlying API call using e.g.
echo '{"version":4,"databaseID":9644238,"email":"ejeggleston+checkouttest2@gmail.com", "checkPermissions":0,"values":{"snooze_end_date":"2024-03-15 00:00:00", "activity_id":207627336}}' | /usr/local/bin/drush @wmff cvapi Omnicontact.create --in=json
And it seems to snooze that email in Acoustic. I'm still figuring out what makes coworker pick up 4 items from the Data Axle queue to every 1 it picks up from the snooze queue.
Feb 23 2024
Hmm, looks like maybe some of these are piled up behind the data axle import job. I'll see if I can increase the priority for the snooze jobs
OK, they are deleted