So with the last of this chain of patches now merged, here's how it went for me:
Tue, Feb 23
I wasn't able to install MySQL Workbench on my Debian Bullseye laptop. However, LibreOffice Base worked fine. (BTW I did have to install an extra package, libreoffice-sdbc-mysql.)
Mon, Feb 22
Hi! I can try making a donation... just looking for a link for test card numbers to use with dlocal...
Wow thanks for all this @Eileenmcnaughton! Even with a bunch of the patches not yet merged, on the master branch HEAD at this writing (898a31439725e), with a clean install using the most recent civibuild patches (b5a85eb0ddc), all tests are passing!
This now worked for me, with the latest version of buildkit in our repo. Thanks!!!
Fri, Feb 19
Just to note, as per IRC, for now I'm proceeding with the approach outlined in the task description. Thanks!!
Thu, Feb 18
Hey again... so just specifically on the security, git and CI points. So, I hadn't thought of the points you raised, and, agreed, it does seem there would be at least some additional work there... still, I would just add a few thoughts/questions...
Hi! So, thinking about this some more... tl;dr: You're right about the attack surface not being all that different, and about the need for some additional CI and branch maintenance, but I would still suggest this should be done in a new extension, especially for software design reasons, and I'm not convinced that overall maintenance cost wouldn't be less, rather than more, if we go that route. :)
Tue, Feb 16
Gonna close this now, too, with all the changes merged! Thanks much @Ejegg!
Just some first quick improvements in the attached patch. Didn't look at the payment form links yet.
The attached change uses volumes instead of bind mounts for database and queue data. Performance on Mac does seem better. Not sure if it's quite where we need it to be, though--maybe? Civi install is still pretty slow, but composer and npm installs seem fine. We're still using bind mounts for source code, config and logs.
Closing as this is basically done. :)
Mon, Feb 15
Wed, Feb 10
Tue, Feb 9
Wed, Feb 3
Tue, Feb 2
Hi! Thanks so much, all, for the detailed info here!
Mon, Feb 1
Fri, Jan 29
Some more notes about whether or not to make this a new extension (from discussions in Standup and IRC):
- Another option could be to re-purpose FundraisingEmailUnsubscribe? Some of the code there seems potentially reusable? Though it might still have to be refactored, which might be just as much work as writing new code in a new extension.
- Should code to talk to CiviProxy maybe go in SmashPig? Or maybe not, since SmashPig is first and foremost a payments library?
- Is it worth the effort to create an entirely new extension for this?
Thu, Jan 28
I would like to suggest maybe that instead of using DonationInterface for this, we create a new, separate MediaWiki extension?
Hi @Ottomata! Thanks so much for your help here!!
Wed, Jan 27
Regarding making this a part of DonationInterface, I found this in the doc about implementation: "reuse some form rendering and querystring checking code that’s in the DonationInterface extension" .
Tue, Jan 26
This is now ready to go once the schema change for Campaign Filtering (T272953) is deployed. Thanks much!!
Jan 26 2021
Jan 25 2021
Here is what I found so far:
- On staging, there is a group called Wikimedia in Review Recipients and it does take at least 5 minutes to show contacts. There are 13943 contacts in all.
- The criteria for that group is based in part on membership in another smart group called Wikimedia in Review Newsletter, and showing contacts for this second group is fast. There are only 1924 contacts in that group.
- It looks like membership in the second (base) group is just determined by the presence of the tag "Wikimedia in Review quarterly newsletter".
- Strangely, it seems membership in the first (derived) group is determined by membership in the base group, plus exclusions for "Do not e-mail" or "No bulk e-mails". So I would expect the derived group to include less contacts than the base group, not more.
- I tried to parse the form_values column in the corresponding rows of civicrm_saved_search, to double-check the details of the smart group definitions. However, I'm having trouble understanding how to interpret the string with the settings there.
- Next steps could include checking what actual queries are being run, and maybe seeing what contacts we get in a new group based on the "Wikimedia in Review quarterly newsletter" tag with the added exclusions, and checking if that's more performant.
Jan 22 2021
Jan 21 2021
Hey @awight! Many, many apologies for the long delay in replying here, and thanks so much for sharing WMDE docker dev work, that looks amazing! I really like the modular setup and also how clean the bash code is.
Jan 20 2021
Jan 19 2021
This is currently blocked due to Campaign Filtering having merged to master. We don't yet have confirmation that it should be deployed in its current state. However, it seems needlessly messy (though I guess not impossible) to merge only the patches previous to Campaign Filtering into the wmf_deploy branch to deploy only those.
Jan 18 2021
Omnipay is a library that provides a general framework for creating gateway integrations. Also, there are Omnipay implementations for numerous popular gateways, some by the authors of Omipay and some by third parties. However, the state of these implementations is uneven. Some appear to be up-to-date and have many contributors, while others haven't been updated recently and have only one contributor. Also, recurring is officially outside the scope of the Omnipay library, though it does seem to be implemented for some gateways.