Cleanup gender handling in contact import + add test

[eileenmcnaughton]

Overview

Cleanup gender handling in contact import + add test

This lays the foundation for option values to be transformed based on metadata in getParams, simplifying validation & later transformations

Before

No testing on gender_id handling and unclear expectations.

On adding the test I discovered that there were 2 types invalid values for gender

• those that fail validation
• those that pass validation but are silently discarded later on

Despite generous consideration in the validation routine only values that were an exact match for the label actually got saved to the database.

I concluded that if a value was not to be saved to the database it should fail validation - and hence the test checks both the validation and the actual import

After

The initial getParams transformation now converts the imported value to an integer, based on metadata.

In line with import handling for other fields in various import places I made it accept any of id, name, label

I ALSO made it accept name & label in all upper or all lower case. This is something that was coded into checkGender but ultimately didn't work. The way I did it is not truly case-insensitive - I might think more on that but there is some risk with non-latin alphabets - at least the way I did it won't mess with a matching font sitll matching.

Technical Details

Comments

Note that the test includes a csv file suitale for r-run testing

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

[eileenmcnaughton]

this part is an extraction

[eileenmcnaughton]

Per function comments this deprecated function is only called from import - so can fully remove

[aydun]

• General standards
  • (r-explain) PASS
  • (r-user) PASS: minimal user impact
  • (r-doc) Undecided: Would be good to update User Guide to show accepted values - not currently described.
  • (r-run) PASS: Tried importing various valid and invalid values as contact and related contact. All works as expected.

Note that imports can use 'name' but this is not shown in the Gender Options display. The result is that if the label has been changed, an import file can contain gender values that work but are not obvious that they should work. This is not limited to gender: maybe option group displays should include 'name'.

The previous behaviour did not reject 'F', 'M' etc but did not correctly set the gender. Allowing initials might be convenient for some imports but would require rules around handling labels with the same initial. The balance of flexibility and correctness in this PR seems good to me and requiring import data to be unambiguous is good.

[eileenmcnaughton]

@aydun yes good point about the docs - although the goal is ti standardise the behaviour across many fields - at which point it is more meaningful to document

[colemanw]

@aydun thanks! Reviewing PRs is extremely helpful to the project.