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.
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)
* if I want only N, FN will be set following globalContactStoreFN option.
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.
I would very much like to see the best of both worlds.
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,
> >
>
>
