The infamous unread email flag bug

[fpbear]

Anyone know if Microsoft is planning to fix this bug? I'd imagine it
shouldn't take that much code to fix it. It's been several years that
people have been complaining about this on the web.

Basically if you have a Rule that automatically marks certain mail read, the
task tray notification icon (little yellow envelope) stays there. It is
supposed to disappear.

This bug forces the user to continuously open and sort through the inbox to
see what arrived, when there is nothing there - it was already processed and
marked read. This often affects spam plug-ins.

The bug existed in Outlook 2003, and still there in Outlook 2007. Now it's
2008. So at least it's been 5 years.

 

[VanguardLH]

Anyone know if Microsoft is planning to fix this bug? I'd imagine
it shouldn't take that much code to fix it. It's been several years
that people have been complaining about this on the web.

Basically if you have a Rule that automatically marks certain mail
read, the task tray notification icon (little yellow envelope) stays
there. It is supposed to disappear.

This bug forces the user to continuously open and sort through the
inbox to see what arrived, when there is nothing there - it was
already processed and marked read. This often affects spam
plug-ins.

The bug existed in Outlook 2003, and still there in Outlook 2007.
Now it's 2008. So at least it's been 5 years.

The design was to trigger the tray icon when new items were received
in the Inbox. Has nothing to do with rules. The trigger occurs
before rules are ever exercised against any e-mails. The tray icon
doesn't trigger after the rules are applied to see what might be left
as marked unread in the Inbox. So, by design, the tray icon is doing
what it was supposed to do. That it doesn't do what you want is
different than it doesn't work as designed.

Rather than use the tray icon, and because you want to see what is
*left* AFTER the rules have executed, disable the tray icon and add a
rule at the end of the list that pops open an alert window. If all
the prior rules failed to trigger then the catchall rule at the end
will fire to let you know there was a new item delivered to your
Inbox. If some of the prior rules should also fire off an alert and
also use the stop-clause, you'll have to add the alert clause to those
rules. You end up using the rule-fired alert window to let you know
of new e-mails rather than the tray icon that wasn't designed the way
that you want it to work.

 

[fpbear]

Vanguard, that does not sound correct.

(a) When a message is marked read in the preview pane, the flag disappears
from the task tray.

(b) When a message is marked read because of a rule, the flag stays around.

So your argument that I'm coming up with some new feature doesn't make much
sense to me. It only makes sense to sync up (a) and (b) behavior.

There is interaction between mail being marked read and the flag, because
this is the behavior in the preview pane. By default this is set to mark
the mail read when the selection changes. I like to set mine to mark the
mail read after 1 second. In any of these cases, the task tray flag
disappears.

The programmers could use the same communication mechanism to get rid of the
flag during the mark-read rule processing.

When a message is marked read in the preview pane, the software talks to the
task tray flag somehow.

Why is it so hard to talk to the flag in the same way for a rule? Did the
programmer use some highly unconventional technique?

 

[fpbear]

Also, something about software application architecture best practices:

When the mark-read rule is processing, it is not the job of the rule engine
to check for all the remaining messages that are still unread. Instead this
should be the job of the application module that is responsible for the
read/unread status and display changes pertaining to that status.

I have a feeling that during the creation of the rule engine some programmer
used an unconventional technique and just changed the bold face to non-bold
formatting for a read message and said to the software development manager
"hey I'm all done." .... instead of using the proper API.

 

[VanguardLH]

Vanguard, that does not sound correct.

(a) When a message is marked read in the preview pane, the flag
disappears from the task tray.

And once you commit the manual action through the GUI, the status gets
updated. Whether you read (or mark as read) a message that would or
would not have triggered a rule is irrelevant when manually marking
the message as read.

(b) When a message is marked read because of a rule, the flag stays
around.

That was the premise of your original post, that the tray icon did not
reflect the results of the Inbox items and their read-status AFTER the
rules had been executed.

 

[Diane Poremsky {MVP}]

marking a message read using rules happens during MAPI processing while
reading it in the reading pane happens after the mapi spooler is finished
handling it so you can't compare the behavior.

Either use the method vanguard suggested or use the unread (or a custom
search) folder to read new mail and ignore (or disable) the tray icon.









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **

 

[VanguardLH]

Also, something about software application architecture best
practices:

When the mark-read rule is processing, it is not the job of the rule
engine to check for all the remaining messages that are still
unread. Instead this should be the job of the application module
that is responsible for the read/unread status and display changes
pertaining to that status.

I have a feeling that during the creation of the rule engine some
programmer used an unconventional technique and just changed the
bold face to non-bold formatting for a read message and said to the
software development manager "hey I'm all done." .... instead of
using the proper API.

I have run across many perceived ease-of-use anomalies that when
reported has the developer claiming that it is working as designed. I
then go read the Functional Specification and come back with the claim
that the behavior is not so specified. The result is usually to
change from "working as designed" to "working as coded". So I end up
issuing a trouble ticket to report the ease-of-use defect and won't
close it based on the lame "working as coded" excuse. But as a QA
tester, I can't change the product but only recommend changes or
report defective behavior that differs from the spec (I can report
what I think is a defect but have to work on getting the developers to
agree if it is not spec'ed that way). After all, you are complaining
to a peer community of users that can't do anything to change the
product. What do you want us users to do about it?

 

[Diane Poremsky {MVP}]

Are you familiar with MAPI or the Outlook object model and rules engine?









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **

 

[fpbear]

And once you commit the manual action through the GUI, the status gets
updated. Whether you read (or mark as read) a message that would or would
not have triggered a rule is irrelevant when manually marking the message
as read.

In the first sentence it sounds like you're essentially saying that manually
marking read works ok, which is no surprise. I don't understand the second
sentence.

That was the premise of your original post, that the tray icon did not
reflect the results of the Inbox items and their read-status AFTER the
rules had been executed.

It's when the rules is executed when this bug manifests itself, not sometime
after. When a rule specifically executes to mark the item read, the new
message flag does not go away. But there is no more new message anymore
because the user made it so via the rule.

Microsoft saw this logic when items are manually marked read, and clears the
tray icon. Why is this logic not clear when using a rule?

Ok so then I should ask this question instead,

Does a mail filtering rule to mark read deserve to be disconnected from
normal UI (tray status) behavior because it is automatic vs. someone
clicking to mark read?

 

[fpbear]

marking a message read using rules happens during MAPI processing while
reading it in the reading pane happens after the mapi spooler is finished
handling it so you can't compare the behavior.

The MAPI rules processing engine is integrated to the UI enough to change
the message subject from bold to normal when it is marked read. Then, with
a little extra programming, Microsoft could "complete the job" and trigger
another detection routine make that little task tray icon disappear if there
are no more unread messages. Just call the same function that is called
when the user manually clicks to mark as read.

Either use the method vanguard suggested or use the unread (or a custom
search) folder to read new mail and ignore (or disable) the tray icon.

Vanguard has a neat idea but that involves disabling the tray icon. The
tray icon is more user friendly than a pop up box. I would go nuts if I had
a pop up box every time I get new emails. It would be better if Microsoft
just finally fixes this in Outlook 2012.

 

[fpbear]

"fpbear" <[email protected]> wrote in message

I have run across many perceived ease-of-use anomalies that when reported
has the developer claiming that it is working as designed. I then go read
the Functional Specification and come back with the claim that the
behavior is not so specified. The result is usually to change from
"working as designed" to "working as coded". So I end up issuing a
trouble ticket to report the ease-of-use defect and won't close it based
on the lame "working as coded" excuse. But as a QA tester, I can't change
the product but only recommend changes or report defective behavior that
differs from the spec (I can report what I think is a defect but have to
work on getting the developers to agree if it is not spec'ed that way).
After all, you are complaining to a peer community of users that can't do
anything to change the product. What do you want us users to do about it?

I'm hoping someone from Microsoft will read this, and then they can go do a
web search and find posts from thousands of other users talking about the
same thing. Then maybe this bug will raise higher on the manager's priority
list.

 

[fpbear]

Are you familiar with MAPI or the Outlook object model and rules engine?

Yes I had to work with MAPI in 2003, it has a long history and needs some
re-architecting.

 

[VanguardLH]

In the first sentence it sounds like you're essentially saying that
manually marking read works ok, which is no surprise. I don't
understand the second sentence.


It's when the rules is executed when this bug manifests itself, not
sometime after. When a rule specifically executes to mark the item
read, the new message flag does not go away. But there is no more
new message anymore because the user made it so via the rule.

Microsoft saw this logic when items are manually marked read, and
clears the tray icon. Why is this logic not clear when using a
rule?

Ok so then I should ask this question instead,

Does a mail filtering rule to mark read deserve to be disconnected
from normal UI (tray status) behavior because it is automatic vs.
someone clicking to mark read?

Personally I'm with you that a rule that marks as read should update
the tray icon. Microsoft decided otherwise. As a user in a peer
community in a Usenet newsgroup, I have no way to change what
Microsoft did and discussing it here will not alter code.

Marking as read is not the same as actually reading it. The same
distinction is lost on users when they permanently delete a message
and then wonder why they have to compact their message store to
actually get rid of the already permanently deleted message.
*Marking* a message to have status "deleted" does not physically
remove it from the message store. It merely tells Outlook not to
*display* that item anymore. Compaction is the action of physically
purging the delete-marked item from the message store.

For example, you might use a rule to move certain mails into a folder
and also mark them as read. Okay, but you are expected to read those
mails in that special folder whether they are *marked* as read. That
is, you are still supposed to READ them regardless of the read/unread
status. There is more than one use for the read/unread status of an
item, just like there can more than one use for a flag. Marking a
message as read really only has the effect of unbolding that item in
the list. Say you are responsible for code compiles during the day.
You are supposed to update a table on a web site used by developers
and QA folk to let them know when the compile is done so developers
can proceed to the next compile and QA folk can begin testing the new
code. You don't want those items bolded in your Inbox because they
are less priority. You are already using the low/high priority flag
for some other purpose so you rely on the bolding to indicate other
priority. You are still responsible for *reading* those "marked
unread" e-mails to update the web site but the bolded messages are
more important for you to look at first.

I doubt we would be discussing this problem if the clause had been
written "make item bold" or "make item unbold". Well, it can have
other effects if you are using Exchange and why it is not important
about the state of the tray icon. I believe, for example, that you
manually clicking on a message which changes its status (and updates
the tray icon) can also be used to trigger events back in the Exchange
or RM servers. So YOU reading the message is very important whereas
whether or not you happen to use a rule to change its bolding is
unimportant to others that need to know status of you reading that
item.

 

[VanguardLH]

in message

I'm hoping someone from Microsoft will read this, and then they can
go do a web search and find posts from thousands of other users
talking about the same thing. Then maybe this bug will raise higher
on the manager's priority list.

I doubt it. As I recall, Microsoft (through their Contact Us link),
had you submit a feedback webform for those type of requests.
Individual requests will have little or no impact to change code. I
doubt even hundreds of such requests would make a dent in their design
philosophy. There could be thousands of complaints here in Usenet but
only maybe a dozen of those thousands of users bother to submit a
feedback using the webform. More often it takes one, or more, large
corporations with a fat contracts with Microsoft and who are also
paying for premium support from Microsoft to nag loud enough for
Microsoft to hear and comply. You could, for example, pay hefty for
an MSDN subscription to get closer to Microsoft's ear.

Hoping that Microsoft does anything to alter their software based on
posts here is as likely as submitting spam reports to SpamCop will
reduce the outflux of crap from spammers. Here you need to find out
how to fix or workaround a problem or defect. In SpamCop, you really
just want to get their blacklist updated. Anything other expectation
is about as real as pushing a disconnected crosswalk button: it eases
your frustration but with no real change.

 

[Brian Tillman]

The MAPI rules processing engine is integrated to the UI enough to
change the message subject from bold to normal when it is marked
read. Then, with a little extra programming, Microsoft could
"complete the job" and trigger another detection routine make that
little task tray icon disappear if there are no more unread messages.
Just call the same function that is called when the user manually
clicks to mark as read.

You can contend it's a bug all you want. The fact remains that rules do not
affect the tray icon. Consider: you have three messages arrive at one time.
The tray icon appears. A rule you have defined moves ONE of the messages
and the other two remain. Do you want the tray icon to continue to display,
indicating that there are more unread messages, or do you want the rule to
turn it off? Remember, this is during rule processing when you might not
even be around to know that new messages have arrived. No matter which you
choose, SOMEONE will be unhappy with the choice.

 

[fpbear]

You can contend it's a bug all you want. The fact remains that rules do
not affect the tray icon. Consider: you have three messages arrive at one
time. The tray icon appears. A rule you have defined moves ONE of the
messages and the other two remain. Do you want the tray icon to continue
to display, indicating that there are more unread messages, or do you want
the rule to turn it off? Remember, this is during rule processing when
you might not even be around to know that new messages have arrived. No
matter which you choose, SOMEONE will be unhappy with the choice.

I think you meant to say in your example that a rule you have defined
performs the action "mark it as read" on one of the emails but not for both
(rather than "move"). In this case of course the tray icon should continue
to display because two unread (bold) emails remain in the inbox. If all
three are acted upon by the "mark it as read" rule because all three meet
the criteria, then there are no more messages to read and the flag should
disappear if the problem were fixed. I don't think any user would be
unhappy with this behavior. This is the expected and correct behavior.

So then I'll explain my particular case. As a software architect at my
company I joined a new project where every member of the team receives
automatic email notification whenever a file is committed to source control.
I get enough emails every day and I don't need to be bothered by these, but
I need to find them in an email folder for reference whenever the need
arises.

So I created an Outlook rule to match the subject and move the messages to a
folder, and also to "mark it as read." I use this rule because I don't need
to know that I didn't read some developer's source control notification
email (on another project I worked on before this, we got daily build
emails; similar story).

But the problem is, now I get these phantom task tray notifications with the
little yellow envelope telling me that I have new email, when I really
don't. If I want the flag to disappear I have to go into the source control
folder and try to guess which email triggered the flag (probably the most
recent) and click on it. It is not bold anymore and has already been marked
read, but as soon as I click on "mark as UNread" the flag disappears! Very
weird, but this works as a cumbersome manual flag clearing step.

The reason I need the new mail notification flag in the task tray is because
often I get very important emails, such as when someone wants to arrange a
meeting, and I need to know when these arrive. I have many other
application windows open and I can't be staring at the Outlook preview pane
all day long. When the task tray envelope appears I know that I need to
open Outlook.

But that is all messed up now, and this kind of this affects office
productivity, because the "mark as read" rule is really not marking as read,
so that is a bug. Instead of really marking as read, it is just changing
the subject from bold to normal text. Some programmer took a shortcut here.

 

[fpbear]

Personally I'm with you that a rule that marks as read should update the
tray icon. Microsoft decided otherwise. As a user in a peer community in
a Usenet newsgroup, I have no way to change what Microsoft did and
discussing it here will not alter code.

OK so we agree then it should be fixed. Anyone from the Microsoft
development team reading this?

I doubt we would be discussing this problem if the clause had been written
"make item bold" or "make item unbold".

Yes it is misnamed for what it does. I suppose Microsoft could make two
different rules,

(1) "make the item unbold" which does the same thing as the rule that is
currently named "mark as read."

(2) "mark as read" which really marks it as read (including updating the
flag status).

 

[Diane Poremsky {MVP}]

BTW - what version of Outlook do you use? I thought 2007 handles it better,
although I never tested it as I never bother with marking messages read
since I never look at the tray (too much other crap there and windows hides
the mail icon eventually) and tune out the new mail sound - I just move the
messages that are not important and deal with what is in the inbox. I check
the inbox every now and again on my schedule - checking it each time new
mail arrives (whether you use the tray icon, sounds or toast to alert you)
is a sure way to kill productivity.









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **

 

[Diane Poremsky {MVP}]

The problem Brian was trying to explain: Say you get 3 messages. the first 2
stay in the inbox. #3 is moved by a rule that marks as read and removes the
tray icon. As soon as a message is read, the icon disappears - it doesn't
matter if you have 1 or 50 unread messages in the inbox, as soon as 1 is
marked read, the icon disappears. So now you don't have the icon to alert
you that there are new messages in the inbox.

Now if the order is the marked read message first then the other 2, its not
an issue - the first one removes the icon, but the next ones restores it.

The rule works fine if you always get messages 1 at a time - but anyone
using pop or cache mode / rpc over http where the messages are received in
bunches will not benefit by removing the tray icon via a rule.









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **

 

[Diane Poremsky {MVP}]

The reason I need the new mail notification flag in the task tray is

because often I get very important emails, such as when someone wants to
arrange a meeting, and I need to know when these arrive. I have many
other application windows open and I can't be staring at the Outlook
preview pane all day long. When the task tray envelope appears I know
that I need to open Outlook.

for cases like this turn off the tray notification and use a rule to move
the messages. Use stop processing on all the rules that move messages and a
final rule that applies to all mail (stop processing on the earlier rules
makes this rule apply only to messages that are left in the inbox) that
plays a sound and/or runs an application that adds an envelope icon to the
tray.