Thanks for the update @Damilare.

@Damilare we're seeing captured transactions on the dLocal console dated May 15th, but they are still not showing in Civi! Is this normal?

I'll include these unusual emails in the weekly admin deduplication task to prevent them from accumulating. However, there's an issue outlined on this ticket https://phabricator.wikimedia.org/T363958, where currently, we're only able to merge one set of data with the same email address. This limitation will apply to queries involving fake emails as well.

@Eileenmcnaughton check out this documentation Adriana put together to help with the LATAM NAME script. I'm happy to join a call if you need clarification!

Adding another CID 59489888 --> This donor has always been in Ireland, how would he end up in the Springlish (US, UK, and CA) segmentation list?

Update: Another odd behavior has come up with a merge 'Could Not Find Valid Value for CID'. On the bright side, the merge happened as anticipated, CID 63239146, and in case this helps, after a quick Civi forum search I found that others have encountered the same issue but when creating an event.

@Damilare thanks for the awesome news, and all the work to make this happen!

@Ejegg feel free to solve/close this phab since I was able to move the box on the DR Layout.

@jgleeson I believe this issue has been resolved!

Exciting news, thank you! Let me know when we can test it out :)

@AKanji-WMF this is a forgotten phab, sorry, and thanks for closing it!

@Ejegg it is working again, thank you!

Thanks, @Eileenmcnaughton, I'll share the good news with the admin team!

@Eileenmcnaughton, thanks for checking, I can confirm the language conflict is indeed gone. Thank you!

Oh yeah, I see it, thanks for sharing! I'm relived it wasn’t one of our rules this time around :)

@Ejegg It's working again, thank you! Can you pls share the CID that caused the deadlock? I want to inspect the query, pretty pls, thank you.

Hi @AKanji-WMF of course! Please send me an invite whenever is convenient for you.

@Eileenmcnaughton Sounds like a great plan! I can now stay late on Mondays and Wednesdays if that works for you.

FYI in case this info helps based on the issue found https://phabricator.wikimedia.org/T353971:

1. When the query under 'name & address rule' crashed Civi we still had about 4.8k donors with different emails to dedupe.
2. Three queries pulled on Friday under the 'Individual (Supervised) Name and Adress' + 50000 first matches + group + Eileen Merge-Picks, contain donors with different email addresses and those with the same emails—one set of CID examples: 70511 and 61477112 which wasn’t the case before, and thankfully these queries are working = not breaking Civi.
3. I think that the mix between the CID > used as a clause + the high number to find the first matches has something to do with the odd behavior. I would love to test it with different parameters when someone is available to stop the queries if needed.

Problem solved, thanks everyone!

Here it is: https://civicrm.wikimedia.org/civicrm/admin/search#/list?tab=custom

@Ejegg I can’t believe it!!! Thank you so much, it feels like Christmas 😊

@AnnWF Legacy interface is what we call the manual merge UI, so we're all set. Thanks again for making this happen :)

@Ejegg Thank you for the thorough clarification! I can now understand it and will instruct the team to prioritize the date which is an improvement, so thanks a bunch for making it happen.

@Ejegg Sorry if my original explanation wasn’t the most helpful! What we are looking to achieve is the capability to view the most recent donation date and amount by hovering over the CID, regardless of its source. Currently, we face an issue where accurate data regarding endowment donations is not visible unless we get into the actual CID. I can see, however, that the accurate date is coming up, only the amount isn’t reflecting the latest donation. Is there a way to have the date and the amount reflect the latest donation regardless of its source?
Mouse over pop-up view:

@Ejegg Thanks for sharing the alternative. Based on the agent’s feedback, pasting the CID into the empty field seems more foolproof, especially given our current workload. While it's not urgent, since we've defaulted to using the browser search field, if there's a chance to bring it back or establish an alternative, we greatly appreciate it :)

Thanks, guys, for all the work and the update. I'll have our team test the link and reach out if we run into any issues!

Thanks for the update, we truly appreciate you guys! @AKanji-WMF and @Damilare

@AKanji-WMF and/or @Damilare, are there any updates on this? Is there anything else we can provide? We have donors who donated via check, BT, etc, who need to be snoozed until the next fiscal year and we can’t comply until this feature is working (in the previous campaign we focused on calendar year, not fiscal). Sorry for the additional pressure, and thanks for prioritizing this task!

@AnnWF Thanks for making the opt-out editable, it will definitely do the trick we desperately need! Is there a way to add the same 'uncheck' box to the legacy interface?
{F41459195}

@Eileenmcnaughton Thank you! I'll have the team test it out, and I'll ping you if they can’t access it.

Additionally, I tested my CID 61216138 on the old 90-day 'unsubscribe link' and it worked as far as showing the correct data from and at acoustic, however, if you search for the same CID 61216138 under the snooze feature, you will see that there's no indication that it was indeed paused/snoozed!

Hi team, it appears that the Civi 'snooze' feature isn’t working! I tried to pause Adri's email, CID 56939616, for 60 days, and when I checked both Civi mailing events>acoustic data and the Acoustic console afterward the data did not show the CID as being snoozed, as seen in the screenshots below! Has anything changed since the initial issue here was reported?

@Eileenmcnaughton The issue is 100% with this scenario 'If 2 is the problem you are trying to solve then that makes sense & we can look to address that in this phab', thanks for agreeing with us!

@jgleeson Thanks for the update! Does this mean they will automatically receive the 'ty receipt' after the emails reach Civi?

Sharing one more, Adyen transaction 193358067.1 - settled on 10/4 still not in Civi. Ty!

Here's another CID 6510295 with a manually settled Adyen transaction from September 19th, that still not showing up in Civi. Adyen ref# NDNGMVGZL3PNT872, Adyen payment ref# 192515521.1. Can someone push this one through at some point? Thanks, guys!

@AKanji-WMF We can use this Collab space under notes to document this! I'll be sharing a spreadsheet with everyone’s name and permission suggestions in a bit. Let me know if you have any questions or need anything else. Thank you.

@AKanji-WMF I do not, however, I can create a spreadsheet with all the DR agents and their Civi permission needs if this helps you and the team. Please just let me know!

Adding one more example where several donations were rejected, however, a single larger donation made on the same day was automatically settled and it is not showing up in Civi! Adyen transaction# 191467831.1; CID 57537617; ticket# 1348185.

Here are some more of this week's examples:
CID 27111095 --> FR email 2_ CopyJoyoflearning_active
CID 7833909 --> FR email 2_ CopyMostExcitingThing_active
CID 7549551 --> FR_email 2_ CopyShorterRewriteHybrid_ active
CID 43956891 --> FR email 2_ CopyJoyoflearning_active
CID 6597388 --> FR_email 1_ CopyPartofTwoPercent_active (was able to complete a single donation via the second email CopyUnderThreat)

@Cstone, Kristie is on VK, is this the information you are looking for?
CID 27392606 --> FR_email 1_ control active
CID 7809549 --> FR_email 1_ shorter rewrite_ active
CID 16391749 --> FR_email 1_ lapsed

@AKanji-WMF I'm happy to confirm that the team has access, ty.

@AKanji-WMF, ok to resolve this one. Thanks for asking!

Hi, @Cstone here are some CIDs that when seen side-by-side you will notice the missing 'check box' for the opt-out attached to the oldest record when the newest is opted-in (we don’t have a way to check the box to save the newest option).
3824035 and 59716851
59675839 and 4201541

@Eileenmcnaughton, Michael spot-checked some recent manual settles and they seem to reach Civi the same day or the next so you certainly close this ticket. Thanks for checking!

I just tested and unless the prefix or suffix has been previously placed in the correct field, Civi still saves the MD as an example in the last name field instead of its respective field @Eileenmcnaughton.

@Eileenmcnaughton would you like me to create the phab?

@Eileenmcnaughton Thank you. I’ll let you know if it fails!

Surely is @AKanji-WMF, ty!

This is it, thanks @Eileenmcnaughton!

@Eileenmcnaughton, I knew about this functionality, thank you. I was talking about the Japanese family names seen here: https://docs.google.com/spreadsheets/d/1sGKnlcbjIL_rVZGQEshEPoFkw2yT1mapGcqkoVeHaIA/edit#gid=0

I believe this issue has already been addressed!

Looking at this again, the JP doc shared by David would be a great addition to an automated script, should this be a possibility. The workaround I mentioned is available for the Roman alphabet only.

This is no longer needed. This ticket can be closed. TY! @AKanji-WMF

This request is no longer relevant. This ticket can be closed. @AKanji-WMF

Issue resolved, this ticket can be closed. @AKanji-WMF

This issue has been solved, the ticket can be closed. @AKanji-WMF

The issue has already been solved, this ticket can be closed. TY! @AKanji-WMF

No longer an issue, ok to solve this ticket. TY! @AKanji-WMF

This issue still remains.

This issue has been solved, the ticket can be closed. TY!

Final Shopify reply below. Sorry everyone, I really tried...

@Eileenmcnaughton Correct, but the actual problem is that Civi isn’t keeping the latest donor's address for recurring donors, as you mentioned, when they happen to be on the right column of the deduper interface!
As shared in the screenshots, the info on the right is the latest = from 2023 and is also attached to the active recurring donation, however, the deduper will merge them but only keep the address from the CIDs on the left which are from 2020 for one set and 2017 for the other. You can see more examples in any of the DR-Dedupe Recurring Donors groups.

Latest Shopify update after escalation -->

Sharing Shopify's latest update below. If anyone has any ideas, please send them my way since I still have no clue what to do!
I made a few tests and found the issue. The subdomain does not point to Shopify. The CNAME records are not valid. The domain has an A record pointing to 23.227.38.74. The domain has a CNAME record pointing to c.ssl.shopify.com. Here's what’s needed: an A record pointing the root domain to 23.227.38.65, and/or a CNAME record pointing any subdomains to shops.myshopify.com. You will need to change the DNS records on the domain itself for it to point to Shopify which involves logging into the domain provider, accessing the domain settings, and following the instructions.