Do not auto generate Display Name (FN) field and allow editing/external updates

Checklist

I made sure that there are no existing issues - open or closed - to which I could contribute my information.
I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
This issue contains only one feature request.
I have read and understood the contribution guidelines.
I optionally donated to support the Fossify mission.

Feature description

Make "Display Name" (FN) field editable and do not auto update from other fields.

Why do you want this feature?

As far as I can understand contacts app auto generates Display Name (FN) field from First Name/Middle Name/Last Name... sections. But I believe generating only once if contact are creating from this app is enough. Users should be able to directly change this field.

This supports users to easily organize their contacts I guess.

Additional information

Note: This is also required for Full Nextcloud/Vcard v4 Integration. See #85
Note2: Otherwise updating Display Name field from any DAV server (for example Nextcloud + Davx5) are not going to work because app still updates it from other fields.

Add a 👍 reaction to issues you find important.

@asandikci

#129 (comment)

@asandikci, if this is implemented, I would like to be able to choose to retain the current behaviour. Were it not doing this, I would have filed an FR to have the FN automatically update from the N field. However, should nextcloud/contacts#3983 (comment) be implemented, it would be reasonable to expect that this conversation would become necessary.

I'm copying from my issue here regarding some incompatibility with names and sorting in Google Contacts, Stock Android, Apple, and Nextcloud. Basically, the de-facto standard right now is that sorting is done on FN: (first name) unless a switch is toggled to sort on N: (last name). FN: and N: are linked together, one generated from the other, and the form used for names has a number of fields, for which you can see both Google's and Nextcloud's, below. When neither FN: nor N: are present, it seems that ORG is used as the sorting key.

This generates some issues, since we may want to sort in some way other than First or Last name or Organization. Nextcloud's solution to this is to break the FN: / N: link, and allow FN: to be filled out independently. That becomes the sort key, and is no longer necessarily the first name. You can see Nextcloud's forms, below. Google has a different solution. They introduce an X-FILE-AS: ("File-As") field (see below). I've also included the most general Google and Nextcloud v-card that I can generate, below.

@RokeJulianLockhart wants to be able to keep the current behavior (FN: and N: linked). I believe that should be the case also, given it's the de-facto standard and that it's directly related to sorting on first name vs. surname.

The following is parenthetical, as I'm unable to see a way to keep compatibility with both formats. I don't necessarily suggest it, but for sorting, this might work:

If X-FILE-AS is present, assume that's the sort field.
Otherwise:
a. sort by FN: (first name - which is the default now where "Start Name by Surname" is off),
b. sort by N: (last name) if "Start Name with Surname" on.

And then, for creation and then exporting, the only way I could see would be to have an export-to-nextcould switch that would copy "File-As" into FN:

Google's Form:

BEGIN:VCARD
VERSION:3.0
FN:Prefix AAAAAFirst Middle BBBBBLast Suffix
N:BBBBBLast;AAAAAFirst;Middle;Prefix;Suffix
NICKNAME:Nick
X-PHONETIC-FIRST-NAME:PFirst
X-PHONETIC-MIDDLE-NAME:PMiddle
X-PHONETIC-LAST-NAME:PLast
X-FILE-AS:File-As
item1.EMAIL;TYPE=INTERNET:foo@bar.com
item1.X-ABLabel:eMail.Label
TEL;TYPE=HOME:555-1212
TEL;TYPE=HOME;TYPE=FAX:555-1212
item2.TEL:555-1212
item2.X-ABLabel:Phone-Label
ADR;TYPE=HOME:;Suite 666;555 Foo St.;777 City;CA;88888;US;555 Foo St.\nSuit
 e 666\, 777 City\, CA 88888\nUS
item3.ADR:;Suit 6666;5555 Foo St.;7777 City;CA;99999;US;5555 Foo St.\nSuit 
 6666\, 7777 City\, CA 99999\nUS
item3.X-ABLabel:Address-Label
ORG:Org;Dept
TITLE:Title
BDAY:19000101
URL;TYPE=WORK:http\://example.com
item4.URL:http\://example.com
item4.X-ABLabel:_$!<HomePage>!$_
item5.URL:http\://example.com
item5.X-ABLabel:Website-Label
item6.X-ABDATE:19200101
item6.X-ABLabel:_$!<Anniversary>!$_
item7.X-ABDATE:19800101
item7.X-ABLabel:Death-Date
item8.X-ABRELATEDNAMES:Related Person
item8.X-ABLabel:_$!<Spouse>!$_
item9.X-ABRELATEDNAMES:Related Person
item9.X-ABLabel:Related-Label
NOTE:These are notes.\nCustom-Field: foobarbaz
CATEGORIES:myContacts
END:VCARD

Nextcloud's Form:

BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 4.5.4//EN
UID:2f7079e3-c9e8-48ef-9452-fda56300677f
FN:First Middle Last
ADR;TYPE=HOME:;Suite 666;555 Foo St.;Bar City;Baz;77777;Bumble
EMAIL;TYPE=HOME:foo@bar.com
TEL;TYPE=HOME,VOICE:555-1212
CATEGORIES:Auto
TITLE:Title
ORG:Company
BDAY;VALUE=DATE:19000101
URL;VALUE=URI:http://example.com
X-SOCIALPROFILE;TYPE=TWITTER:twitterexample
X-MANAGERSNAME:
ITEM1.X-ABDATE;VALUE=DATE-AND-OR-TIME:19200101
ITEM1.X-ABLABEL:_$!<Anniversary>!$_
NEXTCLOUD1.X-ABLABEL:FederatedCloud
X-ANNIVERSARY;VALUE=DATE:19200101
DEATHDATE;VALUE=DATE:19800101
N:Last;First;Additional;Prefix;Suffix
NEXTCLOUD1.CLOUD;TYPE=OTHER:foo@matsodon.social
GENDER:O
IMPP;TYPE=SIGNAL:foo32
GEO;VALUE=URI:geo:90.000\,0.000
NICKNAME:Nickname
X-PHONETIC-FIRST-NAME:PFirst
X-PHONETIC-LAST-NAME:PLast
RELATED;TYPE=RELATIVE:Cousin Last
RELATIONSHIP:FRIEND
LANG:ebu-ke
TZ:Africa/Bissau
REV;VALUE=DATE-AND-OR-TIME:20241129T153519Z
END:VCARD

I would like the option to turn on Nicknames. Commenting instead of creating a new issue, as I believe this is the same request.

@fohfuu

@fohfuu Nicknames are already in the app.

@Aga-C

@Aga-C The nickname field is in the app, you can add a nickname, but it doesn't change the way the contact is displayed.

e.g., if you add a contact Firstname Lastname with the nickname "Nick", then that contact displays as Firstname Lastname (or Lastname Firstname if you select the "start name with surname" option). The contacts list will show the contact as Firstname Lastname, the call log will show you called Firstname Lastname , and so on.

@Aga-C The nickname field is in the app, you can add a nickname, but it doesn't change the way the contact is displayed.

e.g., if you add a contact Firstname Lastname with the nickname "Nick", then that contact displays as Firstname Lastname (or Lastname Firstname if you select the "start name with surname" option). The contacts list will show the contact as Firstname Lastname, the call log will show you called Firstname Lastname , and so on.

This ^.

Nicknames are kinda useless right now. The whole point of giving a nickname is too see it when interacting with that contact instead of the FIRST NAME LAST NAME.

I'm in the same boat as those having no use for the Display Name (FN) property, which I need to be auto-generated.

To resolve this, given that each person has its own preferences, the following options should be added in the Contact App preferences :

Display name : filled when empty from the following properties :
list of [ last name, middle name, surname, prefix, suffix, nickname, ... ]
with the possibility to add or remove them at will, and changing the order (applied only for new contacts)
(basically this means a subpanel with a selector and manual reordering,
and keeping a hidden flag only for a new contact on the edition page, with the Display Name content updated automatically until the user change it manually, or the contact is saved)
Display name : always updated each time a change occurs in the selected properties : on/off
(requiring an event on text change to all the supported properties when active, to update the Display Name)

Bonus : the subpanel would be usable also for the contact list sorting option.

1 will give the desired behavior to everybody, and 2 will cover both those who make use of the Display Name, and those who think this property shouldn't exist.
Btw, please note that when you are syncing the contacts with different systems, some of them (iOS for example) don't even allow the access to Display Name or some other properties and always generate their content automatically.

I'd like to reinforce this request from a real-world corporate CardDAV environment.
Environment: Volla OS 15 (ships with a Fossify Contacts fork as default) + DAVx⁵ syncing from IceWarp groupware via CardDAV.
Problem: Fossify auto-generates DISPLAY_NAME from structured first/last name fields and ignores the FN value synced from the CardDAV server. This is the exact same class of bug I reported for Thunderbird (Bug #2008735) — the lastnamefirst preference was ignored for CardDAV address books, and the server-authoritative FN was overwritten.
In a corporate CardDAV environment, the server-side FN is the canonical display name. Many contacts don't follow simple first/last structure — they include organization, title, nickname, or are company-only entries. When the app overwrites the synced FN, contacts become unrecognizable.
Requested behavior:

Respect and display the FN / DISPLAY_NAME from Android's ContactsContract as-is when synced from an external source (DAVx⁵, CardDAV)
Do not auto-overwrite it from structured name components
Allow manual editing of the display name field in the contact editor
Ideally, support a configurable display name format template (e.g., LastName, FirstName (Organization) - NickName) for locally created contacts
Fall back to auto-generation only when FN is empty and the contact is created locally

Impact: Volla OS ships a Fossify fork as its default contacts app, so this directly affects the entire Volla Phone user base in corporate/CardDAV environments. Currently, Fossify is unusable as a primary contacts app in this scenario.

I wwould have seen the possibility to edit FN field and an preference option "Display FN if there's no first name/last name"

Navigation Menu

Repository navigation

Do not auto generate Display Name (FN) field and allow editing/external updates #129

Checklist

Feature description

Why do you want this feature?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Do not auto generate Display Name (FN) field and allow editing/external updates #129

Description

Checklist

Feature description

Why do you want this feature?

Additional information

Activity

beedell-roke commented on Jun 15, 2024

DiagonalArg commented on Nov 29, 2024

fohfuu commented on Jan 6, 2025

Aga-C commented on Jan 6, 2025

fohfuu commented on Jan 9, 2025

leg7 commented on Jun 2, 2025

beedell-roke commented on Jun 2, 2025

Daryes commented on Sep 5, 2025

braklo commented on Feb 24, 2026

Sigdroid commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions