After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575701 - messages in unread vfolder disappear once replied to
messages in unread vfolder disappear once replied to
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.26.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[disk-summary]
Depends on:
Blocks: 543389
 
 
Reported: 2009-03-17 14:19 UTC by Brian J. Murrell
Modified: 2009-06-21 18:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Description Brian J. Murrell 2009-03-17 14:19:00 UTC 
I know this is probably covered by one of the many other unread vfolder bugs, but I wanted to file a new one to clarify a particular mis-behavior.

Simply put, when I reply to an e-mail in an "unread" vfolder (yes, I have the Unread Search Folder checkbox hack selected) once I have sent the reply, the original message disappears from the message summary list and the preview moves on to the next message.

However, if I simply mark a message read in the exact same view, it stays visible in the unread folder until some event resynchronizes the summary list.

This difference in behavior is obviously dis-contiguous and should not be happening.  The summary behavior should not be at all different between simply marking a message read and reading and replying to it.
Comment 1 Srinivasa Ragavan 2009-03-18 08:16:50 UTC 
I think it makes sense.
Comment 2 Brian J. Murrell 2009-03-18 11:23:10 UTC 
(In reply to comment #1)
> I think it makes sense.

Can you clarify?  Do you think the difference in behavior makes sense or do you think it makes sense that the behavior should be the same for both use cases?
Comment 3 Srinivasa Ragavan 2009-03-19 04:37:05 UTC 
Wait, I said, what you said makes sense. Sorry for not being very clear.
Comment 4 Brian J. Murrell 2009-06-11 11:46:00 UTC 
Is there any progress on this bug?  It's now nearly 3 months old and not a single update to it.
Comment 5 Srinivasa Ragavan 2009-06-20 14:28:26 UTC 
Fixed in master/gnome-2-26.
Comment 6 Brian J. Murrell 2009-06-20 17:08:28 UTC 
(In reply to comment #5)
> Fixed in master/gnome-2-26.

So, what release, if any yet, would this be landed on?  Or was it landed on the branch after 2.26.2 and as such no release has been made with this fix in it yet?
Comment 7 Srinivasa Ragavan 2009-06-20 18:02:10 UTC 
Oh, I fixed it ~3 hours back and committed. You will see it in 2.26.3
Comment 8 Brian J. Murrell 2009-06-20 18:17:30 UTC 
(In reply to comment #7)
> Oh, I fixed it ~3 hours back and committed. You will see it in 2.26.3

Ahhhh.  Sweet.

As a sidebar regarding bz etiquette, it would be very useful to those following a bug, that when somebody closes a bug as "fixed" that they say what release the fix should appear in.  Otherwise it's very confusing to know the difference between "i just fixed this one" and "this one has been fixed for a while now, closing".
Comment 9 Srinivasa Ragavan 2009-06-21 18:52:27 UTC 
Oh sure, point taken.