[Bug 600755] Re: Contact import mapping problem

Bug Watch Updater 600755 at bugs.launchpad.net
Thu Feb 3 09:53:33 UTC 2011


Launchpad has imported 20 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=97294.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2001-08-28T14:41:18+00:00 Mythdraug wrote:

Build:  2001082703
Platform: Win32

Observed behavior: 
    Import from CSV.
    Assign field for  LastName and FirstName
   Choose not to import DisplayName (does not exist in file)
   Import.
    DisplayName is blank.

Expected behavior:  
   DisplayName would be populated with the combined "FirstName LastName" or
  "LastName, FirstName"

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/0

------------------------------------------------------------------------
On 2001-08-28T14:45:27+00:00 Mythdraug wrote:

Created attachment 47323
CSV testcase

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/1

------------------------------------------------------------------------
On 2001-08-28T14:50:11+00:00 Mythdraug wrote:

Mapping used in testcase:
    Work Phone        ->     Work
    Last Name           ->     Last Name
    First Name           ->     First Name
    Custom 1              ->     VM Box
    Home Phone      ->     Home
    Pager Number   ->     Pager
    Fax Number        ->     Fax
    Cellular Number->     Cell Phone
    Primary Email     ->     E-mail
    Notes                     ->     Other

All other AB fields were deselected.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/2

------------------------------------------------------------------------
On 2001-11-10T03:01:19+00:00 Verbal-myrealbox wrote:

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/3

------------------------------------------------------------------------
On 2001-11-10T05:32:01+00:00 Choess wrote:

reopening.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/4

------------------------------------------------------------------------
On 2002-02-10T11:29:23+00:00 Spam-minneboken wrote:

bug 101145 had a similar problem with blank Display Name, later fixed in bug
99391.

mythdraug: are you still seeing this bug?

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/5

------------------------------------------------------------------------
On 2002-02-10T15:53:15+00:00 Mythdraug wrote:

Yes.  Just verified that with 2002020703, the testcase above does
not generate a displayname when imported.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/6

------------------------------------------------------------------------
On 2002-09-08T00:16:14+00:00 Sspitzer wrote:

taking all of chuang's bugs.  she doesn't work on mozilla anymore.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/7

------------------------------------------------------------------------
On 2003-04-08T08:43:18+00:00 Sspitzer wrote:

over to cavin

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/8

------------------------------------------------------------------------
On 2004-11-02T22:10:50+00:00 Scott+mozilla wrote:

Created attachment 164315
Patch to 97294

This patch will patch nsTextAddress.cpp/ProcessLine to add the generation of
the "Display Name" field should none be provided by a text-format import. This
should resolve this case.

I would note that other importing modules are not effected by this patch and I
am unaware of whether they suffer from the same lack of functionality. It would
be much more elegant to solve this within AddCardRowToDB but I'm not sure that
is entirely possible without signifigant revision or even needed.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/9

------------------------------------------------------------------------
On 2004-11-02T22:25:19+00:00 Scott+mozilla wrote:

Marked this for review. I'm not sure who is doing the reviewing for this, so I
ended up marking it for two different people; my apologies for the annoyance.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/10

------------------------------------------------------------------------
On 2005-09-17T17:51:07+00:00 Bugzilla-standard8 wrote:

Comment on attachment 164315
Patch to 97294

Thanks for the nice patch, sorry its taken so long for someone to look at it.
Works well, but could do with a couple of tweaks:

+			     switch( fieldNum) {
...
+			     }

Please add in a default: break; option to the switch. Although not strictly
required, I believe its better practice to have one.

+                displayName.Append(PRUnichar(' '));

It should be:

displayName.Append(NS_LITERAL_STRING(" ");

this aviods run-time conversions.

+	     if (!firstName.IsEmpty()) {
+		 displayName = firstName;
+	     }
+	     if (!firstName.IsEmpty() && !lastName.IsEmpty()) {
+		 displayName.Append(PRUnichar(' '));
+	     }

Move the second if inside the first if statement, and that way you can drop the
second check for !firstName.IsEmpty().

If you could update the patch with those changes, and re-request review from
myself, that would be good (hence I assigned the bug to you). If you can't do
that, reassign the bug to the default owner, and let us know.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/11

------------------------------------------------------------------------
On 2005-09-17T18:21:08+00:00 Bugzilla-standard8 wrote:

(In reply to comment #11)
> (From update of attachment 164315 [edit])
> Works well, but could do with a couple of tweaks:

Ok, I've just been reminded that there are localisation issues here. Some
locales require the lastname before the first name. This is currently set via
the preference:

mail.addr_book.displayName.lastnamefirst

See
http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/content/abCardOverlay.js#502
and
http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/content/abCardOverlay.js#307

for how the new card dialog actually does it.

Also, should we have an option to turn this on and off? See bug 180057 for one
example where I added an option to skip the first line of imported files.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/12

------------------------------------------------------------------------
On 2007-03-12T13:01:09+00:00 Evasdk wrote:

currently, in thunderbird 1.5.0.10, our users are really upset about the
lack of such feature. May I ask what's the status of this ? Are we going
to see this in tb-2 ?

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/13

------------------------------------------------------------------------
On 2009-02-19T00:41:58+00:00 Scott+mozilla wrote:

Created attachment 363018
Adds DisplayName generation to text-based import.

I've updated the code to generate names in the same manner that Card's
do (respecting the first/last order and format strings). I am using the
displayName.autoGeneration preference to decide whether to do it or not,
but a checkbox may still be desirable.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/14

------------------------------------------------------------------------
On 2009-02-27T13:58:46+00:00 Mkmelin+mozilla wrote:

Scott: please set the review flag of the patch to the email address of a suitable reviewer - like standard8. 
(See http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree)

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/15

------------------------------------------------------------------------
On 2009-02-27T23:42:36+00:00 Scott+mozilla wrote:

Comment on attachment 363018
Adds DisplayName generation to text-based import.

Updated review flag to Mark Banner.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/16

------------------------------------------------------------------------
On 2009-03-02T12:13:30+00:00 Bugzilla-standard8 wrote:

Comment on attachment 363018
Adds DisplayName generation to text-based import.

>+#define PREF_MAIL_ADDR_BOOK_DISPLAYNAME_AUTOGENERATION
"mail.addr_book.displayName.autoGeneration"

I think we should expose this in the import UI. Some people may not have
display names, and prefer not to generate them, I've just cc'ed our
user-experience guy in case he disagrees.

>+                            case 2:
>+                                hasDisplayName = PR_TRUE;
>+                                break;

What about the case where the user has chosen to import an existing
address book, but hasn't got a display name in some/all rows?

>+            } else if (!primaryEmail.IsEmpty()) {
>+                // see bug #211078
>+                // if there is no generated name at this point
>+                // use the userid from the email address
>+                // it is better than nothing.
>+                displayName = primaryEmail;
>+                PRInt32 index = displayName.FindChar('@');
>+                if (index != -1)
>+                    displayName.SetLength(index);

I'm not sure we want to copy this clause. If we haven't got a first/last
name then I think generating one from the email in this case isn't such
a good idea, and we should just give up.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/17

------------------------------------------------------------------------
On 2009-03-02T12:22:21+00:00 Scott+mozilla wrote:

(In reply to comment #17)
> I think we should expose this in the import UI. Some people may not have
> display names, and prefer not to generate them, I've just cc'ed our
> user-experience guy in case he disagrees.
> 
> What about the case where the user has chosen to import an existing address
> book, but hasn't got a display name in some/all rows?

With that in mind, I would agree that having a check box (defaulting to
the state of the preference in
mail.addr_book.displayName.autoGeneration) would be best. In that case,
the user can make the decision if only some rows have display names. In
the case that the user would like to replace all of the display names,
they could simply uncheck importing that field while auto-generate was
enabled.

> >+            } else if (!primaryEmail.IsEmpty()) {
> >+                // see bug #211078
> >+                // if there is no generated name at this point
> >+                // use the userid from the email address
> >+                // it is better than nothing.
> >+                displayName = primaryEmail;
> >+                PRInt32 index = displayName.FindChar('@');
> >+                if (index != -1)
> >+                    displayName.SetLength(index);
> 
> I'm not sure we want to copy this clause. If we haven't got a first/last name
> then I think generating one from the email in this case isn't such a good idea,
> and we should just give up.

Having now read bug #211078, I would agree it was an ill-advised copy.

I will wait to hear the opinion of the user-experience guy before
revising further.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/18

------------------------------------------------------------------------
On 2009-03-02T12:23:20+00:00 Scott+mozilla wrote:

Comment on attachment 363018
Adds DisplayName generation to text-based import.

Removed review flag pending suggested UI changes.

Reply at: https://bugs.launchpad.net/thunderbird/+bug/600755/comments/19


** Changed in: thunderbird
       Status: Unknown => In Progress

** Changed in: thunderbird
   Importance: Unknown => Wishlist

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to Mozilla.
https://bugs.launchpad.net/bugs/600755

Title:
  Contact import mapping problem




More information about the Ubuntu-mozillateam-bugs mailing list