View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000736||SOGo||Web Mail||public||2010-08-07 17:31||2011-04-09 19:38|
|Fixed in Version||1.3.6|
|Summary||0000736: New mail displays only after second check|
After upgrading to 1.3.0, we've noted that new mails only display for reading after the second time SOGo checks for new mail (either automatically or manually via the "Get Mail" button).
Between the first and second checks for new mail, new messages are indicated next to the Inbox folder, but cannot be seen in the main webmail window. (See the attached screenshot.)
IMAP server is Dovecot 1.0.15.
Other mail clients don't have this issue.
|Tags||No tags attached.|
sogo_webmail.png (33,981 bytes)
sogo_webmail.png (33,981 bytes)
This should no longer be the case in the upcoming 1.3.2 version. Verify on sogo-demo.inverse.ca if you want.
Thank you, Ludovic. Unfortunately I still see this issue in the CentOS nightly (201008260647).
Don't know if this is pertinent, but at one point I had it briefly working normally again after removing the files in /tmp: clay GNUstepSecure502 hsperfdata_root and restarting the server. Another server restart and the issue returned and I haven't been able to clear it again.
I don't see any errors in the SOGo or Dovecot logs.
More info on this, FWIW.
Testing 201011150650 to see if any of the recent changes have resolved this, I've also noticed that the reverse situation can also occur. If I use only "Manual" checking for new mails, the number of new mails displayed next to Inbox never gets updated, though the new mails show up in the Inbox correctly.
Looking at sogo.log I've noticed different entries for automatic and manual mail checks.
Automatic checks generate:
Manual checks generate:
Could the missing line for unseenCount explain the behavior of the new messages count being off during manual mail checks?
Fixed in revision 1a7fb070202750af8cc8edfa2a6ffba467b2b25b.
The fix helped, but the original issue still remains for us (Dovecot 1.0.15).
Here's some more info from my testing and watching the SOGo logs.
When a new mail arrives to my Inbox, I see different log entries when SOGo first checks for mail and then checks a second time. The logs (and behavior) are the same if the checks are manual or automatic.
FIRST CHECK (new mail count correct, new mail not in Inbox):
localhost.localdomain - - [19/Nov/2010:14:50:45 GMT] "POST /SOGo/so/cwright/Mail//0/folderINBOX/uids HTTP/1.1" 200 7056/44 0.076 17708 60% 0
SECOND CHECK (new mail shows up in Inbox):
I hope this helps. Thank you!
I just tried with SOGo 1.3.5a and dovecot 1.2.15. Everything works fine. Can you confirm?
Hey Francis. We're still on Dovecot 1.0.15 with Debian Lenny. Still have the same behavior. The Inbox count shows new mails that aren't displayed in the Inbox until a second check.
I noted Squeeze will be stable in just a few days and has Dovecot 1.2.15 -- so maybe this won't be an issue for us much longer.
What version of SOGo are you running?
Ah yes -- SOGo 1.3.5a on CentOS.
Make sure to empty your browser's cache.
Can you sniff the IMAP traffic? tcpflow does a nice job. Example :
tcpflow -i lo -c 'tcp port 143'
Any updates on this?
I emailed Francis the requested trace. I can post here if need be. Thanks!
When the problem happens, the server doesn't return the message UID during the "UID SORT" operation but does during the "UID SEARCH (UNSEEN)" operation.
This appears for me too. sogo version 1.3.5
This appears resolved for me after an upgrade to SOGo 1.6.
Still using Dovecot 1.0.15 but I don't see the issue any longer. Thanks!
|2010-08-07 17:31||cwright||New Issue|
|2010-08-07 17:31||cwright||File Added: sogo_webmail.png|
|2010-08-25 21:04||ludovic||Note Added: 0001355|
|2010-08-25 21:04||ludovic||Status||new => resolved|
|2010-08-25 21:04||ludovic||Fixed in Version||=> 1.3.2|
|2010-08-25 21:04||ludovic||Resolution||open => fixed|
|2010-08-25 21:04||ludovic||Assigned To||=> ludovic|
|2010-08-26 15:08||cwright||Note Added: 0001365|
|2010-08-26 15:08||cwright||Status||resolved => feedback|
|2010-08-26 15:08||cwright||Resolution||fixed => reopened|
|2010-11-15 18:43||cwright||Note Added: 0001817|
|2010-11-15 23:31||francis||Note Added: 0001822|
|2010-11-15 23:31||francis||Status||feedback => resolved|
|2010-11-15 23:31||francis||Resolution||reopened => fixed|
|2010-11-15 23:31||francis||Fixed in Version||1.3.2 => 1.3.4|
|2010-11-19 21:03||cwright||Note Added: 0001875|
|2010-11-19 21:03||cwright||Status||resolved => feedback|
|2010-11-19 21:03||cwright||Resolution||fixed => reopened|
|2011-02-02 17:27||francis||Note Added: 0002072|
|2011-02-02 17:59||cwright||Note Added: 0002073|
|2011-02-02 18:02||francis||Note Added: 0002074|
|2011-02-02 18:29||cwright||Note Added: 0002075|
|2011-02-02 21:26||francis||Note Added: 0002076|
|2011-02-15 22:03||ludovic||Note Added: 0002116|
|2011-02-16 01:16||cwright||Note Added: 0002119|
|2011-02-23 19:01||francis||Note Added: 0002159|
|2011-02-23 19:03||francis||Note Edited: 0002159|
|2011-03-04 06:06||Ashok||Note Added: 0002190|
|2011-04-09 19:38||cwright||Note Added: 0002358|
|2011-04-09 19:38||ludovic||Status||feedback => resolved|
|2011-04-09 19:38||ludovic||Fixed in Version||1.3.4 => 1.3.6|
|2011-04-09 19:38||ludovic||Resolution||reopened => fixed|