Closed Bug 80446 Opened 24 years ago Closed 24 years ago

Importing Outlook Contacts doesn't import email addresses

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P2)

Product:
SeaMonkey
Component:
MailNews: Address Book & Contacts
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: ben, Assigned: chuang)

References

Details

(Keywords: dataloss, helpwanted, Whiteboard: [nsbeta1+][PDT+]have fix)

Attachments

(5 files)

Patch for the fix
4.89 KB, patch
Details | Diff | Splinter Review
New patch for trunk - add PR_EMAIL_ADDRESS code back
1.02 KB, patch
Details | Diff | Splinter Review
Patch for 0.9.2 branch
4.84 KB, patch
Details | Diff | Splinter Review
New trunk patch - fix memory leak
1.98 KB, patch
Details | Diff | Splinter Review
New 0.9.2 branch patch - fix memory leak
4.98 KB, patch
Details | Diff | Splinter Review
When I import my Outlook 2000 Contacts into build 20010509, Mozilla will import all of the names, addresses, everything, but not one email address. Can reproduce repeatedly.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
Ninoschka, can you reproduce this?
Yes, I can duplicate the problem. I'll set QA Contact to Fenella because she tests importing address books.
QA Contact: esther → fenella
Note: I used build 2001-05-22-04, WinMe when I duplicated the problem.
moving to 0.9.2.
Keywords: nsbeta1
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.2
Win32 (2001-05-23-06 trunk) Confirm the bug. But when I import outlook express address book, email addresses show up.
We failed to get the email address from Win32 MAPI api IMAPIProp::GetProps() using property "PR_EMAIL_ADDRESS". Others are fine. I need help from someone knows Outlook Contacts format and MAPI apis.
Keywords: helpwanted
This problem is still there using win32(2001-05-30-06 trunk)
Use the Outlook Spy, I can't see email address property. Still looking..
adding PDT+
Whiteboard: [nsbeta1+] → [nsbeta1+][PDT+]
*** Bug 86214 has been marked as a duplicate of this bug. ***
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Keywords: nsenterprise
Keywords: nsBranch
Whiteboard: [nsbeta1+][PDT+] → [nsbeta1+]
This still happens in the trunk on Win98, importing Outlook 2000 address book. No email addresses are migrated.
That's why we haven't marked it fixed :-)
I'm getting close to have a fix, I need to test on different machines and do more testing.
Whiteboard: [nsbeta1+] → [nsbeta1+]have fix
r=bienvenu
Note: I have found the mapi IDs for the 3 email addresses Outlook stores. The strange thing is Outlook save each email address in 2 IDs. I also found the GUID for the email property. Combined the IDs and GUID, we can find the property tag for the email address and find value for the email address. I have tested on different machine to make sure these IDs are machine independant. We can't use PR_EMAIL_ADDRESS in Outlook. But PR_EMAIL_ADDRESS is working for Outlook Expres.
I'm putting my faith in Candice here as I don't fully understand this import code. It looks okay to me sr=mscott
Candice, can you check this onto the trunk first and then we'll get this tested before we try landing on the branch.
Fix checked into trunk
Keywords: vtrunk
Win32 (2001-07-06-09 trunk) This bug is fixed.
trunkverified
There is concern that "PR_EMAIL_ADDRESS" will be used again in Outlook, so I was asked to put the code for checking if "PR_EMAIL_ADDRESS" is used or not. If it failed than use the IDs in the fix. I'll put the original code back for "PR_EMAIL_ADDRESS". There are two patches, one for trunk and one for 0.9.2 branch.
I have attached the newer patch. It fixed two memory leaks pointed by Cyrille at Sun. He has reviewed the patch today. I'll add r=Cyrille.Moureaux@Sun.com
adding PDT+
Whiteboard: [nsbeta1+]have fix → [nsbeta1+][PDT+]have fix
looks good to me. r=mscott
Change r=mscott to sr=mscott per our email.
Fix checked in both trunk and 0.9.2 branch.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Win32 (2001-07-10-05-0.9.2) This bug is fixed in the branch.
Win32 (2001-07-10-08 trunk) I tried to verify this bug using the trunk build but unable to do so because of bug 90206. Both Esther and I tried it today using win32 (2001-07-13-10 trunk). Still unable to do so because of bug 90206. Both Esther and I are using win_nt 4.0. Will try using win 2000 to see if this is OS specific.
Ninaschka tried it on her win_me system using both branch and trunk and 6/7 build, unable to find the outlook address book too.
I don't understand. Pls summarize your findings for branch and trunk. Does this mean that this bug's fix is not correct and we have to reopen this PDT+ bug? Your comments say this is fixed on the branch and then it says that the bug still shows up on the branch and trunk. The other bug you mention shows a bug on the branch. Do we need to bring that other bug to someone's attention?
Keywords: vtrunk
Fenella's last comment is refering to bug 90206. I can't reproduce bug 90206. So on my machine, this bug is fixed when using trunk and branch build.
Using both the trunk and the branch (the 15th build), and Outlook 2000 on an Windows 2000 machine, File | Import | Address Books was unable to find any Outlook addressbook.
Lisa, we have seen inconsistently behavior in Importing Address Book from Outlook. So I log bug 90206 to bring the problem to someone's attention. . On 7/6/01, since I was able to import Outlook in the trunk build, I was able to comment that this bug was fixed. . On 7/10/01, I used the branch build, I was able to import Outlook address book, so I commented that this bug was fixed. . But then on 7/13 and 7/16 builds, we tried win me, win_nt and window 2000, we were unable to import Outlook Address Book.. which means we are not able to re-test this bug using the current build... My suggestion is for us to close this bug since I have verify the email id bug was fixed in both Branch and trunk in the earlier builds. If I see this bug again when bug 90206 is fixed. And will re-open this bug if it come back again. Anyone disagree??
Status: RESOLVED → VERIFIED
*** Bug 49733 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: