@Lars Here is the error report for a recent Chariot Organization import: https://civicrm.wikimedia.org/civicrm/search#/display/Import_4084/Import_4084?_status=ERROR

Also screenshot of the errors:

Import file saved here: https://drive.google.com/file/d/1RO9raFndUn41SEiPYBiEhFNQc1_QMkAY/view?usp=drive_link

Let me know when they are ok to add/import after you've taken a look. Thanks!

@MDemosWMF Thanks for this, having the error details and everything else makes it easy to zero on in the problem. I should be able to resolve it next week.

If you want to go ahead and import these now, that's fine — or if you can wait until the end of the week or so, it should be fixed so it works without having to create the orgs beforehand.

@MDemosWMF Is that error message "Did not find exactly one Organization with the details..." ever useful to your team for any of the other imports? Is it a useful check to see if we might be creating a duplicate organization otherwise? Or should we just get rid of that check entirely, if isn't serving any need and is only causing annoyance?

@Lars I don't believe I have seen it before, or if I have it has been a long time. I think this error when it shows up for not creating any record at all is more of a hinderance because we want it to create the record if one doesn't exist. If it has the same details as something already in Civi the import should dedupe based on the dedupe rules in place so I don't see it as having much use right now.

I will go ahead and import the ones above!

@MDemosWMF We'll take that check out then, which will make things simpler.
Working through the code here reminded me that we discussed earlier how the dedupe rule selection didn't seem to work for organizations (I think). That's by design, as we override some of this logic in our custom code for organization contacts. Currently, we basically implement org name or nickname (unique match) with a fallback to the selected rule if no match found, but with this change I'm working on here we will instead have org name or nickname (first match) with a fallback to the selected rule if no match found. Does that make sense to you? Do you use the same dedupe rule for all imports for organization contacts or does having this overridden cause issues because you want to select the rule in some cases?

@Lars It looks like we have the unique match rule for fidelity and Engage Organization import (below), but for Benevity we have the "first match" rule like you mentioned. I guess I am slightly confused on the difference between the two?

@MDemosWMF It probably makes sense to standardize, unless there is a specific reason to have them be different.

First match will just search for matches and use the first match found (the lower contact id). Unique match will work if there is one contact that matches, but if there is more than one, it will throw an error. So unique match is nice in that it forces you to clean up duplicates and it avoids potentially adding a contribution to the wrong contact if you match two who are not in fact the same organization, but the downside is potentially more rows throwing errors and more work to dedupe. If you aren't having trouble with the Fidelity and Engage ones using unique match (and you aren't seeing the error above due to there being multiple matches), then it probably makes sense to keep doing unique.

@MDemosWMF Just flagging that even if we're thinking about changing to using the Chariot API for these, I'd still like to make a decision on the above and finish up this change, as it isn't really a Chariot specific problem, that's just where it showed up.

Change #1235422 had a related patch set uploaded (by Lars SG; author: Lars SG):

[wikimedia/fundraising/crm@master] Refine checks for 0 or 2+ organization matches in imports

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

Change #1235422 merged by Eileen:

[wikimedia/fundraising/crm@master] Refine checks for 0 or 2+ organization matches in imports

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

@MDemosWMF This has been deployed, so you should now only see errors if there are 2+ organizations that match, while if there aren't any, the organization should be created as expected.

@Lars That's great! I will keep an eye out when I process this week.