GNOME Bugzilla – Bug 625035
Right clicking on a folder and choosing 'Mark Messages as Read' always brings up the only-this-folder/subfolders dialog
Last modified: 2010-07-26 08:15:41 UTC
If you right click on any folder and click 'Mark Messages as Read', it will *always* bring up the dialog that asks you if you want to mark messages in sub-folders as read, even if the folder has no sub-folders. I would expect the dialog to only appear if, not only are there sub-folders, but there are unread messages in those sub-folders (see bug #609982). I experience this bug on Evolution 2.30.2 under Fedora 13.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 546551 ***
This is not a duplicate of 546551. That bug is that the dialog will always mention subfolders. This bug is that the dialog always appears, regardless of whether there are subfolders at all (never mind sub-folders with unread messages in them). This is a regression, the behaviour used to be correct a version or two ago - i.e. the dialog would only appear if there actually were subfolders with unread messages (see the bug I mention in comment #0 too).
It has been fixed with patch in https://bugzilla.gnome.org/show_bug.cgi?id=546551#c10
Fair enough :) Maybe the summary of bug #546551 should be altered to reflect the other things it fixes? Will this patch be available in the next stable 2.30 series version? *** This bug has been marked as a duplicate of bug 546551 ***
(In reply to comment #4) > > Will this patch be available in the next stable 2.30 series version? > Actually the patch has string change so without requesting for string freeze break, it won't be possible to commit the fix in 2.30.x.
Is there any chance of applying a version of the patch that doesn't change strings? The text of the dialog involved in this bug is fine, it's just its constant appearance that's incorrect.