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
* 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 :
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
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:
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
4.) we want to be 100% compatible with Apple clients, and Apple uses only the N
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
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).
On 23 Mar 2016, at 19:42, Jean-Philippe Garcia
Ballester <jean-philippe(a)demo-tic.org> wrote:
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.