After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 221381 - server-side filtering tracking bug
server-side filtering tracking bug
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
3.4.x (obsolete)
Other All
: Normal enhancement
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[connector] evolution[filters]
Depends on:
Blocks: 216959 221380 713015
 
 
Reported: 2002-03-05 16:32 UTC by Dan Winship
Modified: 2021-05-19 11:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2002-03-05 16:32:41 UTC
There's probably some minor generic gui/api work involved in supporting
server-side filters
Comment 1 Dan Winship 2003-06-23 17:37:32 UTC
While I'm mostly concerned with Exchange server-side rules here,
this bug is actually the generic server-side rules tracking bug
that covers both Exchange and Sieve (storing filter rules on your
IMAP server, assuming your IMAP server is Cyrus). So I'm phrasing
the issues generically, though we're allowed to ignore the big
picture if we really want...

  1) How should server-side rules be presented to the user?
     Should they appear in the existing Filters dialog box, or
     should they get their own separate Tools menu item? Or
     somewhere else altogether?

     1a) If they are in the Filters dialog, how exactly are they
         distinguished from client-side rules?

     1b) Do we want to start explicitly referring to evolution
         filters as "client-side"?

     1c) [Extra credit] What if the user has two Exchange accounts,
         or both an Exchange account and a Sieve account?

     If we don't put them in the Filters dialog, then it becomes
     annoying to set up both client-side and server-side rules
     (which people may want to do if they need some functionality
     that Exchange rules can't support, or if they want to do
     something inherently client-side like playing a sound when
     they get mail from a certain person). This may be a non-
     issue.

     Outlook puts client and server rules together in the same
     list, and appends "(client only)" or something like that
     to the client-side ones. This is nice because you can see
     all of your rules at once, but they make it annoying in
     that the rule-creation dialogs don't tell you which options
     are client-side and which are server-side, so you don't
     even know what your rule is going to be until you get to
     the end and save it.

     A better possibility might be to add another option to the
     "incoming/outgoing" pop-up menu. This could also solve the
     (1c) issue, by having "Exchange Filters on shrewdness",
     "Exchange Filters on mr-nutty.exchange.ximian.com",
     "Sieve Filters on skepto.ximian.com", etc. (We'd need to
     renaming "incoming" and "outgoing" to fit the theme.)

     OTOH, another nice aspect of Outlook's way is that you don't
     have to think to yourself "is it possible to implement this
     rule on the server?" before you start to create the rule,
     whereas with separate lists, you might start to create the
     rule and then realize that there was no option for one of
     the rule pieces you needed.

  2) How does the right click -> Create Rule from Message stuff
     change? Do you get separate "create server-side rule" and
     "create client-side rule" options?

  3) Not directly related to this, but Christine wants us to add
     the ability to disable individual rules as well, so that
     should go into the UI blender as well.
Comment 2 Not Zed 2003-06-25 09:36:41 UTC
1) We could probably have 2 settings?  In either case it may make
sense to move the filter rules/management to the provider/store
instead of the session.  Perhaps?  Dunno how you share rulesets in
that case, or even if people want to.

We can't just have a generic 'server side' option using the current
system, since different servers could have different server-side
possibilities, or none at all.

2) This should probably just have 'create rule from message ...' and
pop up a set of options before going forward.  i.e. it would fit into
a wizard thing probably the best.

The wizard would present options based on the features of the backend,
if the rules are backend specific.

3) Disabling rules is obviously easy.
Comment 3 Dan Winship 2003-06-25 14:02:19 UTC
A "create rule from message" wizard sounds like a good plan.

Related to that, we'll need a way to figure out what header and
value was used to generate x-camel-mlist, so that it can be
translated appropriately for server-side rules. (Exchange lets you
include comments in rules, so we could create a rule that would be
presented in the filter editor as "Mailing list is
'evolution@ximian.com'", but where the server was actually
executing "Full message headers contain 'X-BeenThere:
evolution@ximian.com'".)
Comment 4 Dan Winship 2003-06-25 19:22:50 UTC
Oh, there are also advanced out-of-office rules. (Eg, so you can
have one OOF message for coworkers and another for people outside
the company). These probably want to be reached from the OOF
dialog, not the filters dialog. (qv Outlook, although they
confusingly use a completely different UI for defining OOF rules
than for normal rules).

And finally, there's the rule that gets created if you delegate
your meeting requests to someone else. In Outlook, this rule is
hidden and you can only change it by changing options in the
delegates dialog. We may or may not want to do the same.
Comment 5 Gerardo Marin 2003-11-28 19:51:34 UTC
Futuring for now unless this is doable in 2.0 (and if that's the case,
please set milestone for 1.5.1)
Comment 6 Calum Benson 2005-07-28 10:40:26 UTC
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
Comment 7 André Klapper 2021-05-19 11:46:20 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/evolution/-/issues/

Thank you for your understanding and your help.