Remove phone_type, im provider handling form export that seems to be doing nothing

[eileenmcnaughton]

Overview

A lot of the difficult code in the export class is around handling im fields and phone type fields - however, I couldn't find any instance where is was less broken with this handling in

Before

Some bugs exist in im & phone handling

After

Bugs not changed. Less code

Technical Details

@lcdservices this is kind of a challenge to you to find something that is broken by removing these lines. I'm currently seeing a few oddities that I don't have well documented but none seem to be worse without this code

Comments

If you find something I'll add a unit test :-)

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

[lcdservices]

@eileenmcnaughton I applied this PR and ran some tests. I created a contact with a couple IM and Phone values. Here's what I found:

• when exporting primary contact fields, the primary phone/IM values were exported properly. however, the phone type and IM type columns exported the IDs, not the labels. Also, there were two columns for the IM type: IM Provider and IM Service Provider
• when exporting select fields, I included "primary" fields and location/type specific. the phone fields were fine -- however, there's no option to export the "phone type," and that's what we would expect may be an issue. for IMs, if selecting a specific location type and IM type (e.g. IM - Main - Skype) -- the screen name and provider columns exported properly. however, if exporting "primary" -- the screen name was correct but the provider name exported as an ID instead of the label.

So it looks like there are still issues.

[eileenmcnaughton]

@lcdservices was it worse with the patch - my impression was it doesn't quite work & the removed lines are neither part of the fix or the problem

[eileenmcnaughton]

Hmm I tested 5.3 and found that

1. for contacts with a phone type their columns were all misaligned with an 'extra column'

[eileenmcnaughton]

The above misalignment is the same in 5.4 & master but with this patch I get a small regression

[lcdservices]

@eileenmcnaughton I reran my test against current master and the results were better than with your patch. Without your patch -- the IM and phone type labels were exported as expected, not the IDs. With your patch I get the IDs, per my earlier notes.

[eileenmcnaughton]

Thanks @lcdservices I can see the 'right' fix now - it will simplify a lot of stuff it I do that I think

[eileenmcnaughton]

@lcdservices I think this is the correct fix - ie. rip out all the hacks & instead define the metadata correctly in the first place. It's now working for me.

Note that it now exports 'phone type id 'and 'phone type' ditto for Im Provider. This is consistent with what happens with pseudoconstants off contribution search (and some other fields) and you'll see that both fields appear in search builder after this. It's kinda too much information but we already have so much too much I think it's OK.

I'm expecting a few test fails but I'll fix those up.

If we can resolve this & #12579 then the export code maintainability will be hugely improved & we can tackle the bugs without causing more chaos

Note that testing this might require cache clearing - I'm testing under Redis which was a bit tricky on that front

[lcdservices]

I'm still seeing the IDs instead of the provider labels when exporting using both primary fields and select fields.

[eileenmcnaughton]

Closing for now - will come back to this once related ones merged