The old address book had Custom1 ... Custom4 fields, which have not been migrated to vCard and are no longer accessible. Users did have data in those fields.

If there is no standard vCard field for custom data, can we use X-Thunderbird-Custom?

I can offer to work on this.

I'd say the common vCard field for custom data is NOTE.
Although we are currently limiting one note it has a cardinality of "*" (many). This might be a solution for the Custom fields.

But it also depends on the use case of the Custom fields.

Of course the lost support for the old custom fields Custom1...Custom4 should be fixed with a very high priority.

However, I also want to point out the bigger picture wrt custom fields:

For my own add-on Mail Merge the custom fields were often used by the users to store informatation about the salutation or gender, because the old address book lacked support for a distinct gender field - and Bug 642782 never got implemented.

vCard4 supports a distinct "GENDER" field; on the other hand vCard3 has no such field. In the latter case, i.e. vCard3, it would be very handy to configure Thunderbird in a way to also modify an "X-GENDER" field.

The Fritz!Box routers - which are very popular in Germany - have the possibility to mark certain contacts as important. (Calls from important contacts can come through, while the phones stay silent for other non-important contacts.) They use another custom field, i.e. "X-FRITZOS-PRIORITY". Again it would be very handy to configure Thunderbird in a way to also modify this field, so the Fritz!Box can pick up the changes eventually.

The old custom fields Custom1...Custom4 are just another variant and could be supported via "X-CUSTOM1" to "X-CUSTOM4". The add-on CardBook by Philippe Vigneau actually does it already like this, when importing the standard address books into CardBook.

I am sure there are a lot of other use-cases for user-defined custom fields as well.

A very flexible implementation in Thunderbird could be straight forward with presenting a simple text field, when editing a contact, for a list of user-defined custom field names. Just like it is done for custom headers in the compose window via "mail.compose.other.header".

The user-defined custom field names could be a comma separated list via a new (hidden) preference - accessible in the "Config Editor". The new (hidden) preference could default to "X-CUSTOM1,X-CUSTOM2,X-CUSTOM3,X-CUSTOM4" wrt the old custom fields.

I strongly recommend to also take a look at the add-on CardBook, which has supported user-defined custom fields for years in the just described very flexible way.

Plan for 102

Add back those custom fields that had any data in it, as static and always present so users that had data can still see it and edit it.

After 102

Convert those custom fields to actual repeated custom fields and implement those properly based on the vcard spaces.

Regarding all other vCard4 fields we're currently missing, we will implement those after 102.
No need to over engineer or complicate things.
The work on the address book isn't complete and this is a weird transition period.

For info, here is my custom field use case.

I have been using the contents of the Custom1 field to enable me to select subsets of addresses using the address search text box.

As recommended somewhere years ago, I changed the mail.addr_book.quicksearchquery.format advanced preferences option to include the string (Custom1,c,@V) towards the end of the list of fields to be searched in an address book search.

With 102, I can still search the existing address book entries based on the orriginal contents of Custom1 but I am unable to display the field or make ammendments to it.

I hope someone is working on this issue I had a lot of additional info in my address book that no longer shows

(In reply to Alessandro Castellani [:aleca] from Bug 1776129 comment #3)

Plan for 102

Add back those custom fields that had any data in it, as static and always present so users that had data can still see it and edit it.

That still sounds like a good plan, which imo should be pursued with some urgency.
We must accept that even if we're still holding the user's original data of custom1-4 fields from TB 91 somewhere, as long as users cannot see it nor edit it, it's de facto dataloss, and we'll get blamed for that, potentially much-blamed in public.

Seems indeed they should be X-CUSTOM1 and so on. It would be nice to be able to add more custom labels as well, as comment 2 describes. Supporting use cases like that it something user's will like Thunderbird for. I'm not sure it's not about equally much work to implement it like this from the start (with no specific 102 work).

This converts nsIAbCard style Custom[1-4] properties to X-Custom[1-4] vCard properties when a card is edited. Since the properties could exist in either form a number of hacks have been deployed.

Awesome, thank you for taking this, Geoff!

(In reply to Magnus Melin [:mkmelin] from comment #7)

Seems indeed they should be X-CUSTOM1 and so on.

+1, thanks, Magnus!

It would be nice to be able to add more custom labels as well, as comment 2 describes. Supporting use cases like that it something user's will like Thunderbird for.

Indeed! If it's not happening here and now, let's make sure we have this on record.

I'm not sure it's not about equally much work to implement it like this from the start (with no specific 102 work).

Maybe you can discuss this with Geoff?

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/a43d373c7152
Add Custom1-4 fields to Address Book UI. r=aleca

Awesome - you guys rock! Geoff, Magnus, Alex

Comment on attachment 9288221 [details]
Bug 1776129 - Add Custom1-4 fields to Address Book UI. r=aleca

[Approval Request Comment]
Regression caused by (bug #): New address book
User impact if declined: Can't see some data in address book
Testing completed (on c-c, etc.): Landed last week
Risk to taking this patch (and alternatives if risky): Low

Comment on attachment 9288221 [details]
Bug 1776129 - Add Custom1-4 fields to Address Book UI. r=aleca

[Triage Comment]
Approved for beta

Thunderbird 104.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/7f1844c2e512

Is this good for uplift to esr? No strings issue?

Have we had any testing of this patch on beta? I think we really should.

There's some new strings but frankly I don't care. Searchfox says they've been translated in 25 locales already and in most of the others they won't be the only untranslated strings.

On beta almost two weeks. But I don't know that anyone has tested it explicitly.

Until now. On windows with Thunderbird 91 I just added four custom entries to an existing contact. Updated that to version 102. And installed 104.0b4 on top of that. All four fields are correct with the custom data.

So now it is tested :)

Comment on attachment 9288221 [details]
Bug 1776129 - Add Custom1-4 fields to Address Book UI. r=aleca

[Approval Request Comment]
Go on then.

Comment on attachment 9288221 [details]
Bug 1776129 - Add Custom1-4 fields to Address Book UI. r=aleca

[Triage Comment]
Approved for esr102

Thunderbird 102.2.0:
https://hg.mozilla.org/releases/comm-esr102/rev/5f0950dfa685

Thunderbird 102.2.0:
https://hg.mozilla.org/releases/comm-esr102/rev/89ba701459be