| Summary: | Wish: Notification on new mail only when not transferred to trash | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Mitsu Hadeishi <mitsu> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mandrake RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Patch to May 2003 KMAIL HEAD to allow "do not notify on new messages" flag for a folder | ||
|
Description
Mitsu Hadeishi
2003-04-30 18:45:46 UTC
I stand corrected. The finish check happens after the filters are called; so this should be a relatively easy thing to do. Basically, when a filter move action is called on a folder marked "do not notify", a different return code can be returned which notifies the caller that a message was moved to a do not notify folder, which can be handled differently. Well, I downloaded the source code to kdenetwork 3.1 and added this feature to it. It's fairly clean but right now just limited to turning off mail notification for the trash folder. It is trivial to modify it (just redefine one method) to support other schemes for identifying folders where you do not want notification. Please contact me if you'd like my changes. I implemented this is KMail 1.5 (from KDE 3.1) and ported it to KMail HEAD and submitted it to the KMail developers, so hopefully it will get integrated into KMail. I have a different take on this feature request. As near as I can tell, most KMail users will have filters set up for their accounts. Regardless of how extensive their filters are, users would wish to disable notification for a certain set of incoming mail- say, mail that gets into their spam folder, or perhaps a high-traffic mailing list. Wouldn't a filter action (or checkbox, probably) meet this need more accurately than folder-by-folder preferences? I forsee a checkbox in the filter rule dialog near the "If this filter matches, stop processing here" checkbox. It could be labeled "If this filter matches, do not notify me." In my mind, most people are familiar with filter management, and it seems that keeping this option near where it would likely be sought makes a lot of sense. I'm not sure why nobody has suggested this idea yet- it seems like a pretty neat solution to this problem. OTOH, I may have missed another bug mentioning this idea. Of course, there may be any number of technical reasons to not do this, but I confess my ignorance. I also know that there is a filter action called Execute Command, but I don't think that covers the Kmail notification function. Also, it seems to me that several bugs all group around this same notion of selective notification. In particular, I've found that bugs 54268, 63710, and 60991 look similar- Is there a protocol for duplicate feature requests? Thanks for reading, Mischa. This would be a great feature - I see it implemented as a filter 'target' (along the lines of 'Move to Folder', 'Mark As...'), which allows you to filter which messages do or do not cause notification. At present, I'm subscribed to a few fairly high-volume mailing lists (ie linux-kernel) and would prefer not to be notified when new messages arrive from this list, as there is almost always at least one new message each time I check mail. Keep up the great work, Jeremy Comment #3 speaks about a patch. Would it be possible to attach the patch to this bug report so that it doesn't get lost? Created attachment 4961 [details]
Patch to May 2003 KMAIL HEAD to allow "do not notify on new messages" flag for a folder
Here's the patch I submitted last May --- I never had the time to fix the
issues that Ingo pointed out in the patch, though I keep planning to get back
to it. I also think this is a great feature, in fact, for me, KMail would be
pretty much useless without it. I have my own personal patched version running
on my machine here, but I'm probably the only one who has this feature!
This is fixed in KDE 3.3 / KMail 1.7. |