Resolve Issue #3927: contact import failure of different related contact typess

[brienneK]

Overview

This PR resolves issue 3927, which flags that the Contact Import was failing when the related contact was of a different contact type as the main contact being imported.

Issue replication steps:

1. Create a csv file to import that, at a minimum, has a column for each First Name, Last Name, Email, and Organization Name
2. Go to Contacts >> Import Contacts
3. Upload the test csv file, check the box if your file does include column headers, make sure Contact Type is Individual, For Duplicate Contacts select Update, and then set the Dedupe Rule to Email - Unsupervised. Click Continue
4. On the field mapping page, select the First Name, Last Name, and Email options from the corresponding drop down menu next to those columns. For the column in which the organization is listed, select Employee of and then Organization Name from the secondary drop down menu that will appear after the first selection. Click Continue
5. Click Import Now on the next screen
6. After the Queue Runner finished, click Download Errors from the Invalid Rows (skipped) row from the table on the Contact Import screen
7. The reason given on the errors download is "Mismatched contact type."

Before

When importing contacts when the main contact was an Individual and the contact related contact was an Organization (i.e. to create an "Employee of" relationship on import), the import failed with a reason of "Mismatched contact types." This scenario was caused by the dedupe rule for the main contact being applied to the contact related contact as well.

After

With this patch, the Contact Import no longer applies the same dedupe rule to the contact related contact if it is of a different contact type than the main contact. As a result, the import does not fail when establishing a relationship between two different contact types on import.

Technical Details

The original code was not comparing the contact types to determine which dedupe rule should be applied, so this patch initiates a comparison of the contact types via $this->getSubmittedValue('contactType') and $params['contact_type'] and then makes an APIv4 call to DedupeRuleGroup to get the id of unsupervised rule that corresponds with the correct contact type.

This PR also includes modifications to testImportParserWithEmployeeOfRelationship. This test was passing both with and without the above changes, as it was not actually testing the dedupe portion of the import. Previously, this test did not set an email as part of contactImportValues for deduping the main contact or pass a 'dedupe_rule_id' to $this->getUserJobID so the dedupe rule was using the default value of NULL. By modifying these aspects of the test and using an APIv4 call to get the $ruleGroupId, this code more accurately tests importing-and deduping- contacts of two different types.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

Thank you for the patch & test @briennekordis - your explanation is really clear & makes this an easy review