Tickets :: [#6715] advance upon "Mark as..." broken

6.0.0-alpha12

6/16/25

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 (6239 days ago)
Due
Updated	05/19/2008 (6237 days ago)
Assigned	05/18/2008 (6238 days ago)
Resolved	05/19/2008 (6237 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

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.