Importing to checkbox field updates incorrectly

Reproduced this regression on https://wpmaster.demo.civicrm.org/ with 5.55.alpha1 also reported on 5.51.1, 5.53.0:

• Create checkbox custom field with option values of 1,2,3
• Import to this field
• Observe that values in db are now 0,1,2

Pattern:

"1,2,3" becomes => "0,1,2"
"2,3,4" becomes => "1,2,3"

Same behavior exists using labels e.g. Red,Green,Blue.

Importing a singular option value e.g. "2" works as expected.

Ref: https://chat.civicrm.org/civicrm/pl/x1imgh3affbmfb4o9b6ei6fx4h

changed the description

added regression label

added sig:bug label

added triaged label

added comp:Import label

I just tested this & could replicate on contact import but not contribution import. Investigating

Yeah, the regression occurred on contact import for me.

I'm also experiencing this regression. I'm importing contacts. I have a custom checkbox field with text-based values and nothing gets imported for the given field.

I traced the problem to the CRM_Contact_Import_Parser_Contact->formatProfileContactParams() function.

Specifically, for a custom checkbox field, that function passes $value (representing the value being imported) to the CRM_Core_BAO_CustomField::formatCustomField function here.

The problem is that CRM_Core_BAO_CustomField::formatCustomField is defined to expect $value to be an array in which the keys are the real values to be inserted into the database. But instead, it gets an automatically keyed list of values passed in by the user importing the data (in other words, with keys 0, 1, 2 etc).

As a result, CiviCRM will always insert values of 0, 1, 2, etc. depending on how many values you pass in, rather then the actual values that should be inserted.

I can't be sure, but I think this regression was caused by b248c095b12 .

I think the answer is to modify CRM_Contact_Import_Parser_Contact->formatProfileContactParams() before it calls CRM_Core_BAO_CustomField::formatCustomField and change $value. Specifically, we should detect when $value is an array, determine if it's an array of actual values (in which case it should be re-made so that the keys match the values) or if not, lookup matching values and re-make it so that the array keys are the actual values and the array values are whatever is passed in.

@eileen - does that seem right?

@jamie I came to the conclusion that all the custom field formatting in the Contact import was redundant - I will elaborate more on the PR https://github.com/civicrm/civicrm-core/pull/24848

mentioned in commit e99a2a1a

mentioned in commit b3c3e52b

changed milestone to %5.55.0

closed

mentioned in commit 1513cd47

I did test this PR and it did seem to work for me, but now I'm getting another problem with checkbox fields on import. I seem to be able to solve it with this:

https://github.com/civicrm/civicrm-core/pull/24902

reopened

added has-pull-request label

I made one more PR - seems as though you can no longer import a contact with an address in which a county is specified by name.

I've only gotten as far as the unit test:

https://github.com/civicrm/civicrm-core/pull/24917

See the PR - I found issues with the unit test & with those fixed the county import worked in the test

Closing - there is another probable issue @jamie has found but we don't have steps to replicate at the moment so a new gitlab for that is the way to go IMHO

closed

mentioned in commit 6d10f1dd