61078 - Ability to Change Order of Accounts

Status: NEW

(SeaMonkey :: MailNews: Account Configuration, enhancement, P5)

Description

[Brian Z]

I would really like to see a feature that allows the user to change the order
that the accounts appear for selection.  Currently, I recreated the accounts in
the order I wanted, but this took a lot of time.  Thanks!  Keep up the good work!

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Do you want this in the account manager or in the folder pane window?

Comment 2

[Brian Z]

Probably the account manager window.  That way people will only do it if they
know what they are doing.  Thanks!

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Ninoschka - do you want this?

Comment 4

[Ninoschka Baca]

I'll take it, thanks.

Comment 5

[Ninoschka Baca]

Adding keyword Mail3. The ability to change the order of accounts is important
so the user feels in control. So they can view their information in their own way.

Comment 6

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

moving to mail window front end.

re-ordering the accounts would happen there.

Comment 7

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 8

[jglick]

"Move Up" and "Move Down" buttons or drag n drop or both?

Comment 9

[scottputterman]

If we can make move up and down work then I think that's enough. Any other opinions?

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

Would we want arrows here? Or a simple SHIFT+highlight and then holding down
SHIFT you move the cursors?

Comment 11

[Brian Z]

Personally, I think the up and down arrors are a necessity (to make people
realize that this is possible).  We should try to get that working first.  Then
we could add drag and drop ability (which may make it easier for some people -
being how Windows & Mac Work) later as we have time.  Thanks guys!  I'm looking
forward to this feature! :)

Comment 12

[Matthew T (active 1999-2002)]

There should be a standard meta-widget (a tree, with `Up' and `Down' buttons, 
and support for drag and drop) for reordering lists. See also bug 45412.

Comment 13

[scottputterman]

reassigning to racham.

Comment 14

[scottputterman]

moving to mozilla0.9

Comment 15

[Håkan Waara]

Exactly where would these two "Up" and "Down" buttons be located? I don't
understand this..

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

Hwaara, in the account manager, either to the left or to the right (I'd prefer
the right) of the account listings. I bet jglick can make a good mockup of this.

Comment 17

[jglick]

Might not fit to the left or right because space is tight. How about below with
the other buttons?

Comment 18

[jglick]

Attachment: Example Screen shot of Move Up/Move Down buttons

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

Yeah, that looks good to me ;-)

Comment 20

[scottputterman]

marking nsbeta1- and moving to future milestone.

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 77295 has been marked as a duplicate of this bug. ***

Comment 22

[Aleksey Nogin]

After looking at the related Bugzilla bugs, I realized there there have been
quite a few back-and-forth changes related to the account order.

First, bug #10215 asked for an ability to reorder the accounts. _This ability
was implemented_ and after that
user_pref("mail.accountmanager.accounts", "accountX, accountY, accountZ")
could be used to reorder the accounts.

Next bug #43848 asked for some default sort order and it was implemented too -
the accounts were reorderer as Mail - Local - News. But within each category
"mail.accountmanager.accounts" still dictates the order. Currently, this works
in a really strange way - if "mail.accountmanager.accounts" specifies the order
as "News3, News2, Local, Mail1, News1", then the displayed order would be
"Mail1, Local, News3, News2, News1", but the order in
"mail.accountmanager.accounts" _would not_ be changed when the prefs.js is written.

Now my question is - what exactly does is this bug report asking for? In
particular, I believe that the following questions need to be answered:
1) Which of the "mail.accountmanager.accounts" and Mail-Local-News orders should
take precedence when they disagree? In particular, do we want to allow orderings
that would disagree with the Mail-Local-News order?
2) If "mail.accountmanager.accounts" prevails, should we be able to tell
Mozilla, to resort in Mail-Local-News order?
3) If Mail-Local-News order prevails, should "mail.accountmanager.accounts" be
updated to reflect the actual order?
4) Should we be able to reorder accounts in "Accounts settings" menu (as the
attached gif shows), or by D&D in "Mail Folders" pane, or both?

Comment 23

[Brian Z]

I filed this bug hoping for the ability to reorder accounts in "Accounts 
settings" menu (as the attached gif shows).  Drag and Drop may get too 
confusing, plus it would take more memory.  IMHO, let's keep it small, simple, 
and effective.  Thanks a ton!

Comment 24

[Brian Z]

Nominating mozilla1.0.1

Comment 25

[brian]

Another way to implement this feature for the front end is to use the same
principles as moving bookmarks around, just click and drag your account to
wherever you want it. This way there is consistency within the interface of
mozilla. I think that would be small/simple/effective.

Comment 26

[Chase Tingley]

*** Bug 96800 has been marked as a duplicate of this bug. ***

Comment 27

[Peter Lairo]

Here is some text from the duped bug. Particularly, the separator lines might be
a good idea:

We should have "move up" and move down" buttons in the "Mail/News Account
Settings". 

Then we would also need two horizontal lines to delineate between the "mail
accounts *|* local folders *|* ewsgroups", because the moving cannot (should
not) go beyond ones own subgroup (mail accounts | local folders | newsgroups).
Another bug?

How it should look like:

+----------------------------------------------+
| [e-mail]
| [e-mail]
| [e-mail]
| ----------------------------------------
| Local Folders
| ----------------------------------------
| newsgroup1
| newsgroup1
| newsgroup1
|
+----------------------------------------------+
|   [ Move up ]  [ Move Down ]
| 
|   [ New Account    ]
|   [ Set as Default ]
|   [ Remove Account ]
+----------------------------------------------+

1. The buttons should be grayed out if "Local Folders" is selected (unmovable).

2. The *Move-Down button* should be grayed out if selection is at the *bottom of
a group*.

3. The *Move-Up button* should be grayed out if selection is at the *top of a
group*.

Comment 28

[zottel]

I'm a little surprised that some comments here suggest that the user should not
be able to change the order of mail/local/news accounts in any way they like.
Personally I would like to have the local folder at the very top, others will
like a different order... I think that should be up to the user. Maybe, as a
compromise, a "restore defaults" button could be added.

Comment 29

[mental]

*** Bug 138037 has been marked as a duplicate of this bug. ***

Comment 30

[Matthias Versen [:Matti]]

*** Bug 148239 has been marked as a duplicate of this bug. ***

Comment 31

[David Tenser [:djst]]

I totally agree with comment #28. All accounts should be movable, including
Local Folders. You should be able to mix news and mail accounts if you like.

Comment 32

[Alex Bishop]

*** Bug 155951 has been marked as a duplicate of this bug. ***

Comment 33

[Alfonso Martinez]

*** Bug 161057 has been marked as a duplicate of this bug. ***

Comment 34

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

varada, here are some suggestions on how to work on this bug.

1) start with the how you are going to sort stuff in the folder pane (and
account manager tree).  you are going to need to monkey with the account manager
datasource to do this.

in nsMsgAccountManagerDS.cpp, look for this line:  "handle sorting of servers"

add a new attribute (to nsIMsgIncomingServer) for "sortOrder".  it will be
persisted in prefs.  fix the code to use it.  you're probably going to have to
write code to set up these values (as they won't exist), and when adding a new
server, to set the "sortOrder" to be the biggest sort order + 1.

you'll probably be removing FindServerIndex() in nsIMsgAccountManager, as it
will no longer be used.

so once you do all this, you should be able to exit, tweak prefs, restart, and
things should be in another order.

the next step:

2) make it so when the pref changes, the folder pane updates.  (you'll need this
later.)

I haven't touched on how the account manager tree might work (as it starts in
the current sort order, and can be changed).

but let's start here.

Comment 35

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

for those playing along at home, here's a summary of where varada's going:


saspitzer: so we should default sortOrder to -1 in mailnews.js
saspitzer: and then
saspitzer: you'll want a helper method, probably on the account manager
saspitzer: that looks at all the incoming servers
saspitzer: and determines the "next" number
saspitzer: we'll want that for new account creation
saspitzer: for backward compat
saspitzer: you'd do this:
saspitzer: in that code that checks the sortOrder in the amds,
saspitzer: if you get a -1
saspitzer: you better call the old code
saspitzer: to generate and set the sort orders for all servers.
saspitzer: folder sort order is a different beast

saspitzer: so instead of returning that value as the sort order, stuff it into 
the sortOrder attribute.
saspitzer: they are all ints, right?
saspitzer: 1001,1002,2001,etc
saspitzer: right, so if you get -1
saspitzer: since existing the code works, use it.

saspitzer: now, when we go about reordering
saspitzer: the normalization code (you haven't gotten to this yet)
saspitzer: will probably adjust back to 1,2,3,4,5
saspitzer: but for now
saspitzer: leave it be.

saspitzer: about smtp
saspitzer: unless there is a bug about not wanting it at the bottom
saspitzer: leave it at the bottom

saspitzer: don't get ahead and start worrying about normalization.
saspitzer: about the sort order of folders, don't touch that either.

saspitzer: don't worry about moving up and down we need to change the sortOrder 
numbers and then refresh the tree list
saspitzer: it's more involved than that.

saspitzer: for now, just worry about the folder pane.
saspitzer: and how it will work.
saspitzer: we'll worry about that later.

saspitzer: first, this step, and second, the step about asserting the change in 
the ds when the pref chagnes.
saspitzer: but for now, just this first step.

saspitzer: the way we're approaching sort will also allow us to do dnd of 
accounts in the folder pane, very easily
saspitzer: we might end up doing that
saspitzer: instead of the account manager UI
saspitzer: since it's cleaner.
saspitzer: we'd do this:
saspitzer: on drop, adjust / normalize the sortOrderValues, and since 
eventually you'll be adding code to assert changes into the account manager ds 
(which will udpate all listeners, like the folder pane), it would just work.
saspitzer: but that is getting ahead.

Comment 36

[varada]

Attachment: Patch V 1.0

First patch. Added new attribute 'sortOrder' to nsIMsgIncomingServer and
persisted the value in prefs. Added new ServerOrderSort to
nsMsgAccountManagerDS. For backwards compatibility we default the value of
sortOrder to their existing folder name index. Have to write a helper function
to assign the highest sortOrder number + 1 to the new accounts - they are not
assigned anything currently and once they are added will appear at the end of
the accountmanager tree. After closing down the dialog or after a refresh they
will appear in the right order. The current order is 
<Default Account>
<Other Accounts>
Local Folder
News Accounts
Outgoing Server (SMTP).

Comment 37

[varada]

reassigning.

Comment 38

[varada]

forgot to add the changes to the front end - xul and js files - coming up.

Comment 39

[varada]

Attachment: Changes to AccountManager .js, .xul and .dtd

This also contains the changes for some rules to filter out only the default
account and make it bold(changes to css follow in next attachment). I have
changed the name for some buttons in account manager as per jennifer's
screenshot and added some accesskeys as well. The Move up and Move Down
functions are as yet not implemented.

Comment 40

[varada]

Attachment: Changes to accountmanage.css

Added new class for making treecell label bold for default accounts.

Comment 41

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

I think your first patch is getting pretty close.
the folder pane (which is what we're focusing on, right?) uses 
kNC_FolderTreeNameSort.  

I think you should just remove the kNC_ServerOrderSort stuff, and replace the
existing sort code to use your new code.

to test, you'd exit, twiddle prefs, restart, and make sure the folder pane has
been resorted.

for now, don't worry about the sort order in the account tree, or the up down
UI, or the bold default UI.  (we'll get to that later.)

Comment 42

[varada]

Attachment: Patch V1.1

Got rid of the new nsIRDFResource and re-used existing resource. The sorting in
the accountmanager by the manipulation of the prefs is reflected in the
folderpane as well.

Comment 43

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

1)

didn't you also change mailnews.js?  can you attach a new patch with that change
as well

2)

// this is a hack for now - hardcode server order by type

this code is no longer a hack.  it's how we determine the default sort order,
using the type, but the user
will be able to override it.  can you update the comment?

3)

+NS_IMETHODIMP
+nsMsgIncomingServer::GetSortOrder(PRInt32 *aSortOrder)
+{
+    nsresult rv;
+    NS_ENSURE_ARG_POINTER(aSortOrder);
+    rv = GetIntValue("sortOrder", aSortOrder);
+
+    return rv;
+}
+
+NS_IMETHODIMP
+nsMsgIncomingServer::SetSortOrder(PRInt32 aSortOrder)
+{
+    nsresult rv;
+    rv = SetIntValue("sortOrder", aSortOrder);
+    return NS_OK;
+}

Can't you just use the NS_IMPL_SERVERPREF_INT macro?

4)

it's hard to read the patch, but it looks like after your change the default
server is *always* the topmost
even if I override it in prefs.  if I'm right, you don't want this if check
where you've got it:

+    else if (isDefaultServer(thisServer))
+      str = NS_LITERAL_STRING("0000");
     else {

you want to move that so that we do that if the serverSortOrder is -1

Comment 44

[varada]

Attachment: Patch V 1.2 (needs an update)

Changed the comment about the hack. Used the macro for retrieving the prefs.
Moved the default check to inside the sortOrder== -1 check.

Comment 45

[varada]

Attachment: added new default sortOrder pref in mailnews.js

Comment 46

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

why are you removing this check:

-    // only answer for servers!
-    if (NS_FAILED(rv) || !server)
-        return NS_RDF_NO_VALUE;
-

and replacing it with:

+    if (NS_FAILED(rv) || !server) 
+      str.AppendInt(4000);

is that for smtp servers?  They are already appearing the right place in the
account manager tree, without this fix.  (and they don't show in the folder
tree.)  I'm not sure I understand.

in the debugger, what hit's this "4000" line?  Is it smtp servers from the
account manager tree?  folders?

Comment 47

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

from your patch, the code in your tree looks like this:

+      PRInt32 serverSortOrder;
+      rv = server->GetSortOrder(&serverSortOrder);
+      if(serverSortOrder == -1) {
+        if (isDefaultServer(server))
+          str = NS_LITERAL_STRING("0000");
+        nsCOMPtr<nsIMsgAccountManager> am = do_QueryReferent(mAccountManager);
+
+        rv = am->FindServerIndex(server, &serverSortOrder);
         if (NS_FAILED(rv)) return rv;
+
+        // we determine the server sortOrder for existing accounts by using the
+        // numerical index obtained from FindServerIndex.
         nsXPIDLCString serverType;
         server->GetType(getter_Copies(serverType));
+
         if (nsCRT::strcasecmp(serverType, "none")==0)
+            serverSortOrder += 2000;
         else if (nsCRT::strcasecmp(serverType, "nntp")==0)
+            serverSortOrder += 3000;
         else
+            serverSortOrder += 1000;     // default is to appear at the top
+        server->SetSortOrder(serverSortOrder);
+      }
+      str.AppendInt(serverSortOrder);

look at the code path for the default server. it does more code than necessary
and, look what it will set the server sort order to, and look what str will be
afterwards ("0000-1").

it also looks like you wont be setting the server sort order correctly for the
default server, so the next time through, when the prefs are set, there could be
cases where the default server is not the top most.

make sure when testing this code that you are are clearing the sort order
entries in your prefs.js, so that you test the migration case, and then exit and
restart, to test the case where sort order prefs are set.

Comment 48

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

Make sure to test this code well in both cases:  when the sort order pref is
set, and when it's not.

Also, make sure we are generating the proper sort order string.  Looking at the
existing code (and your patch), I'm not sure we do the right thing once the user
has over 10 accounts.
Let me know if I'm wrong.

If you think you've got a patch that works, and you're blocked waiting for my
review, work on adding the code for generating and setting the sort order for
new accounts.

I don't think we can just rely on your code here to do it, as it makes
assumption about the sort orders.  (and we might be normalizing them at some point).

This code should go through all servers, find biggest sort order, and then when
done, add one.  (make sure we do the right thing for new profiles, when there
are no accounts)

And make sure we call your code from the right place so it works for accounts
created manually, from activation, etc.

Comment 49

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

taking all of varada's bugs.

Comment 50

[Fernando Cassia]

where is this going? Any recent developments? 

I'd settle for just a
perl/bash/rexx/tcl/python/insert-your-favorite-scripting-language-here script of
some sort that just reads the accounts info from the appropiate pref files,
displays the current accounts order, allows the user to change the order, and
then re-writes the prefs files.

Would that be too difficult?

Comment 51

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 52

[Chris P. Ross]

It's been months since anyone commented here, and the last request for status
update appears to have been ignored.  I would very much like to see this
feature, in either or both of the folder pane or the mail/news account settings
pref pane.

Can anyone report on the status of this, and perhaps move forward with getting
it ready for checkin?  varada?

Comment 53

[Jo Hermans]

*** Bug 209012 has been marked as a duplicate of this bug. ***

Comment 54

[Stewart Gordon]

At the moment I have the order:
- one news account
- local folders
- four more news accounts

Trying to put the order right in mail.accountmanager.accounts as per comment 22
has no effect.

Comment 55

[Joe Infla]

*** Bug 205275 has been marked as a duplicate of this bug. ***

Comment 56

[Joe Mehaffey]

Are we having fun yet?  
This new feature may indeed be far more complex than any of us "users" can
comprehend.  But in the 2.75 YEARS that all of the slick features discussed in
this epistle have been considered,  MOST of us would have settled for ANY
REASONABLE WAY to move accounts and files UP/down in the mail client.  When can
we have SOME actual solution to this problem implemented into a Mozilla release???
Thanks
Joe Mehaffey

Comment 57

[Alfonso Martinez]

*** Bug 224431 has been marked as a duplicate of this bug. ***

Comment 58

[Adler Rothschild]

There is a lot of interest in this bug. Before looking for it I put a request on
the User.win32 newsgroup and got many suggestions.  That is where I was pointed
to this bug.
Regards Adler

Comment 59

[Adler Rothschild]

There is a lot of interest in this bug. Before looking for it I put a request on
the User.win32 newsgroup and got many suggestions.  That is where I was pointed
to this bug.
Regards Adler

Comment 60

[Illtud Daniel]

Here's another vote for this. I've got 250 users on IMAP who don't use the Local
Folders, and it's just cluttering up their accounts between mail & news. Unless
we can do something about Bug 110672, then we should at the very least be able
to shunt the account down to the bottom of the list.

Comment 61

[R.K.Aa.]

*** Bug 233626 has been marked as a duplicate of this bug. ***

Comment 62

[Joe Mehaffey]

It is interesting that this item has been here for THREE YEARS with many
comments.  I think this demonstrates that it has been talked to death and no one
is considering even putting in the fixes that have ALREADY been implemented as
described herein..  

Comment 63

[Joe Mehaffey]

It is interesting that this item has been here for THREE YEARS with many
comments.  I think this demonstrates that it has been talked to death and no one
is considering even putting in the fixes that have ALREADY been implemented as
described herein..  

Comment 64

[Stewart Gordon]

Has my flag request actually woken anyone up?  Or only sent a request to nobody?
 And is that a real e-mail address in QA contact?

Comment 65

[Chris Ilias [:cilias]]

(In reply to comment #64)
> Has my flag request actually woken anyone up?  Or only sent a request to nobody?
>  And is that a real e-mail address in QA contact?

This enhancement has my vote, and I'm not a driver, but RFE's will *never* block
releases...ever.

Comment 66

[Stewart Gordon]

(In reply to comment #65)
> This enhancement has my vote, and I'm not a driver, but RFE's will *never* block
> releases...ever.

Not even the most fundamental ones?

There must be someone out there, who's ready, willing and able to check in the
fix.  I think we just need to find that someone.

There are far too many thousands of bugs out there that have a
<someone>@formerly-netscape.com.tld as assignee or QA contact.  The question is:
How many of these should really be [e-mail]?

Comment 67

[Frank Schönheit]

> > This enhancement has my vote, and I'm not a driver, but RFE's will *never*
> > block releases...ever.
> Not even the most fundamental ones?

"Fundamental" is a very subjective judgement. Every users tends to declare his
pet peeves as "fundamental" ....

> There must be someone out there, who's ready, willing and able to check in the
> fix. I think we just need to find that someone.

I did not completely check, but to me it looks as if the fix is *not* finished,
but requires some work and *significant* testing to ensure that it works in all
possible cases. I might be wrong with this, but if not, then there *is* nothing
to check in, sorry.

Comment 68

[David :Bienvenu]

I can try to drive this patch in, but I bet it's significantly bit-rotted.

Comment 69

[Asa Dotzler [:asa]]

We're not going to block the release for this feature request. If the patch can
be cleaned up and reviewed in time for 1.7 beta, great. If it doesn't happen
before the freeze, feel free to request landing approval for any fully reviewed
and tested patch.

Comment 70

[Benedikt Kantus]

*** Bug 244347 has been marked as a duplicate of this bug. ***

Comment 71

[Adler Rothschild]

PLEASE lets do something about the account sorting. PLEASEEEEEEEEEEEEEEE

Comment 72

[A. Ohlinger]

*** Bug 252485 has been marked as a duplicate of this bug. ***

Comment 73

[Scott Reed]

(In reply to comment #67)
> I did not completely check, but to me it looks as if the fix is *not* finished,
> but requires some work and *significant* testing to ensure that it works in all
> possible cases. I might be wrong with this, but if not, then there *is* nothing
> to check in, sorry.
It's almost four years since this enhancement was first requested. The frequency
of  dupes and the number of comments and the number of votes indicate this is an
important feature. However, it's still marked NEW! Is there anything we can do
besides vote to get this moving again?

Comment 74

[Stewart Gordon]

(In reply to comment #73)
> It's almost four years since this enhancement was first requested.  
> The frequency of  dupes and the number of comments and the number 
> of votes indicate this is an important feature.  However, it's 
> still marked NEW!  Is there anything we can do besides vote to get 
> this moving again?

I tried requesting a review about a month ago.  If this isn't going to wake
anyone up, what will?  Perhaps filing a new bug about the fact that these
patches are being left to rot in the fields?

Comment 75

[Stewart Gordon]

How has Hardware managed to remain wrongly set to PC all these years, anyway?

Comment 76

[Boris Folgmann]

Until this one is finally solve ...
How can it be done manually in the meanwhile?
I suppose renaming the mail.identity.id1..., mail.identity.id2... and so on
entries in prefs.js while mozilla is not running will do the trick, right?

Comment 77

[Florian Effenberger]

http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&q=order+accounts+user.
js&btnG=Suche

Comment 78

[Boris Folgmann]

Ah, tnx. So the right entry to change the order is one like this:
user_pref("mail.accountmanager.accounts", "account1,account2,account3");

Comment 79

[Boris Folgmann]

Please compare bug 150274 for a similar unsolved ordering problem. Sniff ...

Comment 80

[Kai de Leeuw]

maybe bug 203676 should be duped against this?

Comment 81

[José Jeria]

*** Bug 203676 has been marked as a duplicate of this bug. ***

Comment 82

[Jo Hermans]

*** Bug 270351 has been marked as a duplicate of this bug. ***

Comment 83

[u119584]

(In reply to comment #74)
> 
> I tried requesting a review about a month ago.  If this isn't going to wake
> anyone up, what will?  Perhaps filing a new bug about the fact that these
> patches are being left to rot in the fields?

I'd like to see this feature implemented too. Surely not too much hassle?

Comment 84

[timeless]

Comment on attachment 102994 [details] [diff] [review]
Patch V 1.2 (needs an update)

>Index: public/nsIMsgIncomingServer.idl
>@@ -141,6 +141,9 @@
>+  /* the sort Order for this account. */
>+  attribute long sortOrder;
>+
this requires bumping the iid.

>Index: src/nsMsgAccountManagerDS.cpp
>@@ -460,7 +460,6 @@
>       }
>     }
>   }
>-
why are you removing this line?
>   // handle sorting of servers
>   else if ((property == kNC_NameSort) ||
>            (property == kNC_FolderTreeNameSort)) {

Comment 85

[[e-mail]]

Comment on attachment 102994 [details] [diff] [review]
Patch V 1.2 (needs an update)

Unfortunately this is too far out of date for me to be able to evaluate it.

Comment 86

[Adler Rothschild]

I have been watching tis since it was addressed in 2000.  As far as
firefox/mozilla it seems that it could be fixed.  I have no about 14 email
addresses and I really need an easy way to change their order.
PLEEEEEEEESE
regards
Adler

Comment 87

[Miles]

Now that Mozilla is unofficially dead, except perhaps for security updates, does
that mean that this aged bug request is "offially dead," or deader than it has
been as it applies to Mozilla?

Miles

Comment 88

[Karsten Düsterloh]

> Now that Mozilla is unofficially dead, except perhaps for security updates, does
> that mean that this aged bug request is "offially dead," or deader than it has
> been as it applies to Mozilla?

This is still a valid SeaMonkey bug and may/will get fixed eventually.

Comment 89

[Stewart Gordon]

(In reply to comment #87)
> Now that Mozilla is unofficially dead,

Actually it's been rebranded under a recapitalisation of its old codename:
SeaMonkey.  The updates have moved:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

Comment 90

[Miles]

> Actually it's been rebranded under a recapitalisation of its old codename:
> SeaMonkey.  The updates have moved:
> 
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

However, with SeaMonkey you cannot ascertain what has changed with an update;
therefore I would be very hesitant about installing a SeaMonkey update.  (And
might it conflict with a Mozilla security update?)
Miles

Comment 91

[Stewart Gordon]

(In reply to comment #90)
> > Actually it's been rebranded under a recapitalisation of its old codename:
> > SeaMonkey.  The updates have moved:
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
> 
> However, with SeaMonkey you cannot ascertain what has changed with an update;
> therefore I would be very hesitant about installing a SeaMonkey update.  (And
> might it conflict with a Mozilla security update?)
> Miles

What's your evidence that they're continuing security updates specially for
people who still want their browser to be called Mozilla?  And even if they did,
I'd have thought the security updates would get into SeaMonkey at least as quickly.

Comment 92

[Miles]

There have been many posts by the pros on the newsgroup Netscape.Mozilla.
User.Windows32 mentioning that security updates will continue.  And FYI, I
continue to take down nightlies for Multizilla as the writers attempt to clean
it up in preparation for FireFox.

And again I ask how do you know what has been fixed (or broken) with a SeaMonkey
update?

Comment 93

[Chris Ilias [:cilias]]

Please read the bugzilla etiquette page
<https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.
Comments not related to fixing the bug aren't appropriate. Thanks. :-)

Release changelogs are usually within the release notes.

Comment 94

[Joe Mehaffey]

Chris,
The Mozilla Bug comments may as well revert to a general purpose comment section
since NOTHING ever gets fixed in Mozilla as a result of a bug report (as far as
I have been able to tell in watching for 5 years).

Comment 95

[Michael]

(In reply to comment #27)
[...]
> How it should look like:
> 
> +----------------------------------------------+
> | [e-mail]                                      [Default Account]
> | [e-mail]
> | [e-mail]
> | ----------------------------------------
> | Local Folders
> | ----------------------------------------
> | newsgroup1
> | newsgroup1
> | newsgroup1
> |
> +----------------------------------------------+
> |   [ Move up ]  [ Move Down ]
> | 
> |   [ New Account    ]
> |   [ Set as Default ]
> |   [ Remove Account ]
> +----------------------------------------------+
> 
> 1. The buttons should be grayed out if "Local Folders" is selected (unmovable).
[...]

Just another vote for this style...but the reason I care is slightly different.
Please make the order in which the accounts are displayed match the order which
they are retrieved so that I can retrieve accounts in the order I prefer.  Some
accounts have preference over others for me, and I don't want to wait for a
bunch of spam to download before my personal account has it's turn.  (see:
http://forums.mozillazine.org/viewtopic.php?t=323579 for another reason.)

I'm also taking the liberty of reassigning this bug to the owner and QA contact
of the Account Manager, as it seems that we may have gotten a little distracted
(and I'm new here, so can get away with being ignorant about the politics
involved...)[insufficient rights...so I'll email
[e-mail] instead] 

Comment 96

[Michael]

Here are some very related bugs...perhaps the people involved could consolidate
on this?

Bugzilla Bug 61078 - Ability to Change Order of Accounts
Bugzilla Bug 97186 - Method of having alphabetical sort for newsgroups in the
folder pane.
Bugzilla Bug 150274 - User should be able to reorder the Newsgroups like in NS4

Comment 97

[Riccardo Cretti]

Bug 150274 - User should be able to reorder the Newsgroups like in NS4
it's different from this bug.
When (if) bug 150274 will be fixed, users will be able to reorder newsgroups
with drag&drop (as it was in Netscape 4) and not with the account settings.
It could be good to be able to do it both ways though...

Comment 98

[Jerry Baker]

This bug is not about being able to reorder newsgroups. This bug is about being
able to reorder the accounts. Newsgroups are under an account. Go ahead and try
to put the newsgroup account you created yesterday in front of the one you
created last year. Then, place one of your email accounts below your newsgroup
accounts. When you can do these things this bug is fixed.

Comment 99

[Riccardo Cretti]

(In reply to comment #98)
> This bug is not about being able to reorder newsgroups. This bug is about being
> able to reorder the accounts. Newsgroups are under an account. Go ahead and try
> to put the newsgroup account you created yesterday in front of the one you
> created last year. Then, place one of your email accounts below your newsgroup
> accounts. When you can do these things this bug is fixed.

Did you bother to read what I wrote?
I wrote that bug Bug 150274 - "User should be able to reorder the Newsgroups
like in NS4" has nothing to do with this bug, in response to the message of
Michael that said that it's related.

Comment 100

[Michael]

(In reply to comment #97)
> Bug 150274 - User should be able to reorder the Newsgroups like in NS4
> it's different from this bug.
> When (if) bug 150274 will be fixed, users will be able to reorder newsgroups
> with drag&drop (as it was in Netscape 4) and not with the account settings.
> It could be good to be able to do it both ways though...

I agree with your last statement.  But I believe that these three bugs may be
closely related enough that something that works for one situation will work for
the other.  I'm not suggesting marking two of these three bugs as duplicates and
working on only one solution...I am just encouraging the idea of taking a step
back and looking at these seemingly separate bugs in the same light.

If I understand this correctly, both solutions would be resolved by a module
that re-orders account names in either the [news server].rc file or the prefs.js
files per the user's choice:

From comment #77 in this bug:  “Then you can edit or add the lines in your
user.js (or create a user.js with just these lines) that look as follows to
order the accounts:

user_pref("mail.accountmanager.accounts", "account2,account1,account5,...");
user_pref("mail.accountmanager.defaultaccount", "account1"); “


From comment #5 in Bugzilla Bug 97186:  “To change the order, simply rearrange
the lines of newsgroup names with associated numbers.”


Upon further examination, it appears that there are some syntax differences. 
Specifically that mail accounts are displayed on one line (above), while
newsgroup accounts are listed on separate lines:
  netscape.public.mozilla.announce: 1-257,260,262,263,270,271,274-281
  netscape.public.mozilla.general: 1-59459,59461-60946,60948,60950-62865
  netscape.public.mozilla.layout: 1-10818,10820,10821,10823-10859,10863

I am speaking as a layman here, but if I were writing code to re-order one of
these files, I would just duplicate parts of the same code to reorder the other
file as it seems (to me at least) to be a very similar process.

Comment 101

[Joe Mehaffey]

How do I REMOVE my email address from ALL Mozilla bugzilla sessions?  And
especially THIS one.  I removed my <[e-mail]> email address weeks ago and
I still get advisories from this bug session.
Thanks.

Comment 102

[David :Bienvenu]

changing component to account manager. 

Comment 103

[Karsten Düsterloh]

*** Bug 324077 has been marked as a duplicate of this bug. ***

Comment 104

[Rafael Cordones Marcos]

Check Folderpane Tools:
http://addons.mozilla.org/thunderbird/258/

Comment 105

[Adler Rothschild]

Unbelievable!!!! the extension seems to work well. this bug was first reported 11/28/2000!!!! it is now June 0f 2006!!!! Thank you. it is listed in thunderbird extensions as well as the home page at http://www.chuonthis.com/extensions/folderpane.php.
Regards
Adler

Comment 106

[Peter C. Frank]

I seem to recall being able to drag'n'drop account names in the folder pane view to rearrange them when I upgraded to Thunderbird v1.5; however, now that I'm using v1.5.0.5 and I've added another email account, I can't seem to do this. Am I just mis-remembering being able to drag'n'drop to rearrange or was the feature put in but then taken back out again for some reason?

Comment 107

[Karsten Düsterloh]

> Am I just mis-remembering being able to drag'n'drop to rearrange

Yes.

Comment 108

[Arkady Belousov]

(In reply to comment #18)
> Example Screen shot of Move Up/Move Down buttons

     Not necessary to make extra row, you may squezze Delete button and place Up and Down arrows at its sides.

Comment 109

[Moobi]

While the Folderpane extension mentioned above works, having the buttons right there in the Account Settings pane, as well as not having to restart TB for changes to take effect, would be ideal. I hope this is still being worked on.

Comment 110

[Bug Filler]

Yes, whoever took this bug, please finish your work. Rearrange account order is often used now a day. Most people have multiple accounts now.

Comment 111

[Mike]

I've rearranged my accounts before by editing the mail.account lines in the prefs.js file, but it would be nice if it was made easier to do. 

Comment 112

[girardaquino]

wow... this bug has been here for 8 years now? maybe developers can post about the current state of the project and/or/so others can also help around with the code or something. the hack works, but it still isn't a fix eh?

Comment 113

[Karsten Düsterloh]

Comment on attachment 102995 [details] [diff] [review]
added new default sortOrder pref in mailnews.js

That's useless for several reasons: 
- [e-mail] is no real person
- adding a pref without any code checking it makes no sense (attachment #102994 [details] [diff] [review] needs to be updated, and this attachment here should be part of the new patch)

Comment 114

[Stewart Gordon]

Why isn't it a fix?

Moreover, why has this component been without a QA contact for years?

And are _any_ of the people who have actually worked on this still here?  And does anybody have any idea who is at the moment in a position to review patches for these issues, let alone fold them in?

What other bugs are there that are in this sorry (to put it mildly) state?  I know about bug 43278 - can anybody think of others?

Comment 115

[Adler Rothschild]

this bug is fixed by the Thunderbird addin https://addons.mozilla.org/en-US/thunderbird/addon/258.It will not change the first address but the other email addresses can be moved up and down. works with Thunderbird 2.0.0.0.14. I have been using it quite awhile. It would be nice if it was a menu item. but after installing it will be in the  tools addin  window.
Regards
Adler

Comment 116

[Adler Rothschild]

correction for above comment. URL should be: https://addons.mozilla.org/en-US/thunderbird/addon/258  

Comment 117

[David :Bienvenu]

I think this would be pretty nice to have. And drag drop ordering like we have for newsgroups would be one nice way of doing this, w/o adding a lot of UI.

Comment 118

[John David Galt]

We don't have drag-and-drop ordering for newsgroups (that's bug 150274).

Comment 119

[David :Bienvenu]

not in 2.0, but 3.0 a1 has it.

Comment 121

[Micah Gersten]

Doesn't this bug belong in MailNews Core?

Comment 122

[Philip Chee]

> Doesn't this bug belong in MailNews Core?
No. The implementation is in the front end. We still use a rdf driven account tree while Thunderbird has totally rewritten their code to use a js driven tree view.

Comment 123

[bonbon]

10 years passed, we still have to use the addon to do it. :(

Comment 124

[posita]

Should this be moved to Thunderbird? (It's applicable there.)

Comment 125

[posita]

Oops...sorry...disregard. Bug 244347 is the corresponding bug for Thunderbird.

Comment 126

[Christian]

I'd like to strongly second the selectability of ALL the accounts' order, without any predisposition by Seamonkey (as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=43484#c7).
As always - put the user in control (with choice structures easy to grasp like "Move up/down") and the product will be a very likable one.

For example, my personally preferred order is 
1) changing/dynamic accounts first (IMAP/POP/Blogs+News)
2) static ones (Local Folders)
Why? In Mail and Blogs+News, there are changes happening I don't do myself and I thus want to "see" immediately, whereas in "Local Folders" just are my own changes (including those done by my rules).
With the new preset order of Blogs+News always coming last, a largely expanded "Local Folders" account pushes Blogs+News out of sight, so I optically miss new items there.

Thanks for all the good work!!