CRM-18959: Import fails when custom multi-value date field is imported.

[darrick]

Different path for solving: CRM-18959
Other solution is PR-8566
Also reverts CRM-18708

The guts of the custom import have always supported importing to contact sub types (CRM-5125). However, at some point mapping the "Contact Sub Type" was dropped from the form. This PR restores that option.

[civicrm-builder]

Can one of the admins verify this patch?

[JoeMurray]

jenkins, please retest

[seamuslee001]

I tested this and it seems to work ok, the only thing i would have to say is that it will allow imports for contacts that don't have the same sub type as selected and or same sub type as the custom group. E.g. I was able to import to a contact that had no contact subtype set. To me I think we may want some validation on that part

[darrick]

@seamuslee001 I'm not surprised. I don't have much skin in the game. Don't use this functionality but was doing peer review at the request of @JoeMurray. That said it would be good to identify exactly what steps this import should take.
I.e.
For custom groups tied to a Contact Type:

• Should AJAX be used to filter the "Multi-value Custom Data" to only allow the user to select custom groups attached to the selected Content Type?
• Should the same be done for Custom Groups attached to Sub Content Types.
• Meaning if "Individual" is selected only Custom Groups attached to Individual and Sub Contact Types of Individual are selectable.
• If a custom group tied to a Contact Type is selected but then a sub contact type mapping is chosen on the next page should the records only be imported for Contacts with that sub contact type. Or should should the sub contact type not be mapable.

So on and so forth as I'm sure there are other varieties. I did add help for Contact Type and SubType copied from the import contact page.

[totten]

jenkins, add to whitelist

[eileenmcnaughton]

@darrick are you ok to fix the style warnings? https://test.civicrm.org/job/CiviCRM-Core-PR/10535/checkstyleResult/new/

[monishdeb]

@darrick is there anything left to fix ?

@eileenmcnaughton should I close #8566 ? because it seems current changes does the same with a better solution.

[eileenmcnaughton]

@monishdeb that sounds about right - @seamuslee001 is anything from your comments above a blocker to merging this & closing the other?

[darrick]

I'm on vacation. There is a work around by setting both "Contact Type" and Contact Sub Type" fields in the csv file. It would be best to delineate the use cases CiviCRM is going to support on this form and then tune the PR accordingly.

[monishdeb]

@darrick did you had a chance to look at this PR? Also can you rebase this PR as it gone stale.

Steps to rebase:

$ cd civicrm
$ git fetch upstream master
$ git pull --rebase upstream master 
// resolve merge conflicts if any
$ git push -f origin CRM-18959

[JoeMurray]

@darrick doesn't have much skin in this game. Let's us do the work.

[eileenmcnaughton]

When I look at this there are a number of small discreet code tidy-ups which seem worth pulling out, reviewing, & merging & then we need to figure out how to replicate the main part in a unit test

[eileenmcnaughton]

I'm closing this as an alternate fix has been merged -basically retrieving the sub_type from the contact id (which is required for this import I believe)