dev/core#3850 Fix checkboxes handling for custom fields in contact import #24848
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
dev/core#3850 Fix checkboxes handling for custom fields in contact import
Before
Per https://lab.civicrm.org/dev/core/-/issues/3850 multiple item checkboxes are mis-saved in Contact import
After
Save correctly (description on gitlab of steps)
Technical Details
This code has 'evolved' from what was originally probably a copy & paste of the form layer. The function
formatProfileContact
was used to to prepare values that had been lovingly crafted into form-like format to be passed to the `BAO_Contact::create'.Over time the function started to call the api instead of
Contact::create
making much of what was happening informatProfileContact
redundant. Because that function was serving multiple masters & crazy-complex a copy of the function was taken & it was moved onto the import class where we could start to unravel it (knowing ti would only affect import). However the function still contains much code that grew up for it's other use-cases, rather than import.Paralell to that
$params = $this->getMappedRow($values);
evolved into a function which generally took the input & returned it in an api-ready format.Hence the go-to solution for any import data format related issues is to try removing code :-)
In this case the worker function
CRM_Core_BAO_CustomField::formatCustomField
is already called in the api - but along the way handing was added for exactly this type of field - so if we just let the api do the work the bug is fixedComments