Address Book columns incorrect (phone numbers)

[manawiz]

I've seen this issue raised a column times in other forum posts, but never with a resolution.

With Thunderbird 2.0.0.22 and gcontactsync 0.25 or 0.27, the phone number fields in Thunderbird are changed from Work, Home, Mobile, ..., to First, Second, Third, ...  Associated with each ordinal field is the actual type of phone number in a drop-down.  gcontactsync always puts the first non-empty phone number into First, e.g. if a there is no Work number then the Home number goes into First, the Mobile into second, etc.

The problem is that the Thunderbird Address Book window columns don't know about the new drop-down phone number types.  Whatever gcontactsync puts into the First field always shows as the Work number in the columns even if it is really the Home number, the Second phone number always shows as the Home number even if it is really the Mobile number, etc.

This makes Address Book window *unusable*.  I typically only use Address Book window as there is rarely a need to consult the cards themselves.

I've tried both enabling and disabling the Interface preference, "Rename the phone column labels" but can notice no change of behavior at all with either setting.  With either setting, the columns are still called Work, Home, ..., and Work always comes from First, ...

This behavior causes the extension to lose all information about a phone number's type and thus renders it unusable.

Isn't there some way to resolve this?

EDIT: 1/29/10 added (phone numbers) to the title - Josh

[manawiz]

Managed to work around the problem, but it was tedious.

The issue appears to be a bug in gcontactsync when it first converts thunderbird address records in standard format (like you see in New Card even after gcontactsync loaded) into its enhanced gmail-like format with type-selectable First, Second, Third, ...  The bug is that gcontactsync moves the phone numbers of the original record to the top, i.e. first non-empty number to First no matter what type it was, second non-empty number to Second no matter what type it was, etc.  This is a bug because neither Thunderbird Address Book window columns not Thunderbird export can interpret the generated format.  Both of these Thunderbird features always map the fields like this:

First <-> Work
Second <-> Home
Third <-> Work Fax
Fourth <-> Mobile
Fifth <-> Pager

None of the types are incorrect in the card view, so the fix is to edit each card and put the numbers into the right sequence as above.  I could find no way to do this automatically since both csv and ldiff export follow the ordering above and thus screw up the types until the ordering is fixed.  Fortunately, cards created later, after the initial gsynccontact conversion, can have blank numbers and not have them compressed.

There is are additional bugs in all contact imports from gmail.  My initial import created duplicate records for almost all my contacts (surprisingly there were a few exceptions with no distinguishing characteristics I could notice); there were synced before loading gcontactsync a doubled in both thunderbird and gmail after first sync.  The versions imported to thunderbird from gmail also has field compression, but worse the fields were not in the order above.  As they were out of order they were easy to identify; I simply deleted them, which did sync properly back to gmail.

The bigger problem is that whenever any new contact is created in gmail the same bug happens.  E.g., if you create a contact with just a mobile phone it will be imported in to Thunderbird with mobile number in First, which causes that number to appear as Work in both Address Window columns and in export.  As this bug affects ongoing operation and not just initial conversion it is more serious.

Yet another bug is that even with "Only syncrhonize 'My Contacts' group" preference *un*-checked gcontactsync will only import contacts created in gmail into thunderbird if they were created in My Contacts group.

This core function of this extension is useful, but there are serious bugs. I see discussion of new versions and would like to suggest that making the current functionality solid is the highest priority, before new functionality is added.

[Josh Geenen]

The bug is that gcontactsync moves the phone numbers of the original record to the top, i.e. first non-empty number to First no matter what type it was, second non-empty number to Second no matter what type it was, etc.  This is a bug because neither Thunderbird Address Book window columns not Thunderbird export can interpret the generated format.  Both of these Thunderbird features always map the fields like this:...

Phone number types were added a while back after several people suggested and requested that feature.  Google Contacts now allows far more phone numbers and phone number types than Thunderbird (version 0.3 adds the new types).  Most people, however, only have a few phone numbers per contact.  If I remove the phone number types Thunderbird would need about 20 total phone number fields.

Others have requested using the existing fields, so I filed Bug 20962, but my time is fairly limited between 18 credits at school and my job so I don't know when or if that will get done.  It cannot go into 0.2.x because it would change too many strings so all the translations would be broken.

Bug 21186 is for trying to import and export new fields.  In Thunderbird 2 this would have been very difficult but I will try to look into this for Thunderbird 3.  If native support for field types makes it into Thunderbird in the future this should become much easier.

There is are additional bugs in all contact imports from gmail.  My initial import created duplicate records for almost all my contacts (surprisingly there were a few exceptions with no distinguishing characteristics I could notice); there were synced before loading gcontactsync a doubled in both thunderbird and gmail after first sync.  The versions imported to thunderbird from gmail also has field compression, but worse the fields were not in the order above.  As they were out of order they were easy to identify; I simply deleted them, which did sync properly back to gmail.

Did you previously synchronize the address book with a different synchronization extension such as Zindus or Google Contacts?  I always recommend creating a new address book (there should have been a warning when you chose an existing one) and this is a known problem when switching from Zindus and using the same address book (Bug 21368).  The problem is that gContactSync adds all TB contacts to Google and vice versa on the first sync because Zindus stores its synchronization data in a very different way and does not synchronize the same fields.

Yet another bug is that even with "Only syncrhonize 'My Contacts' group" preference *un*-checked gcontactsync will only import contacts created in gmail into thunderbird if they were created in My Contacts group.

When that preference is unchecked do you see all of the mailing lists corresponding to your groups in Gmail?

I've tried both enabling and disabling the Interface preference, "Rename the phone column labels" but can notice no change of behavior at all with either setting.  With either setting, the columns are still called Work, Home, ..., and Work always comes from First, ...

That preference does appear to be broken and will be fixed so the column labels match the new/edit contact dialog.  This bug will contain the details for the fix, which should be in 0.2.8.  The columns will be renamed to First Number, Second Number, Third Number, etc.

This core function of this extension is useful, but there are serious bugs. I see discussion of new versions and would like to suggest that making the current functionality solid is the highest priority, before new functionality is added.

The current functionality is already fairly solid.  The main problem lies in Thunderbird mailing lists and there isn't much I can do about that other than explain why a mailing list broke the address book and why gContactSync has to reset that address book.  I could work on a tool to ease the transition into gContactSync from another add-on but the cost/benefit ratio isn't high enough to work on that before 0.3 when you can just sync with a new address book and remove the old AB.  Phone number types are more of a feature than a bug and it might not be possible to easily add the types to exports.  Basically, every feature is a trade-off and I usually try to pick the most popular choice that works for the majority of users.

[manawiz]

I rarely consult the Thunderbird address book for anything other than a phone number.  It is unnecessary for email addresses as these auto-complete in message correspondent fields, and how often does one use a physical address now-a-days?  I generally look up phone numbers via search in the address book window and have the major phone number types (work, home, mobile) displayed as columns.  So I almost never open an actual card.

Is this usage unusual?  I suspect not.

I've got many hundreds of address book records (recently culled from thousands) spanning decades of contacts of all types (business, personal, ...).  If the address book columns are simply first, second, ..., that would be unusable.  Who can remember whether the first is a home, work, mobile or fax, especially when contacts created in gmail lead to a random order in thunderbird?  The address book window would become useless, creating a requirement to open every card before using a number, which would decrease the productivity of address book substantially.

To me getting phone number types right is more important than anything else.  I would suggest that a person syncing Thunderbird and gmail can only effectively use phone number types that both support.  gcontactsync should work well for that case.  I think all you need to do is to ensure you place the built-in Thunderbird types (Work, Home, Work Fax, Mobile, Pager in TB 2) into the correct positions (First, Second, Third, Fourth, Fifth, respectively).  I don't see why that would affect any translations.

I did not previously use another sync extension, instead doing it with import-export, usually exporting from TB, replacing the header line with one that uses Outlook field names, and then importing to gmail.  Your extension of course makes this much easier, when it works.

School and job and these extensions?  Good for you!  Have you open-sourced the extensions?  (Sorry if this is dumb question since I didn't look to find out.)  Perhaps other users could submit changes to fix this problem, maybe even me.

[Josh Geenen]

Point taken.  I'll see what I can do about this in version 0.3.  If I have the time it will be a global preference and I need to figure out if it should be on or off by default.

To me getting phone number types right is more important than anything else.  I would suggest that a person syncing Thunderbird and gmail can only effectively use phone number types that both support.  gcontactsync should work well for that case.  I think all you need to do is to ensure you place the built-in Thunderbird types (Work, Home, Work Fax, Mobile, Pager in TB 2) into the correct positions (First, Second, Third, Fourth, Fifth, respectively).  I don't see why that would affect any translations.

There are existing strings that were already translated regarding telephone numbers and their descriptions in the column headers (top) and the contact view pane (bottom).  The preference itself would also require a string.

I did not previously use another sync extension, instead doing it with import-export, usually exporting from TB, replacing the header line with one that uses Outlook field names, and then importing to gmail.  Your extension of course makes this much easier, when it works.

That would definitely cause the duplicates; gContactSync assumes that all contacts are new on the first sync.  I could use the old v0.1 algorithm for detecting duplicates but that is painfully slow and I would have to add merging functionality.  It would be nice to know how many people have this problem...  Otherwise I could detect if there are any contacts in the AB during the first sync and prompt them to do a slow merge or assume there are no duplicates.

Have you open-sourced the extensions?

Definitely, I try to make them as open source as possible.  See this thread for how to view or checkout the source of gContactSync.  See this for the Bugzilla project for gContactSync.  The openCRX extension is also open source on http://opencrx.mozdev.org.

[Deviant]

Hi Josh

Would you please clarify what the pref you're proposing will enable/disable? Thanks.

Richard

[tanstaafl]

To me getting phone number types right is more important than anything else.  I would suggest that a person syncing Thunderbird and gmail can only effectively use phone number types that both support.  gcontactsync should work well for that case.  I think all you need to do is to ensure you place the built-in Thunderbird types (Work, Home, Work Fax, Mobile, Pager in TB 2) into the correct positions (First, Second, Third, Fourth, Fifth, respectively).

Point taken.  I'll see what I can do about this in version 0.3.  If I have the time it will be a global preference and I need to figure out if it should be on or off by default.

Fyi, I just realized this was a problem for our Vendors Address Book too...

Its not the end of the world, but it is a real problem, and I wanted to let you know that manawaiz wasn't the only one with this issue. I'm glad to hear that this will be addressed in a future release.

Thanks Josh!

[Josh Geenen]

The preference will basically tell gContactSync to use Thunderbird's existing phone number fields as they are and with no modifications.  Only the first phone number of each type in Google also present in TB would be synchronized.  The existing modifications changed the default phone types in Thunderbird -- Home, Work, Mobile, Pager, and Fax -- to a generic First, Second, etc. and added custom phone number types like Google has which includes all the Thunderbird types and several others.  As mentioned here, the main problem with this is that people can no longer tell which number is which when viewing the list of contacts or doing an advanced search.  The type is visible in the bottom half of the address book window and in the new/edit contact dialog.

I'm not sure how to condense that into one short sentence for the preference.  Maybe something like this:

Modify Thunderbird's phone number fields to more closely match Google's*

* Requires a reset for all synchronized address books

The preference would require all synchronized address books to be reset (all contacts and lists removed from synchronized Thunderbird address books and added back from Google during the next sync) since the order of phone numbers would change.

Thanks for letting me know that you would like this, too, Charles.  It's good to know how many people want something when figuring out what to work on next.

[Deviant]

Thanks for the clarification, Josh.

So do I understand correctly that there is no way to fix the address book column names without reverting to the old behaviour (using Thunderbird's existing fields)?

From my point of view as a user, it's a simple problem as illustrated by this screenshot:



Of course I know that things aren't always that simple, but I'd feel better about it if I could understand why it's not possible at the moment and what could be done about it in the future.

Thanks again.

Richard

[Josh Geenen]

So do I understand correctly that there is no way to fix the address book column names without reverting to the old behaviour (using Thunderbird's existing fields)?

That is basically correct.  gContactSync uses the existing fields, but allows you to change the phone number type (Home, Work, Mobile, etc.) on those fields, and adds a few more fields.

About the screenshot, not all of the third phone numbers are of the same type.  You could have one contact with that Home/Work/Mobile combination and another in that address book with the same numbers but in reverse order.  The third number would be a Mobile number for the first contact, but a Home number for the second contact.

For example:

Contact 1:
John Doe
123-456-7890 Home
234-567-8901 Work
345-678-9012 Mobile

Contact 2:
Jane Doe
456-789-0123 Work
567-890-1234 Mobile
123-456-7890 Home

This is what you wold see in the top part of the address book window:

Name              Work                  Home             Work Fax
John Doe   123-456-7890   234-567-8901  345-678-9012
Jane Doe   456-789-0123   567-890-1234  123-456-7890

[manawiz]

Using Deviant's example, can you populate the upper grid columns based on the names of the fields in the individual cards rather than based on the order of the fields?  The card preview pane at the bottom uses the names, but the placement of numbers into columns in the upper grid is by position.  If the values for each row in the grid columns are instead filled by field name, then all is fixed with no loss of functionality.  As is already the case, for purposes of filling the column values you can ignore any fields for which there is no defined column.

Josh, I think that solution is better if it is reasonably doable.  If not, I think the preference as you've defined it would work at least for me.

Thanks!

[Josh Geenen]

Unfortunately that is not possible because the labels for the fields can vary between contacts.  Deviant's example works only because there is one contact.  Once you have multiple contacts the column labels cannot be accurate.

In my previous post look at the individual contacts' numbers and number types/labels versus the column labels.

So, the preference to leave TB's phone fields alone is all that can be done in this case as far as I can tell.

[tanstaafl]

So, the preference to leave TB's phone fields alone is all that can be done in this case as far as I can tell.

That would be my preference...

Any idea when this change will make it into a new release? We've got people who simply will not listen, and instead of changing the data to the correct field, they change the label, then complain when the column doesn't display the data corresponding to the field label.

[Josh Geenen]

Any idea when this change will make it into a new release? We've got people who simply will not listen, and instead of changing the data to the correct field, they change the label, then complain when the column doesn't display the data corresponding to the field label.

I do not think I will be able to put it into version 0.2 since it would require a fair amount of work and some new strings (which would break the translations).

It is on my TODO list for version 0.3 and I hope to get to it soon.  I still don't have a release date since I never know when I'm going to get a new project/assignment/exam.  I'd like to at least have a beta out before the end of 2009.

If/when it goes in 0.3 it could theoretically be ported back to 0.2, but the preference would have to be 'hidden' (not visible in the Preferences dialog).  It would also require all address books to be reset or the phone numbers could get mixed.  gContactSync cannot (yet) notice when a preference changes and reset address books so it would have to be done manually.

[tanstaafl]

No worries... maybe they'll get the message after the 25th time they have to go back and change it right...