Hi Jean-Philippe,

On 24 Mar 2016, at 01:23, Jean-Philippe Garcia Ballester jean-philippe@demo-tic.org wrote:

Hello Ján,

I understand your point, but I think there are some useful usecases where FN is different than N. There is indeed no guarantee of "referential integrity" as you say, and that is exactly the point of FN. I want to store that my contact name is John Doe, but I do want it to display as “My very best friend” in my contact list.

I understand that you use vCard in "your way", but FN is definitely not a "your description of a person". FN is supposed to be a formatted name from the N attribute (formatted N = FN). E.g.:

in Hungary the standard name formatting is: Last Middle First N:Last;First;Middle;; FN:Last Middle First but in Slovakia the standard name formatting is: First Last N:Last;First;;; FN:First Last

If you want to use something like “My very best friend”, you should write it into the NICKNAME attribute (most of software will display the nickname instead of the full name if it is present). But the really correct place for that kind of description is the NOTE field (because your string is not a NICKNAME).

If you take a close look at the patch, you will see that it does not remove the globalContactStoreFN option. So :

• if I want FN different from N, I set both,
• if I want only FN, N will be empty (and thus it will not work on Apple clients as you say)

and that's exactly what we don't want to have (software not compatible with Apple)

• if I want only N, FN will be set following globalContactStoreFN option.

95% of users will not understand your 3 points above. They will ask: - When I need to fill FN? - Why FN is here if I don't need to fill it? - If someone will fill only the FN how I will know which name is the First, Last, Middle if the name format is different in each country? - If FN is added automatically from the N what will happen if I later edit the N attribute in the contact? ... do I need to edit the FN too?

I believe it's the way a lot of software work, and I may be wrong, but I can't see how it breaks the way it works now: just don't set DisplayName in the interface and the behavior doesn't change.

See the questions above ... it will confuse most of our users without any real benefit.

I would very much like to see the best of both worlds.

If somebody wants to have FN he/she can use your patch, but we really don't want to add it into the official release.

Cheers,

JM

Cheers, and many thanks for your very detailed answer.

-- Jean-Philippe Garcia Ballester

Le Wednesday, March 23, 2016 10:29:44 PM CET Ján Máté a écrit :

...

Hi Jean-Philippe,

thanks for your patch, but unfortunately I cannot add it to the official release :-/

This feature was discussed multiple times, and there are reasons why we don't want it:

1.) FN only duplicates the data in N (which is required attribute and contains the structured representation of data) 2.) there is no guarantee of "referential integrity" between N and FN; e.g. you can create something like: N:Doe;John;;Dr.; FN:Mr. Peter Parker 3.) most of users don't want to write the name multiple times (into the N and then into the FN attribute), and will be confused why there are 2 fields for the same information 4.) we want to be 100% compatible with Apple clients, and Apple uses only the N attribute

For backward compatibility we added support for the globalContactStoreFN option, where you can "format" the content of the FN attribute (this attribute is write-only for "older" clients which use the FN instead of N).

I fully understand your situation and maybe there will be more users who find your patch useful, but the real and good solution is to update all your contacts with fixed N attribute.

If you use DAViCal, it requires only a simple PLPGSQL script which extracts the FN attribute, then format it (e.g. using a simple capturing regex match), remove the current N attribute, then add it back e.g. before the "END:VCARD" line and call the write_sync_change function (with correct parameters). It is much better approach than using unstructured data; personally I used it multiple times to fix common errors in our database (which currently contains 18807 contacts).

Cheers,

JM

...

On 23 Mar 2016, at 19:42, Jean-Philippe Garcia Ballester jean-philippe@demo-tic.org wrote:

Hello all,

The “Formatted Name” field of contacts is not used. Our problem is that we have a very big addressbook, and all contacts only have Formatted Name (no Last Name nor First Name).

Attached is a patch that adds a field named “Display Name”, as most carddav clients call it, that is displayed in the contact window and editable. It is also used by default in the contact list.

Warning: it has not been extensively tested (and only with Davical as a server), but it seems to work well.

It would be very interesting for us if it could be tested by more people and eventually included in an official release.

Best regards,