On 24 Mar 2016, at 01:23, Jean-Philippe Garcia
Ballester <jean-philippe(a)demo-tic.org> wrote:
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
FN:Last Middle First
but in Slovakia the standard name formatting is: 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
and that's exactly what we don't want to have (software not compatible with
* if I want only N, FN will be set following
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
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, 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
> 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
>> 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
>> 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,