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 720943 - vFolder does not refresh automatically
vFolder does not refresh automatically
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[vfolders]
Depends on:
Blocks:
 
 
Reported: 2013-12-22 18:08 UTC by Hans Petter Jansson
Modified: 2014-01-23 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hans Petter Jansson 2013-12-22 18:08:59 UTC
Evolution 3.10.2.

When new mail arrives, I see the unread count increasing in one of my local mail folders.

One of my vfolders has the expression "#t" with sources set to a couple of local mail folders -- essentially a join operation -- including the one that just received mail.

The vfolder's option "Automatically update on any source folder change" is set to true. However, it does not register the newly arrived mail until I visit a different folder. Its unread count will then immediately increase, and I can go back and see the new mail. Manually refreshing using F5 also works.
Comment 1 Milan Crha 2014-01-21 18:34:51 UTC
Thanks for a bug report. With "local mail folders", did you mean one under On This Computer, or a special account? If the later, what is the account type, please?
Comment 2 Hans Petter Jansson 2014-01-22 16:29:23 UTC
The rule looks like so:

Match: All the following conditions
Include threads: Replies and parents
Expression: #t

Automatically update on any source folder change: true

Specific folders:
  On This Computer: Folder 1
    Include subfolders: false
  On This Computer: Folder 2
    Include subfolders: false
Comment 3 Milan Crha 2014-01-23 10:50:39 UTC
Thanks for the update. I think I can reproduce this too, but before I describe what I've found, let me tell you that the "Include threads: Replies and parents" is not needed in your case, because you include all messages from the folders already - the option is used to include whole thread even in cases when your condition satisfies only one message from the give thread. You will not notice any visual difference if you change "Include threads" to "None", but the virtual folder processing in the background will be significantly cheaper than it is now.

Back to the point: I created the same virtual folder, to make it easy, I chose my On This Computer/Inbox as one folder, and On This Computer/Sent as the other, thus they overlap and can create threads of "conversation".

When I close evolution and run it again, staying either in Inbox, or in Sent. I change a read/unread status on one of the messages, but the unread count doesn't change in the folder tree for the virtual folder (say I marked it unread). I mark it back read, and after this initial round, the virtual folder will start processing events properly, thus if I repeat the "mark as unread" step, then the unread count of the virtual folder changes properly.

I saw a similar issue when copying messages into my Inbox, the virtual folder didn't show the message for the first time, only after I copied one more message there. I cannot reproduce it currently (reliably), but I'm pretty sure it has the same reason like the read/unread message status change from the previous paragraph.
Comment 4 Milan Crha 2014-01-23 12:48:35 UTC
This was tricky. Any message selection in the message list tries to set the message as unread, where the vFolder's summary ignores the change event from the related folder. The thing is that if the related folder doesn't emit the 'changed' signal, then the vFolder still has noted to ignore it, thus the next real 'changed' signal is ignored, and the vFolder keeps the change saved for later use, like when calling a Refresh. I changed this in a way that if the message info of the related folder did not change, then the noted "ignore next change event from this folder" is removed. That is supposed to fix it.

Created commit 8b07bce in eds master (3.11.5+) [1]
Created commit 5132a40 in eds gnome-3-10 (3.10.4+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=8b07bce