Comment 18 for bug 600755

(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.