79305 - Use the WSM and nsPreferenceWindow for account manager.

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Account Configuration, enhancement)

Description

[eddyk]

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

Comment 1

[scottputterman]

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

Comment 2

[eddyk]

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.

Comment 3

[eddyk]

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.

Comment 4

[Jussi-Pekka Mantere]

Moving to 0.9.3 per mgmt triage.

Comment 5

[Rodney Velasco]

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.

Comment 6

[eddyk]

moving milestone

Comment 7

[eddyk]

changing milestone

Comment 8

[eddyk]

Attachment: development patch. kinda works.

Comment 9

[eddyk]

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?

Comment 10

[eddyk]

Attachment: working patch. need comment

Comment 11

[eddyk]

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,

Comment 12

[grega]

marking nsenterprise-.

Comment 13

[tao]

mail/news bug ->putterman

Comment 14

[scottputterman]

reassigning to racham.

Comment 15

[Jaime Rodriguez, Jr.]

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

Comment 16

[(not reading, please use [e-mail] instead)]

> This is needed by the Enterprise to customize the client.

jaime, can you elaborate on how this is needed for client customization?

Comment 17

[Jaime Rodriguez, Jr.]

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.

Comment 18

[Rodney Velasco]

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".  

Comment 19

[scottputterman]

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

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 21

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 22

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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 26

[Robert Kaiser]

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 27

[Robert Kaiser]

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