6.0.0-alpha12
6/10/25

[#6715] advance upon "Mark as..." broken
Summary advance upon "Mark as..." broken
Queue IMP
Queue Version 4.2-RC4
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester liamr (at) umich (dot) edu
Created 05/17/2008 (6233 days ago)
Due
Updated 05/19/2008 (6231 days ago)
Assigned 05/18/2008 (6232 days ago)
Resolved 05/19/2008 (6231 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
05/19/2008 11:28:46 PM Jan Schneider Comment #8
State ⇒ Not A Bug
Reply to this comment
I disagree with this statement.  Explicitly setting flags on a
message is different than message actions IMHO.  If I look at this
from the perspective of "how would I implement this if we didn't have
to reload the page" (i.e., how would I implement in DIMP) - flagging
messages would be something done in the background without changing
the page.  Deleting/moving/copying is something when you do when you
are done working with the message, so moving to another
message/returning to mailbox is ok.
Alright, you outvoted me. As I said, I don't use this personally 
anyway, so my opinion is not too strong about it.
And I don't personally feel this is a pref item.
No, please not.
05/19/2008 07:29:26 PM Michael Slusarz Comment #7 Reply to this comment
Flags are often like undelete, though - when we undelete a message,
we stay on that message.
That would be inconsistent too then, IMO. All message actions
consider the preference to return to the mailbox at the moment, which
is what I use. So they should all either stay at the current message
or proceed to the next, consistently, if that preference is turned
off.
I disagree with this statement.  Explicitly setting flags on a message 
is different than message actions IMHO.  If I look at this from the 
perspective of "how would I implement this if we didn't have to reload 
the page" (i.e., how would I implement in DIMP) - flagging messages 
would be something done in the background without changing the page.   
Deleting/moving/copying is something when you do when you are done 
working with the message, so moving to another message/returning to 
mailbox is ok.



And I don't personally feel this is a pref item.
05/19/2008 07:58:49 AM Jan Schneider Comment #6 Reply to this comment
Flags are often like undelete, though - when we undelete a message,
we stay on that message.
That would be inconsistent too then, IMO. All message actions consider 
the preference to return to the mailbox at the moment, which is what I 
use. So they should all either stay at the current message or proceed 
to the next, consistently, if that preference is turned off.
05/19/2008 02:34:08 AM liamr (at) umich (dot) edu Comment #5 Reply to this comment
In the version we're coming from (4.0.5), "Mark as..." advanced the 
message.   I'd be happy with a preference.
05/18/2008 11:58:02 PM Chuck Hagenbuch Comment #4 Reply to this comment
Flags are often like undelete, though - when we undelete a message, we 
stay on that message.
05/18/2008 11:51:29 PM Jan Schneider Comment #3 Reply to this comment
But we should be consistent with all message actions. And the user 
already has the choice to return to the mailbox or change to the next 
message after an action.
05/18/2008 11:44:09 PM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
Is this really more often than not going to be a "next-message" type 
action? I'd say about half the time I mark a message I'm not done with 
it, or at least I don't want the next message.
05/17/2008 12:32:29 PM liamr (at) umich (dot) edu Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ advance upon "Mark as..." broken
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
Reply to this comment
When you select 'Mark as [attribute]' while reading email, it does not 
move to the next message to continue browsing. Instead, it remains on 
the same email. This prevents fluid browsing and requires the 
redundant action of clicking the next message arrow after a message 
has been read and marked for later use.

Saved Queries