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)

defect

Tracking

(Not tracked)

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.
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.
OS: Windows XP → All
Hardware: x86 → All
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...
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).
Blocks: 373182
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Summary: Refactor NEW message management, splitting into various roles → Refactor NEW message marking/flags, splitting into various roles
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.