Contact import improvements

[johndoh]

For #9419

Some of the mappings in the current code work (pass the tests) but the result is different to what you get if you create the same contact manually through the UI and then export it as a vCard, for example Roundcube uses phone:mobile not phone:cell and there is no email:pref field. I have changed the mapping so it matches the fields in the UI. I added some more aliases rcube_vcard to show existing vCards with mismatched fields nicely.

I have removed the subtype other from the IM field because that does not exist in rcube_vcard which means if when you hit save in the UI the value simply disappears, it’s not saved.

I have removed the variable rcube_csv2vcard::$label_map because it’s a duplicate of contents of /program/localization/en_US/csv2vcard.incand just a bit confusing currently /program/localization/en_US/csv2vcard.inc is not used by the code and this PR changes that.

I have another reason for wanting to use /program/localization/en_US/csv2vcard.inc over rcube_csv2vcard::$label_map and if this PR gets merged then I will propose 1 additional change which will remove the rcube_csv2vcard::$csv2vcard_map variable and simplify the mapping process by storing both the source and destination for the map in /program/localization/en_US/csv2vcard.inc and allowing multiple sources (including multiple languages) for the same destination. This is a slightly larger and may be more controversial change hence the separate PR.

[johndoh]

I moved the list_fields function back to rcmail_action_contacts_import because it relies on the contact list from its parent class rcmail_action_contacts. I think its the best place for it.

Also I completed the second part of my suggestion to remove the hard coded mapping information entirely and use 1 to define the source and destination.

[pabzm]

if this PR gets merged then I will propose 1 additional change which will remove the rcube_csv2vcard::$csv2vcard_map variable and simplify the mapping process by storing both the source and destination for the map in /program/localization/en_US/csv2vcard.inc

You're removing this variable in this PR already and to me it looks like information gets lost there, because there's no mapping e.g. of email_2_address to email:other anymore. Am I right?

[johndoh]

I should have updated my comment when I changed my approach. You are totally right that this PR now removes that variable. It happens in this commit.

to me it looks like information gets lost there, because there's no mapping e.g. of email_2_address to email:other anymore. Am I right?

The $map['email_2_address'] entry is replaced by $map['email:other'][] in the proposed approach. e.g.:

$map['email:other'][] = "E-mail Address";
$map['email:other'][] = "E-mail 2 Address";
$map['email:other'][] = "E-mail 3 Address";

[github-actions]

@pabzm, @alecpl
🛎️ This PR has had no activity in two weeks.

[johndoh]

@pabzm any chance this could be part of 1.7?

[pabzm]

From my point of view, yes. I don't really like the syntax in the csv2vcard.inc-files, but I'm happy about the cleanup and those files don't change often, so it's not a big problem and shouldn't block us, I think.

@alecpl What do you think about this?

[johndoh]

the format of csv2vcard.inc is now similar to labels.inc/messages.inc

[pabzm]

Much nicer, thank you! Can we make the format even more close by swapping keys and values in the inc-files, and run array_flip() on them after reading?

[johndoh]

I put them this way round because multiple CSV fields are mapped to the same vCard field so, I think, its either:

$map['email:other'][] = "E-mail Address";
$map['email:other'][] = "E-mail 2 Address";
$map['email:other'][] = "E-mail 3 Address";

or

$map['E-mail Address'] = 'email:other';
$map['E-mail 2 Address'] = 'email:other';
$map['E-mail 3 Address'] = 'email:other';

[pabzm]

Oh, alright! Then I prefer the second and current way.

Thank you again!