70340 - Filter UI: Foldersmenu should not show unsupported folders as choices

Status: VERIFIED WORKSFORME

(MailNews Core :: Filters, defect)

Description

[laurel]

Using feb26 commercial trunk build

When using the New Folder button in the Filter UI to create a folder which gets
a create error, that new/non-existent folder name is left in the filter action
value selection dropdown.  This seems a little confusing to me, although we do
error if user tries to OK the dialog with the incorrect folder name.

1.  From the mail window, Edit|Fitlers. Click New button, blank filter rules
dialog opens.
2.  Create a simple filter, choose Action=MoveToFolder (default action) and
click New Folder.  Add a folder which will cause a create error, such as
choosing a parent folder which doesn't allow sub-folders. 
    Note:  in some cases folders which can't have subfolders are already greyed
out in the folder hierarchy for the parent folder selection and aren't selectable.
3.  After attempting to create the disallowed folder, the filter UI action 
value selector reflects the new folder name.
4.  An alert appears telling you the folder couldn't be created. OK the alert
and note that the filter ui still carries the new/disallowed folder name.
    Note:  upon OK to the filter rules dialog user will get an error telling
them to select a target folder, just as they would if they hadn't attempted the
new folder thing.  Having the errored folder name there just adds to the confusion.

Comment 1

[Håkan Waara]

The real bug here is that the unsupported folders/servers shouldn't be shown in
the folderspopupmenu.

Backend, so reassign to naving. (Who owns this popupmenu-with-folders-widget
anyways?)

Comment 2

[laurel]

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

Comment 3

[Håkan Waara]

I can't reproduce this any longer since folders that doesn't support sub-folders
are greyed out in the menu.

Are there any other triggers?

Comment 4

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

racham may have fixed this recently.

Comment 5

[Håkan Waara]

If there are no other triggers to this bug other than the one suggested in the
summary, this bug is fixed.

In the AOL case (the dup.), that is a problem with the AOL code...

Comment 6

[laurel]

I'll mark it worksforme based on both of your last comments, and I'll verify
when I get to the trunk. You can always reopen if you find something in the
meantime.

Comment 7

[laurel]

Maarking verified worksforme. OK with aug27 commercial trunk builds.