Last Comment Bug 746066 - Contacts API: Add v1 and v2 fields
: Contacts API: Add v1 and v2 fields
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Device Interfaces (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla15
Assigned To: Gregor Wagner [:gwagner]
:
Mentors:
https://wiki.mozilla.org/WebAPI/Conta...
Depends on:
Blocks: b2g-contact
  Show dependency treegraph
 
Reported: 2012-04-16 23:16 PDT by Gregor Wagner [:gwagner]
Modified: 2012-06-29 01:30 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
interface (6.42 KB, patch)
2012-04-19 00:00 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
implementation draft (27.02 KB, patch)
2012-04-19 02:53 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
interface (6.52 KB, patch)
2012-04-24 16:48 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
Interface (6.10 KB, patch)
2012-04-26 11:04 PDT, Gregor Wagner [:gwagner]
jonas: review-
Details | Diff | Review
Implementation (22.50 KB, patch)
2012-04-26 18:12 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
interface (6.06 KB, patch)
2012-05-02 08:56 PDT, Gregor Wagner [:gwagner]
jonas: review+
Details | Diff | Review
Interface (5.97 KB, patch)
2012-05-02 09:55 PDT, Gregor Wagner [:gwagner]
jonas: review+
Details | Diff | Review
Implementation (21.50 KB, patch)
2012-05-02 12:01 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
Implementation (27.39 KB, patch)
2012-05-02 17:49 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
Implementation (28.96 KB, patch)
2012-05-03 11:01 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
Implementation (30.07 KB, patch)
2012-05-08 13:23 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review
Implementation (32.81 KB, patch)
2012-05-10 13:59 PDT, Gregor Wagner [:gwagner]
fabrice: review+
Details | Diff | Review
AllInOne (25.89 KB, patch)
2012-05-10 14:52 PDT, Gregor Wagner [:gwagner]
no flags Details | Diff | Review

Description Gregor Wagner [:gwagner] 2012-04-16 23:16:38 PDT
We want to add following fields to the contacts API as proposed in the webapi thread: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/HGNpjyakc78

I collected the following fields that we want to add:
* custom field for phone, IM, email, address..
self defined and not an enumeration like work=1, home=2....
* work titles: string[]
* custom dates: dates[]
* ring tones: string[]
* favorite: boolean
* pictures

There is already a separate bug filed for the pictures that depends on the mediaStorage API.
Comment 1 Tantek Çelik 2012-04-17 11:44:57 PDT
(In reply to Gregor Wagner [:gwagner] from comment #0)
> * custom field for phone, IM, email, address..
> self defined and not an enumeration like work=1, home=2....

We've got this under consideration in the spec for tel and address, could you provide some background / existing examples for IM, email, and expand the "..." to a specific list?

> * work titles: string[]

Ok, I'll add "job-title" accordingly - already noted as under consideration in the page.

> * custom dates: dates[]

Examples?

> * ring tones: string[]

Also under consideration.

> * favorite: boolean

I'm going to reject this one and say instead, use a category of "favorite" on the contact. Pretty sure that's how existing UIs store this information.

> * pictures

What is needed here more than the existing "photo" field?

For a lot of these, it would help a lot if the requester could attach:
a) screenshot of the UI of one or more existing mobile address book apps with a contact using the feature 
b) .vcf export(s) of said contact for each platform tested (to see if they're even trying to interop at all, or if we should bother)
Comment 2 Gregor Wagner [:gwagner] 2012-04-17 18:00:27 PDT
(In reply to Tantek Çelik from comment #1)
> (In reply to Gregor Wagner [:gwagner] from comment #0)
> > * custom field for phone, IM, email, address..
> > self defined and not an enumeration like work=1, home=2....
> 
> We've got this under consideration in the spec for tel and address, could
> you provide some background / existing examples for IM, email, and expand
> the "..." to a specific list?
> 

It makes sense to me fore tel and address. rnewman asked for more fields. Maybe he can give concrete use-cases.

> 
> > * custom dates: dates[]
> 
> Examples?

This was also added by rnewman. It's up to him to 
convince us :)

> 
> > * favorite: boolean
> 
> I'm going to reject this one and say instead, use a category of "favorite"
> on the contact. Pretty sure that's how existing UIs store this information.
>

Sounds good to me.
 
> > * pictures
> 
> What is needed here more than the existing "photo" field?

Our UI guys requested to store blobs in the photo field in the DB.
Comment 3 Richard Newman [:rnewman] 2012-04-17 18:46:26 PDT
(In reply to Gregor Wagner [:gwagner] from comment #2)

> It makes sense to me fore tel and address. rnewman asked for more fields.
> Maybe he can give concrete use-cases.

Email… I think I average three email addresses each for my closer work and personal contacts, with a peak being perhaps nine. Having no categorization, or fixed categories (work, home, mobile? fax?!), is of little use in managing these. It's slightly less painful than for phone numbers, but I still use them all.

Similarly for IM handles (which one do I use for sending ops pages? which is his main one? which is his old account, which I don't want to message but I do want to use for integration with my IM application's log manager?).

It's even more important if you want to grow the concept of "IM" -- "twitter", "facebook", "Mozilla IRC".

I'd argue that *any* field in your address book -- URL, phone, email, date, human relationship, IM address, physical address -- should be able to be annotated with a user-specified string.


> This was also added by rnewman. It's up to him to 
> convince us :)

Child's birthday. Anniversary. First met. Divorced.

I have all of those in my address book and more.

People keep personal dates in address books.
Comment 4 Richard Newman [:rnewman] 2012-04-17 18:49:01 PDT
(In reply to Gregor Wagner [:gwagner] from comment #0)
> We want to add following fields to the contacts API as proposed in the
> webapi thread:

I would also like to suggest human relationships. This is necessary for Mac address book parity, and besides, it's really useful.

Husband, father, brother, ex-wife, daughter, manager, PhD supervisor: these are all in my address book, and I've used them all... particularly when filling out Christmas cards! "What's his wife's name again?".
Comment 5 Richard Newman [:rnewman] 2012-04-17 18:55:28 PDT
And if I were to give two non-personal justifications:

I spent a few years working at a company that supplied voice dialing services for major carriers. The largest address books hit the 5,000-contact limit. Lots of sales guys and small businesses, for example, rely on their address books to store *everything*. If you can't annotate and store everything -- "mobile email", "assistant", "first sales meeting", "finance approver" -- then you're not meeting those needs.

(That also implies that you need to be able to manage a few thousand contacts efficiently, and support all kinds of grouping and search constructs.)

The second justification: the more you have control over the labels on your data, the more human it feels. A user will have a closer bond with their data, their phone, and their applications if it can speak to them with labels that are meaningful, and capture the events and relationships that the phone enables.
Comment 6 Mike Conley (:mconley) - (needinfo me!) 2012-04-18 08:20:33 PDT
Hey, TB address book hacker here - thought I'd pipe up.

(In reply to Richard Newman [:rnewman] from comment #5)
> And if I were to give two non-personal justifications:
> 
> I spent a few years working at a company that supplied voice dialing
> services for major carriers. The largest address books hit the 5,000-contact
> limit. Lots of sales guys and small businesses, for example, rely on their
> address books to store *everything*. If you can't annotate and store
> everything -- "mobile email", "assistant", "first sales meeting", "finance
> approver" -- then you're not meeting those needs.

Having worked on Thunderbird's address book, and solicited information from our users on what it lacks, I can definitely corroborate the above.  The ability to customise field labels is something that TB lacks, and is definitely something that our users want.

> (That also implies that you need to be able to manage a few thousand
> contacts efficiently, and support all kinds of grouping and search
> constructs.)

With respect to grouping, I believe tagging should take care of most use cases.

> The second justification: the more you have control over the labels on your
> data, the more human it feels. A user will have a closer bond with their
> data, their phone, and their applications if it can speak to them with
> labels that are meaningful, and capture the events and relationships that
> the phone enables.

I agree with this as well. A set of contacts is precious because they represent what I know about other people in a way that I understand and value.
Comment 7 Mike Conley (:mconley) - (needinfo me!) 2012-04-18 08:27:40 PDT
Gregor:

Another thing to ponder - the Contacts API seems to stick pretty close to vCard, but one thing I'm not seeing is support for vCard extensions.

http://en.wikipedia.org/wiki/Vcard#vCard_extensions has a pretty decent list.

I'm just curious - were we planning on adding support for fields of this type somewhere down the line?

-Mike
Comment 8 Mike Conley (:mconley) - (needinfo me!) 2012-04-18 08:29:49 PDT
wrt that link I posted - I imagine most of those extensions are obsolete, but fields like X-MOZILLA-HTML and X-MOZILLA-PROPERTY are still useful to Thunderbird.

No pressure - just curious.
Comment 9 Gregor Wagner [:gwagner] 2012-04-18 23:09:35 PDT
My primary goal with this bug is to add features that are already in the B2G design and fulfill the requirements for the B2G milestone 3: https://wiki.mozilla.org/Gaia/Contacts

I am also ok to include some "easy to add" features but this won't be the bug where we solve every possible use-case. We are very limited in time here.

For changes outside of the B2G design I agree with Tantek where he wants to see some UI design that actually uses the feature.
Comment 10 Gregor Wagner [:gwagner] 2012-04-19 00:00:36 PDT
Created attachment 616481 [details] [diff] [review]
interface

interface draft
Comment 11 Gregor Wagner [:gwagner] 2012-04-19 02:53:34 PDT
Created attachment 616507 [details] [diff] [review]
implementation draft
Comment 12 Mike Conley (:mconley) - (needinfo me!) 2012-04-19 06:30:45 PDT
(In reply to Gregor Wagner [:gwagner] from comment #9)
> My primary goal with this bug is to add features that are already in the B2G
> design and fulfill the requirements for the B2G milestone 3:
> https://wiki.mozilla.org/Gaia/Contacts
> 
> I am also ok to include some "easy to add" features but this won't be the
> bug where we solve every possible use-case. We are very limited in time here.
> 
> For changes outside of the B2G design I agree with Tantek where he wants to
> see some UI design that actually uses the feature.

Yep, totally understandable.  No worries.
Comment 13 Gregor Wagner [:gwagner] 2012-04-24 16:48:24 PDT
Created attachment 618096 [details] [diff] [review]
interface
Comment 14 Gregor Wagner [:gwagner] 2012-04-26 11:04:45 PDT
Created attachment 618721 [details] [diff] [review]
Interface

For v1 I added:

new interface nsIDOMContactTelephone with type and number,
jobTitle
missing location fields from wiki API version
Comment 15 Gregor Wagner [:gwagner] 2012-04-26 18:12:24 PDT
Created attachment 618879 [details] [diff] [review]
Implementation

Implementation update
Comment 16 Mike Conley (:mconley) - (needinfo me!) 2012-04-27 08:29:42 PDT
Comment on attachment 618879 [details] [diff] [review]
Implementation

Review of attachment 618879 [details] [diff] [review]:
-----------------------------------------------------------------

Hey Gregor,

I hope you don't mind my drive-by review here.

-Mike

::: dom/contacts/ContactManager.js
@@ +4,5 @@
>  
>  "use strict"
>  
>  /* static functions */
> +let DEBUG = 1;

Should we really be enabling DEBUG by default here?

@@ +163,5 @@
>        this.adr = null;
>      }
>  
> +    if (aProp.date) {
> +      aProp.date = aProp.date.length == undefined ? [aProp.date] : aProp.date;

Am I correct in interpreting that you're using aProp.date.length == undefined to determine if aProp.date is an array?

If so, a more direct approach is to use Array.isArray(aProp.date).

@@ +172,5 @@
> +      this.date = null;
> +    }
> +
> +    if (aProp.tel) {
> +      aProp.tel = aProp.tel.length == undefined ? [aProp.tel] : aProp.tel;

Same as above, re: Array.isArray(aProp.tel).

::: dom/contacts/fallback/ContactDB.jsm
@@ +5,5 @@
>  "use strict";
>  
>  const EXPORTED_SYMBOLS = ['ContactDB'];
>  
> +let DEBUG = 1;

Like above, should this be enabled by default?

::: dom/contacts/fallback/ContactService.jsm
@@ +3,5 @@
>   * You can obtain one at http://mozilla.org/MPL/2.0/. */
>  
>  "use strict"
>  
> +let DEBUG = 1;

As above - should this be enabled by default?
Comment 17 Gregor Wagner [:gwagner] 2012-04-27 10:18:20 PDT
(In reply to Mike Conley (:mconley) from comment #16)
> Comment on attachment 618879 [details] [diff] [review]
> Implementation
> 
> Review of attachment 618879 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Hey Gregor,
> 
> I hope you don't mind my drive-by review here.
> 
> -Mike

Hi Mike! Feedback is always welcome :)
Thanks for looking over it!

> 
> ::: dom/contacts/ContactManager.js
> @@ +4,5 @@
> >  
> >  "use strict"
> >  
> >  /* static functions */
> > +let DEBUG = 1;
> 
> Should we really be enabling DEBUG by default here?
> 

This is not the final patch. That's more WiP because I am still waiting for Jonas to review the interface.

> @@ +163,5 @@
> >        this.adr = null;
> >      }
> >  
> > +    if (aProp.date) {
> > +      aProp.date = aProp.date.length == undefined ? [aProp.date] : aProp.date;
> 
> Am I correct in interpreting that you're using aProp.date.length ==
> undefined to determine if aProp.date is an array?
> 
> If so, a more direct approach is to use Array.isArray(aProp.date).

Yeah that would be great if it would work. But we have to deal with 2 global objects here and isArray just compares the array class pointer internally. They are different in this case. So isArray would always return false even if aProp.date is an array.
Took me a while to figure out what's going on here :)
Comment 18 Andrew Sutherland [:asuth] 2012-04-27 10:30:12 PDT
(In reply to Gregor Wagner [:gwagner] from comment #17)
> Yeah that would be great if it would work. But we have to deal with 2 global
> objects here and isArray just compares the array class pointer internally.
> They are different in this case. So isArray would always return false even
> if aProp.date is an array.
> Took me a while to figure out what's going on here :)

The code definitely checks if it is dealing with a proxy and then asks the proxy to do the class test:

http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp#3631
http://mxr.mozilla.org/mozilla-central/source/js/src/jsobjinlines.h#1658

If it still doesn't work for you with a current build, it seems like a JS engine bug that needs to be filed.
Comment 19 Gregor Wagner [:gwagner] 2012-04-30 11:11:59 PDT
(In reply to Andrew Sutherland (:asuth) from comment #18)
> (In reply to Gregor Wagner [:gwagner] from comment #17)
> > Yeah that would be great if it would work. But we have to deal with 2 global
> > objects here and isArray just compares the array class pointer internally.
> > They are different in this case. So isArray would always return false even
> > if aProp.date is an array.
> > Took me a while to figure out what's going on here :)
> 
> The code definitely checks if it is dealing with a proxy and then asks the
> proxy to do the class test:
> 
> http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp#3631
> http://mxr.mozilla.org/mozilla-central/source/js/src/jsobjinlines.h#1658
> 
> If it still doesn't work for you with a current build, it seems like a JS
> engine bug that needs to be filed.

That seems to work now. Thanks!
Comment 20 Jonas Sicking (:sicking) 2012-05-01 15:34:28 PDT
Comment on attachment 618721 [details] [diff] [review]
Interface

Review of attachment 618721 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/interfaces/contacts/nsIDOMContactProperties.idl
@@ +11,3 @@
>  interface nsIDOMContactAddress : nsISupports
>  {
> +  attribute jsval type;               // DOMString[]

Why is this an array? That's not the feedback we got from the UI team. They were planning on showing just a single type for a given address.

@@ +23,5 @@
> +
> +[scriptable, uuid(82601b20-89e8-11e1-b0c4-0800200c9a66)]
> +interface nsIDOMContactTelephone : nsISupports
> +{
> +  attribute jsval type;        // DOMString[]

Same here
Comment 21 Gregor Wagner [:gwagner] 2012-05-01 19:59:27 PDT
(In reply to Jonas Sicking (:sicking) from comment #20)
> Comment on attachment 618721 [details] [diff] [review]
> Interface
> 
> Review of attachment 618721 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/interfaces/contacts/nsIDOMContactProperties.idl
> @@ +11,3 @@
> >  interface nsIDOMContactAddress : nsISupports
> >  {
> > +  attribute jsval type;               // DOMString[]
> 
> Why is this an array? That's not the feedback we got from the UI team. They
> were planning on showing just a single type for a given address.
> 

We want to be able to store multiple values but the UI can do a workaround.
I don't have a strong opinion here. Tantek you also said you don't really care right?
So lets do a DOMString.
Comment 22 Jonas Sicking (:sicking) 2012-05-01 20:06:49 PDT
I don't understand why we would want to store multiple values? What is the use-case? I.e. what is the value of storing "home" and "fax" as separate string values compared to just storing "home fax"?

I can't imagine that anyone would want to build a UI where there are several textboxes for free-form text for a single phone number.

Sure, we can require apps to work around this quirk, but wouldn't it be better if they didn't have to?
Comment 23 Richard Newman [:rnewman] 2012-05-01 20:50:12 PDT
(In reply to Jonas Sicking (:sicking) from comment #22)
> I don't understand why we would want to store multiple values?

The only reason I could see would be for impedance matching with other data sources; a single string is the way I'd design this from scratch.

Alas, we don't always get to design from scratch: we have a second set of requirements above and beyond whatever UI Mozilla intends to layer on top of this.

The sources with which I'm familiar (Mac Address Book, Android) don't allow multiple values per se, but Android does allow storing something like

  DATA1 (NUMBER)      DATA2 (TYPE)         DATA3 (LABEL)
  "+1 800 555 8355"   Phone.TYPE_FAX_WORK  "Assistant"

because it has a rich array of types (including TYPE_CUSTOM, which means "use the label field") and a label field for arbitrary text.

  http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.Phone.html

The same applies to structured postal addresses, so it's relevant to this case:

  http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.StructuredPostal.html

If we don't plan to support distinct "type" and "label" fields (and I argue that we shouldn't, because that's janky), then we might need to map these to a type array, so that an Android address which is marked as "old, parent's cabin" and TYPE_HOME can be round-tripped correctly.

(I'm not sure that encoding that as "old\, parent's cabin, Home" and showing the escaping in a UI is a good solution, but I'm open to alternatives.)


> I.e. what is the value of storing "home" and "fax" as separate
> string values compared to just storing "home fax"?

Supporting data sources that store those two separately.

People get really annoyed when a sync solution crushes their data into a lowest common denominator.

We already have plans to support syncing of contact data, so it would behoove us to ensure that our data format can support the data we'll be feeding into it. We don't have to make identical representation decisions, but we should ensure that we can round-trip a user's Google contacts from their Android device through the webapi contacts representation, including intermediate editing.
Comment 24 Gregor Wagner [:gwagner] 2012-05-02 08:56:48 PDT
Created attachment 620340 [details] [diff] [review]
interface
Comment 25 Gregor Wagner [:gwagner] 2012-05-02 09:55:21 PDT
Created attachment 620356 [details] [diff] [review]
Interface

Removed the location fields from contact address. that needs more research and will be added in another bug.
Comment 26 Gregor Wagner [:gwagner] 2012-05-02 12:01:26 PDT
Created attachment 620412 [details] [diff] [review]
Implementation
Comment 27 Jonas Sicking (:sicking) 2012-05-02 15:22:24 PDT
Comment on attachment 620356 [details] [diff] [review]
Interface

Oh, also remember to bump the version on the IndexedDB database when checking this stuff in.
Comment 28 Jonas Sicking (:sicking) 2012-05-02 15:22:39 PDT
...and upgrade existing data of course.
Comment 29 Gregor Wagner [:gwagner] 2012-05-02 15:31:14 PDT
(In reply to Jonas Sicking (:sicking) from comment #28)
> ...and upgrade existing data of course.

I increased the DB version number and bent looked over the upgradeSchema function.
Comment 30 Jonas Sicking (:sicking) 2012-05-02 15:59:21 PDT
The upgrade code doesn't look correct. First of all I don't see anyone actually calling the upgradeSchema function. Second, why are you removing the "telLowerCase" index in the upgrade code, when it looks like the index is created if the database is created from scratch.

Also, don't you need to update any existing data to follow the new schema, at least for phone numbers?
Comment 31 Jonas Sicking (:sicking) 2012-05-02 16:01:43 PDT
By the way, on the iphone favorites is per-telephone number, not per-contact. That way the user can add someone's cellphone number to the favorites list, but not add their home phone and office number as well.
Comment 32 Gregor Wagner [:gwagner] 2012-05-02 16:48:31 PDT
(In reply to Jonas Sicking (:sicking) from comment #30)
> The upgrade code doesn't look correct. First of all I don't see anyone
> actually calling the upgradeSchema function. Second, why are you removing
> the "telLowerCase" index in the upgrade code, when it looks like the index
> is created if the database is created from scratch.
> 
> Also, don't you need to update any existing data to follow the new schema,
> at least for phone numbers?

Hm the upgradeNeeded works different than I expected. upgradeSchema gets called from the IndexedDBHelper.js but currently not in the right way. I will change that.
Comment 33 Gregor Wagner [:gwagner] 2012-05-02 17:49:17 PDT
Created attachment 620541 [details] [diff] [review]
Implementation

I had to change how the IndexedDBHelper handles onupgradeneeded.
It's kind of annoying that I have add the transaction as an function argument but I guess I need it to get an existing objectstore.
Comment 34 Gregor Wagner [:gwagner] 2012-05-03 11:01:38 PDT
Created attachment 620780 [details] [diff] [review]
Implementation

Jonas: would be good if you could also take a look at the upgradeNeeded functionality again.
Comment 35 Gregor Wagner [:gwagner] 2012-05-04 17:46:59 PDT
Comment on attachment 620780 [details] [diff] [review]
Implementation

There is more stuff to fix...
Comment 36 Gregor Wagner [:gwagner] 2012-05-08 13:23:06 PDT
Created attachment 622113 [details] [diff] [review]
Implementation

hopefully with the proper DB  upgrade now.
Comment 37 Gregor Wagner [:gwagner] 2012-05-10 13:59:16 PDT
Created attachment 622901 [details] [diff] [review]
Implementation

I also added category as searchable field. We need this for favorites.
Comment 38 Gregor Wagner [:gwagner] 2012-05-10 14:52:10 PDT
Created attachment 622931 [details] [diff] [review]
AllInOne
Comment 40 Ben Bucksch (:BenB) 2012-05-11 10:56:05 PDT
(In reply to Richard Newman [:rnewman] from comment #23)
> (In reply to Jonas Sicking (:sicking) from comment #22)
>   DATA1 (NUMBER)      DATA2 (TYPE)         DATA3 (LABEL)
>   "+1 800 555 8355"   Phone.TYPE_FAX_WORK  "Assistant"
> 
> because it has a rich array of types (including TYPE_CUSTOM, which means
> "use the label field") and a label field for arbitrary text.

This is the right way to do it.

In the patch, I only see a "type", which seems to be an arbitrary label. That is not sufficient. We need:
number - string, only characters 0-9, +, -, /, up to 20 chars - what would be dialed towards the phone network
extension - string, optional - what the user has to key in via DTMF, or select in a speech menu
label - user-visible, random string, optional - a description, e.g. "second mobile"
type - computer-readable flags, e.g. (fixed or mobile or fax), and (home or office), e.g. "office mobile"

It's really important to have this type distinctive from label. 

Label: I need the label when I have many, sometimes rather odd phone numbers for a person and want to keep them apart, e.g. "phone at his mother's place". I currently have no way to put this kind of information in the Thunderbird AB.

Type: However, we also need the computer to read some of this information. For example, this is needed for sync, as VCF only gives fields like HOME_CELL, no label. What's more, if I sync my Thunderbird AB with my Android, and from there with the speech-controlled phone system in my car (as using the phone while driving is forbidden by law), I can tell my phone system "mom cell", and it will pick the right number. The "cell" is not a label, but a type.

As for UI, we could have a textfield with a dropdown with number of default labels, localized, e.g. "Private mobile", "Office fixed" etc.. If selected, they would set only the type, *not* the label in the DB. If the user then switches locale, the label is still localized. More importantly, the computer can differentiate the standard labels from special user-entered label values, and honor the latter with more importance. When syncing, "private fixed" would be converted properly and unambiguously. Thus, we don't have to bother the user with a type in the UI, but we have the data.

Extension: Things like phone extensions (CTI Computer-Telephony-Integration, SIP, Skype) which can dial from the computer. They will need the number, and adding an extension might confuse it. "strip everything after 'x'" would be a hack, but I guess possible.

Please add at least the separation between type and label, because a lot of things will break or be very hard to do cleanly without this.

Ben
Comment 41 Ben Bucksch (:BenB) 2012-05-11 10:58:33 PDT
So, in essence, Android has it exactly right, and it's really needed. Please add it. Thanks!
Comment 42 Ben Bucksch (:BenB) 2012-05-11 11:03:52 PDT
As for address, we need both street and an extra description field, e.g. "right alley, in the back" or "door code 8899". For many addresses, post will not arrive without such extra info, but it doesn't belong in the street field.
Comment 43 Matt Brubeck (:mbrubeck) 2012-05-11 11:42:43 PDT
https://hg.mozilla.org/mozilla-central/rev/3cbe5afeb563

Note You need to log in before you can comment on or make changes to this bug.