Export fix on long custom fields

[eileenmcnaughton]

Overview

Fixes a code miss whereby improved metadata meant the code intended to handle custom
fields was not being hit, adds tests for fixed variant of a long option value

Before

Handling for 'data_type' parameter in the export class is also missed because it was based on the assumption that 'type' was not set. However, quite some time back we standardised custom fields to load the correct type in their metadata.

After

Metadata fixed, resulting in custom fields with longer option values exporting - per test

Technical Details

Needs a rebase once #18114 and #18147 are merged

Comments

@mlutfy

[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]

I'll wait for #18114 to merge before fixing these tests

[demeritcowboy]

I started looking at this but got confused. For one, I was able to export long text ok without the PR, but then realized that it's different for select than other types. So this is about select. But then also, the value it stores is the value, like the number 1, but it exports the label, so it will let you have a field defined with length 255 (or less) with option choices with labels of length 512, and then export still fails even with the PR.

But, if you do have a longer field defined, then the PR makes it better and it will export it.

I was also confused about the current_employer part, but it seems to export it ok.

And there's other items in here like tags and participant fields that I wasn't sure if they were related, and I didn't look at those.

[eileenmcnaughton]

@demeritcowboy thanks for looking - this builds on #18147 which is the source of the other changes - basically it switches to using less guess work to get field lengths. I have been focussed on that with a plan to later rebase this. I think this kicks in when the label on your option value (or combined labels) is super long

[eileenmcnaughton]

@demeritcowboy I think the trick to reproduce is to have a select field of type number with long labels but perhaps with @mlutfy being back now....

[demeritcowboy]

I can reproduce it, and the patch helps the problem, it just doesn't fully fix it. You still get the error if the custom field is defined to have size e.g. 255, but the option choice label is big and the value is short.

For the other stuff I wasn't aware of the duplication with 18147.

[eileenmcnaughton]

@demeritcowboy I'm happy with 'helps' as a criteria as it covers the bug report & the PR & fixes the fact the code intended to address this is being bypassed

[demeritcowboy]

Ok - it helps.

[eileenmcnaughton]

@demeritcowboy I've rebases so what this actually does is visible now - basically moves handling that was written for the custom fields to where they actually hit it

@seamuslee001 I think @demeritcowboy's testing from earlier is still valid

[demeritcowboy]

I retested with the rebased patch and yes it seems the same as before - it makes life better just not a complete fix.

civicrm_custom_field.text_length > length(option_value.label) ==> OK

civicrm_custom_field.text_length > length(option_value.value) && civicrm_custom_field.text_length < length(option_value.label) ==> NOT OK (e.g. field is varchar(16) but label has 17 chars)

[eileenmcnaughton]

@mlutfy are you OK to merge based on the above - ie it partially tackles the issue (the use case from the issue) & fixes the code so at least the right lines are being hit

We'd need to extend the test further for the one @demeritcowboy hit