"VanguardLH" wrote in message
...
"fpbear" 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.

"Diane Poremsky {MVP}" wrote in message
...
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.

"fpbear" wrote in message
...
"VanguardLH" wrote in message
...

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?


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.

"fpbear" wrote 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.

fpbear wrote:

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.
--
Brian Tillman [MVP-Outlook]

"Brian Tillman" wrote in message
...

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.

"VanguardLH" wrote in message
...

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).

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.

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Need Help with Common Tasks? http://www.outlook-tips.net/beginner/
Outlook 2007: http://www.slipstick.com/outlook/ol2007/

Outlook Tips by email:


Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com
Subscribe to Exchange Messaging Outlook newsletter:


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


"fpbear" wrote in message
...
"Brian Tillman" wrote in message
...

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.

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.

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Need Help with Common Tasks? http://www.outlook-tips.net/beginner/
Outlook 2007: http://www.slipstick.com/outlook/ol2007/

Outlook Tips by email:


Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com
Subscribe to Exchange Messaging Outlook newsletter:


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


"fpbear" wrote in message
...
"Brian Tillman" wrote in message
...

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.

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.