[Tickets #2617] Filtering on "Sender" does not use "From"

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2617
-----------------------------------------------------------------------
 Ticket             | 2617
 Updated By         | Michael Slusarz <slusarz at mail.curecanti.org>
 Summary            | Filtering on "Sender" does not use "From"
 Queue              | Ingo
 Version            | HEAD
-State              | Rejected
+State              | Feedback
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | 
-----------------------------------------------------------------------


Michael Slusarz <slusarz at mail.curecanti.org> (2005-10-25 09:49) wrote:

> So as a first measure I would propose putting From at the top of the 
> list.  As a second measure I would propose adding clarifying text 
> after the field name:
>
>    From     (message author)
>    Sender (not message author)
>    To
>    Subject

As for the order, this can be changed via the config/fields.php file. 
Additionally, the text displayed to the user can be altered via the 'label'
parameter located in the same file.  Suggestions on improving the
labels/order in the default fields.php.dist file are welcome.

> Also, since the RFC recommends against specifying a Sender when it is 
> the same as the From, how about filtering on From when Sender is 
> absent instead of just failing without a heplful indication of why.

This is not possible with the current ingo setup.  As mentioned previously,
the current behavior (and the way the UI is setup) is that the user selects
either a header, body, or size of the message to filter on.  There is
currently no method of indicating a conditional search pattern (i.e. "if
Sender is not available, filter on From").  

That being said, this could be added by defining a new INGO_STORAGE_TYPE_*
entry.  But this will require some coding (patch would be great).

> Furthermore, the list of fields is hardly exhaustive (what if I want 
> to filter on Reply-To?), so how about having a checkbox to enable 
> infrequently-used fields like Sender and Reply-To, and when the box 
> is unchecked, just show the "normal" filtering fields, From, To, 
> Subject, Body, X-Spam*.

If you want to filter on other headers, you can either add the header to the
list in config/fields.php or the user can add it themselves via the
'self-defined header' option.

> In any case, this IS a bug in the sense that the program didn't do 
> what I expected.  Just because it's behaving "correctly" doesn't mean 
> it's behaving "well".  Hiding behind standards in the face of user 
> confusion strikes me as bordering on what Steven Covey refered to as 
> "Malicious Obedience".

This still isn't a "bug".  Bug means the software is behaving incorrectly
given the proper input.  In your case, the software is behaving incorrectly
because you are giving it incorrect input because you don't understand what
the input should be.  Thus, the UI or documentation needs to be improved. 
As stated above, it is not even possible to do some of what you want the
program to do which, by definition, is an "enhancement" not a bug - if the
code doesn't even exist, it can't be buggy.

I will reopen this ticket for feedback and possible patches.