@Eileenmcnaughton I don't find an associated patch or see a comment explaining this in review?

A note that 2416641 got merged to 29131997 which doesn't explain the missing deletion. 20904192 also does have a civi contact, but again, this doesn't explain them existing in silverpop.

I actually don't know that I have Zendesk access @MBeat33. That might help as I track this down. Because these contacts don't have Civi contacts I'm struggling to find more data on what happened. Could they be RML contacts?

Ah thanks @KHaggard!

@KHaggard I don't know which email to search for because forgotten contacts have their emails deleted. How did you find the email address?

@KHaggard how do you search for these contacts on the suppression list? I was trying to look into this but without the email from civi, I'm not sure how to find them.

Removing my name so someone else reviews the patch above.

Notes based on @Ejegg's feedback:
To know that we need to add the monthly convert extension in Mustache.php we need to know that

• • The current country is in MonthlyConvertCountries
• No other monthlyconvertvariant has been called
• The current adapter is one that should have recurringConversion enabled

Where showMonthlyConvert() is called is pretty late in the code to add the resources.
Potentially we could move this higher up.
There's a lot lot of logic in that method it'd be nice not to have to repeat.

@Ejegg is recommending we use the showMonthlyConvert method in gatewayadapter then getResources in Mustache.

@KHaggard That should be doable! Moving back to Doing so we remember to do this.

@Eileenmcnaughton is this the same task @Ejegg and I fixed last week?

Great @KHaggard! I think our final step would be to send two of opt-out lists going forward?

Now I'm wondering if a good place to put this is in readConfig, or at least to put in an option to read an extra config. However, the issue is if we have two variants, the scripts of one would overwrite the scripts of the second.

I just realized I assumed that this task was about making monthlyConvert the default and then being able to turn it off. Just in case, it occurred to me another way it could be read is being able to turn off access to the variant itself. Either way, my questions about where to put the code will persist.

Yup I was basing my guess on your fix,

This looks like it may have been a php version issue? I wasn't seeing the same error on my local civi.

I might take a look at this tomorrow.

Even though there are success messages above, I missed them because the "ERROR" seemed troubling.

We'll use the rc version.

Thanks @KHaggard! I'm putting this in done on this sprint board but not closing it for now to reflect that fr-tech has finished our side within this sprint.

Moving to done since it's almost the end of the sprint.

@Cstone did you test the final patch?

Thanks @eileen! Now I just have to figure out how to apply the patch in my civicrm-docker :) instance.

Just wanted to update that we had a great conversatoin with @bsisolak, @KHaggard, @Eileenmcnaughton, @Ejegg, and @DStrine about this. How did it doing the import to load the field for the suppressed contacts?

@Eileenmcnaughton did you fix the triggers?

I can confirm form chooser still gives me Ingenico.

It looks like the upstream patch is currently failing CI. The reason doesn't look super relevant but I'd be curious what's going on.

@Eileenmcnaughton do we know if other contacts haven't had this field been updated?

Thank you @Aklapper!

The patch is up for review but after +2ing we'll still need to do some testing. Just putting it in the review column so people know that action is needed.

Based on talking to @MBeat33 and my own testing, this is ready to go. It's such a small amount of text that there's no difference between language variants--at least with pt and pt-br which I tested.

We've been exploring this in tech talk and unfortunately there's a lot of trickiness. Basically, the current fix will allow more donors to see translations but it will actually block some from seeing further localization, like in the case of Brazilian Portuguese. I updated my patch to get the currency translation working again but we may want to look again at whether there's anything that we can do on the mediawiki end.

@bsisolak Thanks for the quick response! At this time, we remove all contacts on the suppression list from our upload to the main db. The issue is that it does not go back and update the pre-existing contacts. My understand of the linked documentation is that there's a way to import the list of suppressed contacts to the main db with opt-out selected so that it just updates the contacts that are already in the main db. We do dedupe by email already for the export to silverpop. The other option would be to delete the contacts from the main db. It sounds like @DStrine has set up time for us to talk about this further.

My next step will be to try only converting the $locale for the unsubscribe link because otherwise I don't think it needs reformatting.

Hm so what's happening is that l10_currency needs the country which I took out to make unsubscribe link work..

It does @KHaggard and this would cover any contacts that were put on the supression list from Civi. Basically, what needs to happen next is for trilogy to have another scheduled import of the suppression list (assuming they import it?) to the main db where they just check "Opt-out contacts".

Ooh! From https://help.goacoustic.com/hc/en-us/articles/360042858094-Master-suppression-list

@Ejegg has suggested we might not be able to update this field. I'm reading through https://help.goacoustic.com/hc/en-us/articles/360042685114-Opt-out-and-suppression-settings and https://help.goacoustic.com/hc/en-us/articles/360042858454-Import-a-database to try to figure out if we can or if there's a way for contacts on the suppression list to be opted out.

Ahh yeah my brain spaced. I updated the patch, thanks @Pcoombe!

Thank you @Pcoombe!

@Eileenmcnaughton @KHaggard :). It's exciting to find a possible way forward! Is there anyone else we should ask about how the status field is being used before moving forward?

Does this field not reflect what's on the suppresssion list? Sorry I don't know much about silverpop.

I wonder if this is helpful for this: https://help.goacoustic.com/hc/en-us/articles/360042857374-View-opted-out-contacts-in-queries?

Hmm here's why that doesn't work: https://help.goacoustic.com/hc/en-us/articles/360043570933-Opt-in-an-opted-out-CRM-synchronized-contact.

I'd made the spacing change in code but it got overwritten by translate wiki. Can anyone with the right privileges go to; https://translatewiki.net/wiki/MediaWiki:Donate_interface-amount-legend/fr and add a space to the end of the text there? I'm pushing out the capitalization changes now but not the text change.

@Eileenmcnaughton are we not able to delete contacts from silverpop databases? I guess if I'm understanding the problem, once contacts are added to the suppression list we won't email them, but they're still in the main database. Are these separate enough that they could be on the suppression list but not in the main db?

Thanks @Eileenmcnaughton I've stared at this a bit today and it looks safe to merge but it has a merge conflict.

@Ejegg my read of the unsubscribe code is that core mediawiki uses fr instead of fr-fr for language codes so we probably want to change what gets sent from civi.

@DStrine, here's the latest without the next step text.

From @Eileenmcnaughton, once they're opted out, we stop pushing the contacts up to silverpop. The fix here would be to push them up but add suppression data to update their records. So, we'd add a silverpop filled called "suppressed" and we'd have to add these contacts to the regular export with suppressed=true.

From @DStrine, the next step here is removing the smaller "Next step" text.

Thanks for checking on that @krobinson! So now we just want to confirm the fix is to change how the url is generated and not to change how mediawiki interprets uselang for unsubscribe.

Okay so I'm wondering why we're just hearing about this from donors. It appears to me that this is larger than just french. Basically, to get the language it looks in the db for preferred languages which is in the format XX_ll where XX is country code and ll is language. We convert this to the "wiki way" which just makes it xx-ll. But the unsubscribe page only accepts the second half as a param based on my testing so spanish wouldn't work either. The fix is likely to change how the parameter is passed to build the link but I want to make sure nothing has changed recently that impacted how this works.

So based on the code, this should mean somewhere locale is getting passed to the thank you module as "fr-fr" but I need to figure out where.

@krobinson I did, thank you! I'm just trying to figure out where the extra fr- is getting generated.

So I'm not seeing much in those contacts. They're language is set to French (France) which appears correct. In the code, the unsubscribe link is built from $mailingData['preferred_language'] and then using wmf_common_locale_civi_to_mediawiki($locale) to convert it. That function just converts it to lower and replaces underscores with strtolower( str_replace( '_', '-', $locale ) );.

This is how it looks for ideal:

Also this might be a separate task but we don't have a link to Adyen ideal on the vagrant payments wiki home screen.

Here's how it looks now in test. Next steps are to test the ideal form (done) and check the new skin code into git (done).