dev/core#1806 - Fix import of "Radio"-style custom fields using option "label"

[seamuslee001]

Overview

This fixes a regression when using the contribution importer with certain custom-data.

Custom fields of type "Radio" or "Select" have a list of acceptable options, and every acceptable option has a "value" (OptionValue.value) and "label" (OptionValue.label). During import, each input must be checked against the list of acceptable options.

See: https://lab.civicrm.org/dev/core/-/issues/1806

Before

When matching the imported datum to the list of acceptable options, it matches only by "value" (OptionValue.value).

After

When matching an imported datum to the list of acceptable options, it matches on either "value" or "label" (OptionValue.value or OptionValue.label). This reproduces the older behavior.

ping @eileenmcnaughton @totten

[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).

[seamuslee001]

This stops it it getting caught in the default case

[totten]

I've been r-running a bit on 5.25, 5.27 (without patch), and 5.27 (with patch) -- with two different import files. (The files include nearly identical contribution records, except the column for custom_6` aka "How long have you been a donor?" -- one file references items by value; the other by label.) As expected, the patch restores support for matching by label.

I must admit - from a structural/programmatic perspective, matching by value-only makes a lot of sense... but from a usability perspective, it is much more forgiving/useful for the importer to be flexible about matching on either.

[seamuslee001]

I'm going to merge this based on @totten 's comment and that this has passed unit tests