Closed Bug 1090553 Opened 5 years ago Closed 4 years ago

create filter from doesn't create filter while in Unified Inbox, and no error message

Categories

(Thunderbird :: Filters, defect)

31 Branch
defect
Not set

Tracking

(thunderbird39 wontfix, thunderbird40 fixed, thunderbird41 fixed, thunderbird_esr3839+ fixed)

RESOLVED FIXED
Thunderbird 41.0
Tracking Status
thunderbird39 --- wontfix
thunderbird40 --- fixed
thunderbird41 --- fixed
thunderbird_esr38 39+ fixed

People

(Reporter: tylerguthrie7, Assigned: aceman)

Details

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko

Steps to reproduce:

While Inbox is selected in Unified view (accounts underneath not expanded), I have a message in view (it is in an IMAP account, I haven't tested one of my POP accounts in Unified view as I don't use them as much) (Vertical View with Folder Pane and Message Pane both Enabled), I click on an/the email address in the From field in the Message Pane (I think.. the window on the right side that you can see the email contents inside of), and choose Create Filter From, which brings up the "Filter Rules" window, with the following Fields:

Filter name: AAA Example Filter
Apply Filter When:
X Manually Run
X Getting New Mail: Filter before Junk Classification
X Match all of the Following
Rule1: From IS bugzilla-daemon@mozilla.org (for example)

Perform These actions:
Action1: Move Message to: Some Local Folder
Action2: Stop Filter Execution

I choose OK


Actual results:

Takes me to the Message Filters window for the first account in my list of accounts (not the account that the message arrived into), listing all the filters for that account, it doesn't show my new filter, and I cannot find my new filter anywhere under any of the accounts or the Local Folders filters.


Expected results:

It should take me to Message Filters window for the account that the message arrived into, listing all the filters for that account.  And it should show the new filter.
Some possibly related bugs/issues in the past that I read through..

https://bugzilla.mozilla.org/show_bug.cgi?id=537012
https://bugzilla.mozilla.org/show_bug.cgi?id=242665
http://forums.mozillazine.org/viewtopic.php?f=39&t=2796221

Other things of note:
- IMAP may be the issue?
- Unified View may be the issue?
- Unidentified bug of process that should be working?

I can test a pop account's inbox as well if it helps to see if there's any difference and maybe narrow it down to a Unified view issue?
I can not reproduce the problem. For me the Filters window opens on with the proper account and the new filter is in the list.
So yes, please try to play with it and find what is the necessary setup to see the bug. What type of folder do you try it on? Is it the Inbox of the IMAP account or some other folder? Subfolder of Inbox or not?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Thunderbird/40.0a1

I have the same problem as the reporter. The account that the message arrived into was a POP account.

UNIFIED VIEW IS SELECTED. 

Once the filter is created the behavior is exactly as reporter describes i.e.
1. Takes me to Message Filters window for the first account in my list of accounts
2. The filter is NOWHERE to be found (in any account)

Question: Is there a way to see ALL filters created together?
OK, I can see it now. I must be on the top level Inbox, that summarizes messages from all accounts.
The filter is created without any error, but is nowhere to be found.

So what is the proposal? Should it be created in the account where the source message is located?
Assignee: nobody → acelists
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
(In reply to :aceman from comment #4)
> OK, I can see it now. I must be on the top level Inbox, that summarizes
> messages from all accounts.
> The filter is created without any error, but is nowhere to be found.
> 
> So what is the proposal? Should it be created in the account where the
> source message is located?

In my mind it would be ideal if ONE filter was created for ALL accounts (since the same rule would apply more or less to all and any accounts e.g. IF message is received FROM XXXX then MOVE in YYYY folder).

If that is too hard to accomplish the second best would be as you suggest: The filter should be created in the account where the source message is located. (That was my immediate impulse anyway: Look in the account where the message was received).
Attached patch patch (obsolete) — Splinter Review
So let us send also the folder of the message. Otherwise we were sending the currently selected folder, which could be the "smart mailboxes" account for unified folders. That one can't be seen in the filters list UI and probably filters in it do not run ever.
Attachment #8600269 - Flags: review?(rkent)
Attachment #8600269 - Flags: review?(mkmelin+mozilla)
(In reply to CAK from comment #5)
> In my mind it would be ideal if ONE filter was created for ALL accounts
> (since the same rule would apply more or less to all and any accounts e.g.
> IF message is received FROM XXXX then MOVE in YYYY folder).
We have other bugs filed for having global filters. It is currently not possible.

> If that is too hard to accomplish the second best would be as you suggest:
> The filter should be created in the account where the source message is
> located. (That was my immediate impulse anyway: Look in the account where
> the message was received).
Yes, I implement this version in this quick patch.
Status: NEW → ASSIGNED
Comment on attachment 8600269 [details] [diff] [review]
patch

Review of attachment 8600269 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/msgHdrViewOverlay.js
@@ +1656,5 @@
>   */
>  function GetNewsgroupServer()
>  {
>    if (gFolderDisplay.selectedMessageIsNews) {
> +    let server = getFolderOfCurrentMessage().server;

folder can be null
Attachment #8600269 - Flags: review?(mkmelin+mozilla) → review-
(In reply to Magnus Melin from comment #8)
> folder can be null

I guessed it couldn't because of the if (gFolderDisplay.selectedMessageIsNews), and my patch doesn't make it any worse, but I can surely add the guard.
Attached patch patch v1.1 (obsolete) — Splinter Review
Attachment #8600269 - Attachment is obsolete: true
Attachment #8600269 - Flags: review?(rkent)
Attachment #8603867 - Flags: review?(rkent)
Attachment #8603867 - Flags: review?(mkmelin+mozilla)
(In reply to :aceman from comment #9)
> (In reply to Magnus Melin from comment #8)
> > folder can be null
> 
> I guessed it couldn't because of the if
> (gFolderDisplay.selectedMessageIsNews), and my patch doesn't make it any
> worse, but I can surely add the guard.

Ah, I misread that context. Let's not add more guards than needed.
Comment on attachment 8603867 [details] [diff] [review]
patch v1.1

Review of attachment 8603867 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/msgHdrViewOverlay.js
@@ +1608,5 @@
>  /**
> + * If there is a currently selected message, return its folder.
> + * Otherwise null.
> + */
> +function getFolderOfCurrentMessage() {

... but in short I don't see the use for this function. It's short enough to write gFolderDisplay.selectedMessage.folder + other guards that you usually have anyway

And also, MsgFilters tries to do the auto selection in a very similar way if you pass in null (like we currently do). So, I guess that is the place that should be fixed instead?
Attachment #8603867 - Flags: review?(rkent)
Attachment #8603867 - Flags: review?(mkmelin+mozilla)
Attached patch patch v2Splinter Review
Yes, it seems MsgFilters does the same analysis, we just didn't len it do it and passed the wrong folder.
Attachment #8603867 - Attachment is obsolete: true
Attachment #8608324 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8608324 [details] [diff] [review]
patch v2

Review of attachment 8608324 [details] [diff] [review]:
-----------------------------------------------------------------

Great! r=mkmelin
Attachment #8608324 - Flags: review?(mkmelin+mozilla) → review+
Thanks.
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/e7bf02ea3e61 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 41.0
Comment on attachment 8608324 [details] [diff] [review]
patch v2

Seems low risk.
Attachment #8608324 - Flags: approval-comm-esr38+
Attachment #8608324 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.