I'm leaning towards putting this in the Email Preference Centre extension. It moves us closer to having one place to manage email preferences. That landing page already handles POST requests, so we'd just need to implement the behaviour for this method https://github.com/wikimedia/mediawiki-extensions-DonationInterface/blob/830225b217f11cee801a56403096e053b18d9306/special/EmailPreferences.php#L189. The surrounding code currently expects a send_email form param but we could just hard code that to false and we should be good I think.

We'd have to open up the URL generation code to embed the direct links in the emails so it can be used elsewhere. It's currently running as part of UI hooks from what I can see here https://github.com/wikimedia/wikimedia-fundraising-crm/blob/1b3fd2641dc2780b3df87814e619540db0aa21d8/drupal/sites/default/civicrm/extensions/wmf-civicrm/Civi/WMFHooks/PreferencesLink.php#L42

Change 989243 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[mediawiki/extensions/DonationInterface@master] WIP: Add support for one-click-ubsubscribe

https://gerrit.wikimedia.org/r/989243

@Eileenmcnaughton, the API action that eventually processes the data sent as part of an email preferences update has a list of required parameters, which I'm wondering if we can put into that List-Unsubscribe: embedded param to make things easier. If not, we could probably look them up under the hood, but I thought I'd check with you first before going one way or the other. You can see the list of params here

Update: I've just found your patch here. It looks like we have everything except country. I'll add some notes on that patch.

@jgleeson the api action you are pointing to doesn't process the data sent - it just generates the url to be inserted into the message - once we have a change of the url that we want to put in the message we can update that api to return the new end point and we will only need to tinker with that one place in the code.

In order to make is such that we can change only 1 place I have made it so the api signature is to return 3 urls - the one for the user, the one-click get one &(when available) the one click post one.

We don't actually have 3 urls yet - but the callling code can be updated to the 'right' url (ie one_click where appropriate) & won't need to be updated again when we have a one-click url to use

In T354587#9451954, @Eileenmcnaughton wrote:

@jgleeson the api action you are pointing to doesn't process the data sent - it just generates the url to be inserted into the message - once we have a change of the url that we want to put in the message we can update that api to return the new end point and we will only need to tinker with that one place in the code.

I was referring to this API action https://github.com/wikimedia/wikimedia-fundraising-crm/blob/263a85ae6b5634dc3f2d07629cd4ea85a37931d0/drupal/sites/default/civicrm/extensions/wmf-civicrm/api/v3/Preferences/Create.php#L15

Yeah, I can see your new one generates the URLs, it looks good. I was thinking about ways to reduce the intermediate work between the URL generated and the final API action that will update the donor's email preferences.

@Eileenmcnaughton @Ejegg, what should we show when the request is processed? I was guessing we'd still show a formatted confirmation page, but I wanted to chat about it to make sure.

You can see what I've added so far here https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/989243

My instinct is that showing a formatted confirmation page makes it multi-use. Elliott has tested some of the emails he has received & I think some of them just show a blank screen