4.7 pref for Pinpoint addressing does not migrate correctly

RESOLVED WONTFIX

Status

MailNews Core
Profile Migration
RESOLVED WONTFIX
16 years ago
3 years ago

People

(Reporter: yulian chang, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nab-migrate)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

Updated

16 years ago
QA Contact: fenella → nbaca

Comment 1

16 years ago
reassigning to cavin
Assignee: chuang → cavin

Comment 2

16 years ago
Marking nsbeta1. The workaround is easy, just deselect the Address
Collection|Local Address Book checkbox but migration should handle this case.
Keywords: nsbeta1

Comment 3

16 years ago
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
Created attachment 62032 [details] [diff] [review]
patch, please review.
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 8

16 years ago
Comment on attachment 62032 [details] [diff] [review]
patch, please review.

sr=bienvenu
Attachment #62032 - Flags: superreview+

Comment 9

16 years ago
Comment on attachment 62032 [details] [diff] [review]
patch, please review.

r=cavin.
Attachment #62032 - Flags: review+
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Whiteboard: nab-migrate

Comment 11

16 years ago
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 → ---

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Created attachment 67975 [details] [diff] [review]
define default for 4.x pref in mailnews.js (in 4.x, this value lived in all.js)
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
Created attachment 67982 [details] [diff] [review]
partial patch

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.

Updated

16 years ago
Blocks: 122274
Status: NEW → ASSIGNED
Keywords: nsbeta1 → nsbeta1-
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 → ---

Comment 18

9 years ago
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

Comment 19

9 years ago
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

Comment 20

9 years ago
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

Comment 21

9 years ago
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

Comment 22

9 years ago
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

Comment 23

9 years ago
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

Comment 24

9 years ago
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

Comment 25

8 years ago
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
Last Resolved: 16 years ago8 years ago
Resolution: --- → EXPIRED

Updated

6 years ago
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

Comment 27

3 years ago
4x migration is dead since some years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.