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)
MailNews Core
Profile Migration
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: yulian, Unassigned)
References
Details
(Whiteboard: nab-migrate)
Attachments
(2 files, 1 obsolete file)
2.44 KB,
patch
|
cavin
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
684 bytes,
patch
|
Details | Diff | Splinter Review |
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
Comment 2•23 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•23 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
Comment 4•23 years ago
|
||
taking, fix in hand. fixed as part of the AB_OUTLINER_BRANCH.
Assignee: cavin → sspitzer
Comment 6•23 years ago
|
||
Comment 7•23 years ago
|
||
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•23 years ago
|
||
Comment on attachment 62032 [details] [diff] [review]
patch, please review.
sr=bienvenu
Attachment #62032 -
Flags: superreview+
Comment 9•23 years ago
|
||
Comment on attachment 62032 [details] [diff] [review]
patch, please review.
r=cavin.
Attachment #62032 -
Flags: review+
Comment 10•23 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Whiteboard: nab-migrate
Comment 11•23 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•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
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
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
I've checked in the default pref.
since srilatha owns migration, she's the right owner for this.
Updated•23 years ago
|
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•17 years ago
|
Assignee: srilatha → mail
Status: ASSIGNED → NEW
Priority: P2 → --
QA Contact: nbaca → addressbook
Target Milestone: mozilla1.2alpha → ---
![]() |
||
Comment 18•16 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•16 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•16 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•16 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•16 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•16 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•16 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•15 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
Closed: 23 years ago → 15 years ago
Resolution: --- → EXPIRED
Updated•14 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Comment 26•14 years ago
|
||
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•10 years ago
|
||
4x migration is dead since some years ago
Status: NEW → RESOLVED
Closed: 15 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•