GNOME Bugzilla – Bug 562912
Unread vfolder marks unread messages as read
Last modified: 2016-12-02 14:20:29 UTC
Please describe the problem: The behaviour of the "Unread" vfolder has regressed since 2.20: * In 2.22 new behaviour was introduced: the previously selected message in the Unread vfolder (usually the last one marked as unread so it could be processed later) got selected at startup automatically, and marked as read after the timeout. So if the user forgot to mark it as unread again before closing evolution or his/her desktop crashed, a message that was never read (in human terms) got marked as read by the application and would never reach the user's eyeballs. * In 2.24 it's gone even further. Whenever new mail comes in or the user manually deletes a mail (either directly or by marking it as spam), the Unread vfolder's view gets updated. So if a user is reading mails in the vfolder, all the mails that are already read are removed from the list. Combine this latest behaviour with multiple email accounts and a mailfilter that takes longer than the "mark as read" timeout to check the messages in a given mail account for spam, and you have a recipe for lost mails: 1. New mail comes in at account A, and after the spamfilter is done with it and releases it to evolution, the Unread vfolder is updated. 2. The currently focussed mail (plus every other read mail) gets removed from the vfolder. 3. The next unread mail is automatically selected and marked as read after the timeout. 4. By then, the spamfilter is done checking account B's messages and releasing them to evolution. Repeat for the number of accounts in a given user's list. In my case, that would be potentially 8 messages lost every 5 minutes. Steps to reproduce: 1. Read messages in your "Unread" vfolder 2. Wait for new mail to arrive, or force a manual update by deleting a message Actual results: The messages which were read during the current session disappear from the vfolder, and a new one automatically gets selected and marked as read. Expected results: New incoming (unread) messages appear in vfolder and/or deleted messages disappear from it, but the read messages remain until the user either selects another (v)folder, or closes the application. Other than that, I expect messages selected automatically by the application, rather than the user, never get their status updated unless the user indicates otherwise by either updating the message manually (e.g. marking as read, replying, forwarding, ...) or shifting the focus to another message. Does this happen every time? Yes Other information: I assume this has to do with the switch to sqlite in 2.24; I can imagine it's easy to just do an sql query to the DB to update the "unread" view every time mails come in or disappear. I suppose with the old system, it was a bit harder to update a vfolder on the fly, and required evolution to read all mails and select them on a case-by-case basis for inclusion in the vfolder. That would certainly explain the "lazy" updates where only the affected mails (the new arrivals or the deletes) got added/removed instead of iterating over the whole list again. However, those "lazy" updates are what people expect from an "unread" vfolder as far as I know. People certainly don't expect the inconsistent behaviour where read mails to remain in the unread folder, except if mails get deleted or new mail arrives. The previous behaviour can however be simulated without sacrificing the convenience of on-the-fly updates via simple SQL queries. It requires addition of one table to the DB with the required fields to uniquely identify an email and a vfolder. An extra field called session_id is also present in this table. For the sake of convenience, let's assume that a mail can be uniquely identified by one id called mail_id. In reality I suppose you also need the account_id and folder_id, but that's irrelevant for the method I'm about to explain. This new table would then contain the following fields: vfolder_id, mail_id and session_id. * A unique number, the session id, is generated when the application starts and kept in memory, or even written to the DB * A vfolder's contents are only calculated when the application starts; all matching mails are added to the new table, and the table defines the view * Whenever new mail arrives that matches the criteria of the given vfolder, the tuple (vfolder_id, mail_id, session_id) is added to the new table * Whenever a mail in a vfolder gets deleted, its tuple gets removed from the table Obviously, this is just a proposal. But that's how I would code this, assuming that my hunch regarding the cause of this regression is correct. I must admit I haven't checked the code, nor am I a good enough coder to write an elegant patch myself. Bonus advantage of using this method: crash recovery. By storing "last_session_id" in the DB, or deriving it (for example by using an auto_increment field or a datetime field as session_id) one can recreate the state of the vfolders from before the crash. I don't think I'm the only one who goes over his "read" folder once, and later, before closing the application, starts marking messages unread if he wants to process them next time. If evolution, gnome or the complete computer were to crash in the meantime, the session could be easily recovered. Hope this helps and wasn't too verbose. ;)
*** Bug 562667 has been marked as a duplicate of this bug. ***
We've a downstream bug for this as well. https://bugzilla.redhat.com/show_bug.cgi?id=487262
Can you right click on the unread vfolder and enable 'Unread search folder' option and try out. Its a hack, but therez no option yet. Its tough to keep the read message in the message list of just unread list. I need to find time to redo this portion, which Im not getting :/ Just test and lemme know.
(In reply to comment #3) > Can you right click on the unread vfolder and enable 'Unread search folder' > option and try out. Its a hack, but therez no option yet. Its tough to keep the > read message in the message list of just unread list. I need to find time to > redo this portion, which Im not getting :/ > > Just test and lemme know. > Option is enabled, same behaviour. But I'm running stock evolution from Ubuntu 9.04, being Evo 2.26.1. Would it be useful for me to download & build latest cvs/svn/... rev. and try with that?
I guess this version is latest enough, though there is a newer one. But, Lemme confirm your issue. In the unread vfolder, the selected mail dis appears when a new mail comes to the folder? Is it the core of the issue? I tried to simulate with marking a message as unread on the parent folder, in a new view. My selected message stayed. But the other read messages disappeared. Its design. When the folder list updates, it removes stale <unread> mails, but keeps the read mail under the cursor. In 2.27.3 code base.
Yes and no. The selected mail now remains, sorry, hadn't noticed that since I don't mark mails as read automatically anymore. All the other read mails still disappear though. I still consider the current behaviour flawed. Mails disappear from the list when a new mail comes in. This is not how people expect their unread folder to behave. What people expect is this: unread folders retain read mails for as long as the view doesn't change. New incoming mails get added to the list in the appropriate spot, read mails remain. This is how other mail clients implement it, and this is how Evolution used to implement it. Imagine the following scenario: you're subscribed to some maillist(s), you're following a thread in your unread vfolder, and the messages get marked as read as you read them one by one. At a certain point, you want to verify something in an earlier mail in the thread; one that you've read a couple of minutes ago. Before you locate it again in the list and can select it, your mailboxes get checked again and you guessed it: you've got mail... Now if this were another mail client, that wouldn't be a problem. But this is the new Evolution, so the whole thread disappears except the one mail you had currently selected. Does it seem logical that your task of exploring that discussion thread gets interrupted and made impossible without switching away from the unread folder towards the mailbox in question, simply because someone couldn't wait another hour to send you a mail? And what added benefit does this new behaviour bring to the user? Does it weigh up to the inconvenience of having to alter the way he reads his mails? So yes, retaining the currently selected mail is a good solution for the worst side effects of this bug, and enough to make the wait for a real solution bearable. I don't consider the bug itself fixed though.
I am using: % rpm -q evolution evolution-0:2.28.2-1.fc12.x86_64 ...and still have "auto mark as read after X time", and the currently selected message will still disappear (and thus. move the cursor to the next message, which is then marked as "read", etc. ... until no messages remain in the VFolder).
#7 I have the same problem. All messages is removed in Unread. vFolder/Search folders stopped working a long time ago and now Unread is broken to.
Latest behaviour makes it even worse. Before, messages would remain in the unread vfolder until you either switched away or new mail came in. Now they're removed immediately upon being marked as read, even when they're still selected and thus open in the preview pane. Currently running Evolution 2.30.3 on Ubuntu 10.10.
*** Bug 598018 has been marked as a duplicate of this bug. ***
*** Bug 642231 has been marked as a duplicate of this bug. ***
In 3.0.0 the problem with automatically marking mails as read one by one as soon as I clicked one is back! Yeah! 2.32.2 worked fine, really fine. But since I've installed 3.0.0 the "Unread" vFolder is unusable again. :-( TODO: set version tag to 3.0.0
still there in 3.0.2
Created attachment 194471 [details] [review] eds patch for evolution-data-server; Not the best solution I ever wrote, but it seems to work. Maybe the background logic of it is also correct, but consider yourself: if user changes messages inside a search folder, then the folder doesn't propagate this change immediately, but only on folder refresh or synchronization, thus the message will not disappear immediately, causing auto-reading of messages. This used to work before folder changes were delivered immediately, but it was also not completely right, as total counts got broken by the change as well. Also, this was done for unread folders only, but my change makes this work for any virtual folder, except of virtual trash and junk folders.
Created commit a8df571 in eds master (3.1.90+) Created commit 4de215d in eds gnome-3-0 (3.0.3+) ------------------------------------------------------------------------------- Committed change in master is slightly larger, I removed all the "deprecated" API, as it was not needed and there was an API change just after 3.1.5 release, thus this is covered under one soname version bump for libcamel. Also note that there might be necessary to remove your cache for search folders, to have counts working as expected. It's enough to do something like this: $ rm ~/.local/share/evolution/mail/vfolder/ -rf
*** Bug 546637 has been marked as a duplicate of this bug. ***
*** Bug 602378 has been marked as a duplicate of this bug. ***
Again there in 3.2.2! It was somewhat ok in 3.2.1. EMails were only marked as read, if new mails came in while I had the "Unread" vFolder active. Then the selected mail was chosen randomly and set as read. In 3.2.2 the problem got worse: Every time I activate the "Unread" vFolder, it chooses one random mail and marks this as read. If I don't pay attention, this renders all my important TODOs (=unread mails) unuseable. TODO: set status to "CONFIRMED" TODO: set version to "3.2.2"
I cannot reproduce it, the mesage is marked as read (because I have the timeout set), but it's not vanished from the view, as long as I stay in the unread vFolder. It seems to me that the right way for you is to disable the automatic mark as read, because it only breaks your work-flow. The option is gone from Preferences (do not ask me why, I do not like that decision either), but you can turn it off with a GConf command: $ gconftool-2 --set --type=bool /apps/evolution/mail/display/mark_seen false