CiviCRM Community Forums (archive)

I had been doing this in previous versions using .csv with existing internal IDs, not importing anything new, but using it to add a tag or group, like for a mailing list pared down offline. I would have to make two passes with same file if individuals and households were both in list (three passes if orgs in there). Using dedupe on internal ID rule, fill, and mapping only the internal ID to the ID (nothing else in file, to be safe), I would choose radio button for individual contact type and the results would show me how many were "imported" (individuals) and how many were mismatched (households). Second pass with household selected and quantities would be reversed and all would be in group. Now in 4.4.5 the whole entire list runs in the first pass, but the household records have been converted to individual records. Select radio button for household type, and it will convert the entire list to households. This is a neat trick if you happen to want to convert contact types. Most of the time, though, we have an offline list with internal IDs, no contact type field in the file, and then find a need to do more work with the list in Civi. Is there some way to have import skip the mismatched contact types (to run two passes)-or else run them all (to add to group or add tag)-but not convert the types. I would really like to be able to work with a spreadsheet of mixed house/indiv records that doesn't contain the contact type field. Thanks!

Thanks Joanne! So sad to see there isn't a way to skip mismatched contact types. Scary with no notification. I'm the "fundraising guru," but I don't want to remind myself and others to always keep contact types and split the import files for all the many in and out passes I do to build, pare, and mark lists. It was a lucky fluke that I had saved a big export with that field and could use for repair. I could imagine some would miss this issue at first. So, I'll also note another oddity in case it is the first sign: even with nothing but IDs in the import, Households that have an email address on record will have the display name and sort name fields replaced with the email address when they inadvertently get converted to Individual Contact Type. If there is no email address, the display and sort name will look OKish with household name in those fields (though they have no first, middle or last names). I didn't pin it down, but some other circumstance made a small subset of my Individuals converted to Households come up with numeral 1 in the display name. All these name issues are corrected when converted back to correct Contact Types via import's hidden "feature." Individuals also retain first and last names despite their journey through householdhood.

not seeing that on https://issues.civicrm.org/jira/browse/CRM-14392 still says 4.6 - is there a related ticket, or am i just jumping the gun