41715 - Filter/Search UI: launch to account selected in folder pane.

Status: VERIFIED FIXED

(MailNews Core :: Filters, enhancement, P2)

Description

[laurel]

Using jun05 commericial build

When launching the message filters ui from a profile with multiple accounts, the
dialog should launch to the account which is selected in the folder pane. 

Some rules as I see it:
1.  If nothing selected in folder pane, should launch to default mail account.
2.  If news/nntp account selected in folder pane, should launch to default mail
account seeing as how we're not doing news filtering in this release.
3.  If Local Folders is selected, should launch to default mail account.
4.  If valid (filter-able) mail account is selected, should launch to that
selected account.
5.  If a mail account which doesn't support filtering should launch to default
mail account.
6.  All of the above should work regardless of what level is selected in a given
account hierarchy; rules should apply if account level (expanded or collapsed),
special folder, top level user folder, or sub-level folder is selected.

Comment 1

[Alec Flett]

would be nice

Comment 2

[selmer (gone)]

Changing to enhancement, please consider moving to FUTURE milestone.

Comment 3

[Alec Flett]

reassigning my filter bugs to gayatrib..

Comment 4

[laurel]

Nominating for 6.5
This should apply to search ui, too... not sure we have a bug on search ui.

Comment 5

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 6

[scottputterman]

moving to mozilla0.9

Comment 7

[gayatrib]

Fix in hand. Posting patch.

Comment 8

[gayatrib]

Attachment: patch

Comment 9

[gayatrib]

seth and bienvenu--could you please do a review for me?

Comment 10

[gayatrib]

adding patch and review keywords

Comment 11

[David :Bienvenu]

looks good to me, so if it's OK with Seth, sr=bienvenu

Comment 12

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

I have some comments and questions for gayatrib, I'll be meeting with her today.

hold off on checking this in.

Comment 13

[gayatrib]

Posting a new patch with the following changes:
1) Introduced canHaveFilters variable into nsIMsgIncomingServer.idl
2) Intialized canHaveFilters to false in base class, and true in imap and pop.
3) Commented out dump statements in throw/catch block.
4) Added code to do the following:
    1) get the selected server if it can have filters.
    2) if the selected server cannot have filters, get the default server
       if the default server cannot have filters, check all accounts
       and get a server that can have filters.
    3) if no server in any account can have filters, throw an alert.
       close the filter dialog

Comment 14

[gayatrib]

Attachment: patch

Comment 15

[gayatrib]

Seth could you do review/super review for me? Thank you.

Comment 16

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

I'm not sure about:

3) if no server in any account can have filters, throw an alert.  close the
filter dialog

how much work would it be to do this:

change MsgFilters() to ensure initialServerUri
 is correct before opening the filter dialog.  if it can't come up with a valid
server (there are no servers that can have filters), throw up the alert instead
of opening and closing the filter dialog.

all the code is there, it just needs to be moved around.

cc'ing jglick for comments.

Comment 17

[Matthew T (active 1999-2002)]

> if it can't come up with a valid server (there are no servers that can have
> filters), throw up the alert instead of opening and closing the filter dialog.

Even Better would be, if there are no servers which can have filters applied to 
them, don't have the filters menu item enabled in the first place. Letting the 
user select the menu item, and then throwing up an alert saying `No you can't!', 
is a bit denigrating.

Comment 18

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

mpt idea is better.

to implement it, make the assumption that if the filter dialog comes up, you
will have at least one server that can have filters.  You can keep most of your
code the way it is, but remove the alert stuff and the close dialog stuff.

now, we've got to enable / disable "edit filters" conditionally, based on if you
have at least one server that can have filters.  

We may have to extend the account manager to keep track of that, because
iterating through all servers during each call to IsCommandEnabled will be too
expensive.

Let me know if you have questions or want to discuss the implementation.


It looks like accountCentral.xul always shows "Create Filters", this should be
conditional.  I'll go log a bug on bhuvan for that.

Comment 19

[scottputterman]

Can we just check this in and file a new bug? It seems to me that the case 
where people don't have an account that can have filters is pretty rare. They'd 
have to be using us as only a newsreader (possible, but after the first time 
they'll get it that they can't do filters) or for imported mail accounts that 
can't receive mail. The second case seems really rare to me and the first case 
doesn't seem worth holding up this bug.

Comment 20

[jglick]

>if there are no servers which can have filters applied to 
>them, don't have the filters menu item enabled in the first place. 

I agree with mpt's suggestion.

Comment 21

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

it should not take too long to finish this bug up right.

But, if we are going to check in with known bugs, let's at least not check in
the alert code and close dialog code.

The rest of the code in gayatribs patch is fine as is.

all that would be left would be the enable / disable code to the UI and the
account manager part (to efficiently know if we have any servers that can have
filters), and that could be another bug.

Comment 22

[gayatrib]

Attaching a new patch--which would just bring up an empty filter dialog when no 
server in any account supports filters.

Filing a separate bug to handle that case.

Attaching the new patch.

Comment 23

[gayatrib]

Attachment: new patch.

Comment 24

[gayatrib]

Seth--could you review/super review the new patch for me?
Filed bug 67219 for handling no filters in any account case.

Comment 25

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

looks good.  sr=sspitzer

Comment 26

[gayatrib]

I missed marking this fixed. Fix has already been checked in. 

Comment 27

[laurel]

Generally working except for bug 67219.
Any other specific issues will be logged separately.
OK using feb26 commercial trunk builds: linuxrh6.0, win98, mac OS 9.0