second phase of account manager modernisation. Use standard pref and WSM classes.

Is this just a programatic change or is there a UI change associated with this?

programmatic. It should make it consistent in how to specify prefs in mailnews and global prefs. It's not absolutely necessary for fufilling the enterprise requirements, but I think it would be nice. And by not doing this, it makes specifying lockable prefs optional which should not be the case.

To clarify the optional pref comment: I mean that new prefs added to mailnews will not be locked if the programmer is not aware of the extra step needed to disable xul elements which are locked. For instance, the offline imap and ldap directory code recently added will not lock because they were not aware of the special incantations.

Moving to 0.9.3 per mgmt triage.

pref locking issue, QA should go to me since this is my area. adding esther to Cc. Esther, if you feel you should own this one let me know.

moving milestone

changing milestone

This first attachment is a diff of a work in progress. Formatting is bad, and unnecessary functions are still lying around. At this point, I'm just trying to get the damn thin working. The main point is that AccountManager is being driven by nsPrefWindow. There is one problem that I hope someone can help with, because I'm absolutely stumped. In AccountManager.js:524 there is an alert statement which used to be a dump statement. When it's a dump statement, the panel is populated with values (by onpageload) and then is mysteriously cleared. When it's an alert statement (or when I use the js debugger) the panel doesn't get cleared. ?!!?!?! Very confusing and causing me some distress. The function onAccountClick() is called when an item in the tree is selected. This is different from the behavior of the global pref dialog, which calls switchPage in nsPrefWindow. Comments in onAccountClick() should hopefully explain the situation more fully. Any suggestions on how to figure this one out?

I've added another attachement. It is cleaned up and in a working state. The Account Manager dialog is now using a slightly modified nsPrefWindow to load, display and save mail/news prefs. The majority of the am-*.xul panels still need to be updated to be nsPrefWindow friendly. But if you apply the patch you can see the am-main panel fully working. However I would like comments and suggestions at this point from Ben or anyone else on the modifications and usage of nsPrefWindow in this patch. Thanks,

marking nsenterprise-.

mail/news bug ->putterman

reassigning to racham.

Renominating for nsbeta1. This is needed by the Enterprise to customize the client.

> This is needed by the Enterprise to customize the client. jaime, can you elaborate on how this is needed for client customization?

Tao would be better able to explain the enterprise need. However, my poor recollection tells ME, sys admins in enterprises need the capability to control accounts for their users.

Seth, when this bug was originally filed by eddy, he wanted to have a simpler way of locking down NEW preferences added to the Mail & News Account Settings. At the time, we were working on the various preference locking issues for the mail/news account settings. I had to go through and find out which preferences weren't lockable....file a bug....and eddy would go in and try and lock it down according to his pref locking guidelines. see newsgroup posting: news://news.mozilla.org/3AC8F5D2.6CA02623%40netscape.com . Since more prefs were being added to the mail/news account settings pref window (for example bug 86778) he figured it would be best to file this bug so that any new preference added to Mail/News account settings would automatically be locked, regardless of the engineer following his locking spec. So now we in customization engineering have a need to lock down all the preferences specified in the Mail/news account settings. If a solution can be found, it would "kill many birds (well actually bugzilla bugs) with one stone".

adding nsbeta1- since it sounds like we don't need this to do the customization work we have to.

I'm doing related work in bug 167561; in particular, I hope to land the nsPrefWindow.js chunk of this patch shortly.

mass re-assign.

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