Closed Bug 94641 Opened 24 years ago Closed 10 years ago

4.7 pref for Pinpoint addressing does not migrate correctly

Categories

(MailNews Core :: Profile Migration, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: yulian, Unassigned)

References

Details

(Whiteboard: nab-migrate)

Attachments

(2 files, 1 obsolete file)

Address Book was not checked under Pinpoint Addressing in my 4.x prefs file. After migration, Local Address book was checked under Address Autocompletion. Steps: 1. In Communicator, launch Preferences/Mail&Newsgroups/Addressing window 2. Check Address Books under Pinpoint Addressing and save it 3. Do clean installation of N6.1 and migrate the profile with above settings 4. In N6.1, launch Preferences/Mail&Newsgroups/Addressing window actual result: Local Address books is checked under Address Autocompletion Expected result: Local Address books shouldn't be checked under Address Autocompletion
QA Contact: fenella → nbaca
reassigning to cavin
Assignee: chuang → cavin
Marking nsbeta1. The workaround is easy, just deselect the Address Collection|Local Address Book checkbox but migration should handle this case.
Keywords: nsbeta1
Changing summary from "Address Book prefs wasn't correctly migrated" to "4.7 pref for Pinpoint addressing does not migrate correctly".
Summary: Address Book prefs wasn't correctly migrated → 4.7 pref for Pinpoint addressing does not migrate correctly
taking, fix in hand. fixed as part of the AB_OUTLINER_BRANCH.
Assignee: cavin → sspitzer
this bug should be XP.
OS: Windows NT → All
Hardware: PC → All
the problem is we chose a new pref name, instead of the old 4.x pref name. see #37955 (may 2000) two ways to go about fixing this: 1) fix the added .js, .xul and default pref (in mailnews.js) to be how it was in 4.x: "ldap_2.autoComplete.useAddressBooks", and write code to fix existing users 6.x prefs. 2) add migration code for 4.x to 6.x, and leave existing 6.x users prefs alone. this patch does #2.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Comment on attachment 62032 [details] [diff] [review] patch, please review. sr=bienvenu
Attachment #62032 - Flags: superreview+
Comment on attachment 62032 [details] [diff] [review] patch, please review. r=cavin.
Attachment #62032 - Flags: review+
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: nab-migrate
Trunk build 2002-02-01-03: WinMe Trunk build 2002-02-01-08: Linux RH 7.1 Reopen, still a problem. Haven't checked mac yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.8 → mozilla0.9.9
looking at the code, the lack of a default should not have caused the problem. if the default was true, it that would mean the pref wouldn't be there, so this code (if hit) would do nothing. that's ok, since the default in mozilla is also true. I'm wondering if this code isn't getting hit for some reason (news migration failure, causes us to bail early?)
Status: REOPENED → ASSIGNED
Attached patch partial patchSplinter Review
a partial patch. I think this is going to be a news migration issue. I'll ping for reviews once I get a complete patch.
Attachment #67975 - Attachment is obsolete: true
ok, I see what's going on. if I migrate, but launch mail (or addressbook) before checking your prefs, it works. the messenger migrator code gets run the first time you do any thing mail related. if I migrate, and check prefs (from the browser), before I do anything mail related, it won't get migrated. this isn't normally an issue because most mailnews pref migration affects the account manager, which can only be reached from the 3 pane. one exception to this is the addressbook prefs, which are visible from the prefs and can be reached from the prefs. note, there is some necessary ldap autocomplete pref migration that nsMessengerMigrator.cpp is doing. I think there might be some other ldap autocomplete migration code else where, too. I think the fix for this will be to: 1) move all the ldap autocomplete migration code to nsMessengerMigrator.cpp 2) add the js code to the mailnews pref overlays to check if need to migrateand if necessary perform migration when loaded.
I discussed this with srilatha over aim. There is code that does ldap / pref migration code Its in nsLdapPrefsservice.js in mailnews/addrbook/src the addressbook migration code in nsMessengerMigrator.cpp just migrates the "autcomplete against local addressbooks" pref (see http://bugzilla.mozilla.org/attachment.cgi?id=62032&action=view) and, if you've got an ab upgrader (only NS 6.x build have this), we'll migrate the local 4.x na2 files to .mab files. there is other code that converts some ldap_2.* prefs into UTF-8. see nsPrefMigration.cpp we can't just move the ldap migration code from nsLdapPrefService.js to nsMessengerMigrator.cpp, because that code is need to migrate users from Netscape 6.0 (and mozilla 0.9.something) to modern builds, not just from 4.x to modern builds. so, I think the proper solution for this bug is to do this: leave the nsLdapPrefsService.js code alone. leave the nsPrefMigration.cpp code alone leave the nsMessengerMigrator.cpp code alone add some code to the mailnews pref overlay js to call the upgrade code in nsMessengerMigrator. we should treat prefs like a mailnews window (but only if mailnews is installed), and force migration of prefs when the window comes up. the fix for this will look like this code: http://lxr.mozilla.org/mozilla/source/mailnews/base/prefs/resources/content/acco untUtils.js#150 since she owns migration, I'm going to hand this over to srilatha to fix. I'll land the "partial patch" (which defines the 4.x default) for completeness, but it will not affect fix this problem. srilatha, can you log a new bug about moving the migration code from nsLdapPrefsService.js into nsMessengerMigrator.cpp? note, we can only do that work once we don't think people will be migrating from 6.0 to modern builds. until then, the code needs to stay where it is.
Assignee: sspitzer → srilatha
Status: ASSIGNED → NEW
I've checked in the default pref. since srilatha owns migration, she's the right owner for this.
Blocks: 122274
Status: NEW → ASSIGNED
Keywords: nsbeta1nsbeta1-
Priority: -- → P2
Target Milestone: mozilla0.9.9 → mozilla1.2
Product: Browser → Seamonkey
Assignee: srilatha → mail
Status: ASSIGNED → NEW
Priority: P2 → --
QA Contact: nbaca → addressbook
Target Milestone: mozilla1.2alpha → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → EXPIRED
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
By courtesy of MXR, this seems still an issue.
Assignee: mail → nobody
Status: UNCONFIRMED → NEW
Component: MailNews: Address Book & Contacts → Profile Migration
Ever confirmed: true
Product: SeaMonkey → MailNews Core
QA Contact: address-book → profile-migration
4x migration is dead since some years ago
Status: NEW → RESOLVED
Closed: 15 years ago10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: