Open
Bug 507638
Opened 15 years ago
Updated 2 years ago
Refactor NEW message marking/flags, splitting into various roles
Categories
(MailNews Core :: Backend, defect)
MailNews Core
Backend
Tracking
(Not tracked)
NEW
People
(Reporter: rkent, Unassigned)
References
Details
Whenever I do work that affects any of the new message management methods, I am frustrated at all of the multiple definitions of "New", the multiple ways they are managed, and the impossibility of anticipating how any change will affect others. The root cause of this is that the definition of "new" is not clear, and means different things in different contexts. Some of the definitions: - this message is in a folder that has not been examined then exited since the message was first received (the NEW message flag) - this message is newly received, and needs filtering. - this message should trigger a biff notification at the next available opportunity. In addition to the confusion in definitions, there are a variety of overlapping methods used to manage the count and state of newness: - the New message flag is kept both in the database newList as well as in the message header flag. - folders have a separate count of new messages, as well as a state hasNewMessages that is not modified at the same time as the counts. This whole area needs a refactoring.
Comment 1•15 years ago
|
||
This is the definition of the new flag: - this message is in a folder that has not been examined then exited since the message was first received (the NEW message flag), and the message has not been read. Other pieces of code may poke at the new flag, but that's the definition.
Updated•15 years ago
|
OS: Windows XP → All
Hardware: x86 → All
Comment 2•15 years ago
|
||
One nice thing about decoupling this into two(?) roles is that it would allow front-end extensions to do more finely grained experimentation about when to notify users about which messages. Adding some folks who are likely to have helpful thoughts to the CC...
Reporter | ||
Comment 3•15 years ago
|
||
In FiltaQuilla, I actually have a filter action that supposedly disables notification on messages that fit a particular criteria. But I'm not sure that it is still working. New message management tends to break easily, and so I sorta assume it is broken until proven otherwise. The (relatively new) processing flags though would make life much easier for an extension. There should be a processing flag for notification, that could be set or reset by an extension (or custom filter action).
Comment 4•9 years ago
|
||
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Updated•6 years ago
|
Summary: Refactor NEW message management, splitting into various roles → Refactor NEW message marking/flags, splitting into various roles
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•