551644 - TB3 fails to show the name of the folder when it warns that renaming it modifies related filter(s).

Status: REOPENED

(MailNews Core :: Filters, defect)

Description

[ISHIKAWA, Chiaki]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

Suppose you have a hierarchical folder structure like below:

 A -+- B0 - C0
    |  
    +- B1 -+- C1
           |
           +-- C2

And suppose each of A, B0, B1, C0, C1, and C2 have filters associated with them.

Now suppose A is renamed to AAA.

TB3 then issues confirmation dialog for each of A's subfolders that
a folder is renamed and its associated filter is changed.
Unfortunately, TB3 doesn't display the name of the folder (it should)
and so the user is at a loss to figure out WHICH folder TB3 is talking about,
and this confirmation dialog is useful at all.

Yes, TB3 probably should NOT warn about the sub-level folders as long as
the user knows what she/he is doing and no typing mistake is made,
or pointing device movement is always accurate.
(But since sometimes I pick up the wrong folder by mistake, 
a CLEAR DISPLAY of the FOLDER name in the confirmation dialog is preferred.)


Reproducible: Always

Steps to Reproduce:
1. Choose a folder with associated filter(s) and try renaming it.
2. A dialog appears that warns that filter(s) are changed, too.
3.
Actual Results:  
The dialog doesn't mention WHICH folder is being renamed.

Expected Results:  
The dialog SHOULD DISPLAY the name of the folder being changed.
(Especially if TB3 tries to warn about the sub-folders one by one.)

As I mention above,
the folder name SHOULD be displayed.

And probably we can have a switch (user preference) to
suppress the warning for sub-level folders when a top-level
folder is renamed and the filter associated with a sub-folder is
modified IMHO.

Comment 1

[ISHIKAWA, Chiaki]

I hasten to add that the warning dialog does have a check box
to suppress the further warning, but in my case above

A -+- B0 - C0
    |  
    +- B1 -+- C1
           |
           +-- C2

and I want to rename A to AAA, I don't mind receiving a warning for
"A" -> "AAA" (or XXX/AAA as in moving it under a different directory) causing the filter modification for those filters associated with top-level "A".
 
But I don't want to see the filter modification warnings for "B0", "B1", 
"C0", "C1", and "C2".

The sub-level move is after all implicit (they must follow where "A" goes)  and I think if the top-level folder is chosen at one's will and CORRECTLY, the user should not be bothered for sub-level changes. (And I am not sure if TB2 warns of these implict filter modifications, if they are called as such, associated with sub-level folders in a hierarchy when its top-level folder name is changed.)

When the folder names are not displayed, we have no idea to which folder TB3 refers  anyway and thus very confusing as in the original post.

TIA

Comment 2

[Ludovic Hirlimann [:Usul]]

James do you think you could drive that in for 3.1 ?

Comment 3

[Kent James (:rkent)]

Ludovic: I'm curious why you would pick this particular bug to ask about, a new unconfirmed bug, when there are several more important bugs (IMHO of course) that I have been ignoring.

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to comment #3)
> Ludovic: I'm curious why you would pick this particular bug to ask about, a new
> unconfirmed bug, when there are several more important bugs (IMHO of course)
> that I have been ignoring.

So as you have guessed I'm trying to help you drive, this is my first try, I'll probably learn as much as you will:

i)   It came my way in a unco-new bug - I wasn't looking for driving things.
ii)  It's unconfirmed because I didn't look for duplicates.
iii) It seems to me that it could bring value to the user.
iv)  From my I don't know the code - this seems like a easy fix.
v)   Knowing that you are working on something else and that 3.1 is coming soon, I though This one would make a candidate for trying given the constraints.

I consider you being the owner of Filters, so I'd be very interested in your list of bugs that you find more important - would you mind sharing it ?

Comment 5

[Kent James (:rkent)]

Ludovic (with apologies to the reporter for our slightly off-topic conversation):

You can look at my list of Assigned bugs to get a little better feeling of issues I think are most important. Bug 537012 is probably my highest priority easy fix based on extensive GS issues.

As to the difficulty of this bug, while the code change to fix the issue may be easy, there are two complications. First, it is a front end bug. My experience has been that front-end bugs generate significantly more controversy and difficulty in review than back-end bugs. Second, testing requirements generate a non-trivial amount of work regardless of the ease of the fix. (I noticed Bienvenu recently give an estimate of 10x the work to do the test as fix the bug.) An impartial observer would doubtless claim this is the tail wagging the dog, but it is the reality of the current process that I can only comply with (and occasionally complain about).

Comment 6

[:aceman]

When do you get that alert? I can't see it. When renaming a folder there is no warning for me (in TB10).

Comment 7

[ISHIKAWA, Chiaki]

(In reply to aceman from comment #6)
> When do you get that alert? I can't see it. When renaming a folder there is
> no warning for me (in TB10).

Hmm. I have test a version 7.0.1 on Windows, and you are right!
There is no warning at all now when 
 - the folder is renamed, or
 - the folder is moved into a different folder 
These were when I used to receive the warnings.
Maybe I should check the linux version tomorrow.

Comment 8

[Wayne Mery (:wsmwk)]

suggest this bug is essentially wontfix, because we shouldn't be warning in the first place.  note bug 41720 comment 55, et al, suggests we shouldn't warn.  HOWEVER, perhaps there is warning code that can be removed?

I'm sure all the OS are the same.

Comment 9

[ISHIKAWA, Chiaki]

(In reply to Wayne Mery (:wsmwk) from comment #8)
> 
> I'm sure all the OS are the same.

Right, I checked the linux operation and it didn't warn when I
moved the dirctories around.

Comment 10

[ISHIKAWA, Chiaki]

(In reply to ISHIKAWA, Chiaki from comment #9)
> (In reply to Wayne Mery (:wsmwk) from comment #8)
> > 
> > I'm sure all the OS are the same.
> 
> Right, I checked the linux operation and it didn't warn when I
> moved the dirctories around.

For the last few years, I was not bothered with the original problem any more since TB
no longer warns of the renaming of folder which is referenced by a filter rule.

So I am closing this as WONTFIX.

TIA

Comment 11

[:aceman]

The code for the warning is still there at nsMsgDBFolder::AlertFilterChanged
and is called from many places. The showing of the warning should somehow depend on the value of the pref mail.warn_filter_changed, but neither setting it to true or false didn't show the warning. I can look at that. Somehow the pref has no default today (maybe it was removed and that is why the warning no longer shows). It can stay as a hidden pref, but should actually work.
Then I can also look at refining the warning.

Comment 12

[ISHIKAWA, Chiaki]

(In reply to :aceman from comment #11)
> The code for the warning is still there at nsMsgDBFolder::AlertFilterChanged
> and is called from many places. The showing of the warning should somehow
> depend on the value of the pref mail.warn_filter_changed, but neither
> setting it to true or false didn't show the warning. I can look at that.
> Somehow the pref has no default today (maybe it was removed and that is why
> the warning no longer shows). It can stay as a hidden pref, but should
> actually work.
> Then I can also look at refining the warning.

Thank you, aceman. I should have known!

TIA

Comment 13

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.