View Issue Details

IDProjectCategoryView StatusLast Update
0005009SOGoWeb Mailpublic2020-05-15 15:57
Reporterfsoyer Assigned To 
Status newResolutionopen 
Platform[Server] LinuxOSUbuntuOS Version16.04 LTS
Product Version4.3.0 
Summary0005009: Threads for mail do not colapse/expand after a while + colorization on Chrome/Chromium (linux)

First, sorry if this issue was already posted, I have not found a search functionality in this new interface of bug tracker :(

  1. As described, threads for mail do not colapse/expand after a while. The first time or after a refresh (F5), the colapse/expand functionality works, but if I change tab, then come back to sogo tab after some times, it's broken. Clicking on the number does nothing, do not colapse an expanded thread nor expand a colapsed one (am I clear ? I hope). Refreshing (F5) solves the issue, but it's not usable as this... Cleaning datas on browsers doesn't solve the thing.
    Sogo 4.3.0 is installed on a CentOS 7 server, with yum.
    Tested locally on Chromium and Chrome 79 linux (Mint 18), Firefox 70 linux, and Chrome 80 on Windows : same behavior.

  2. Another thing : I have no colorization of the thread, and no indentation, on Chromium and Chrome linux. It's OK on Firefox linux and Chrome Windows. An idea ?


Steps To Reproduce

Launch Sogo web mail on some browsers

TagsNo tags attached.




2020-05-10 17:21

reporter   ~0014318

Same bug found in build from sogo rpm repo.

Christian Mack

Christian Mack

2020-05-11 09:03

developer   ~0014322

Do you run into session timeout?
Which value do you use in /etc/cron.d/sogo after "expire-sessions"?
What have you set for SOGoRefreshViewCheck in sogo.conf?



2020-05-11 09:11

reporter   ~0014323

how can I see if I run into session timeout ? In log ? In the webui I see no deconnection nor timeout.
In /etc/cron.d/sogo, only one line is uncommented :
0 0 * sogo /usr/sbin/sogo-tool update-autoreply -p /etc/sogo/sieve.creds

and I have no parameter "SOGoRefreshViewCheck" in sogo.conf. Does it have a default value ?

Christian Mack

Christian Mack

2020-05-11 09:25

developer   ~0014324

When sessions expire, you usually get prompted for login credentials after clicking on a button or list item.
But some functions fail silently, like screen refresh.
As your "expire-sessions" command is disabled, you do have infinite sessions, which means they never expire.
Which also means, that a user only needs to login one time, then never again.

Sessions are stored in database table set with OCSSessionsFolderURL.
But you can not see who has which session anywhere.

"SOGoRefreshViewCheck" defaults to "manually", which means never, until a user presses the refresh button.
I would suggest to change that to something sensible, like "every_10_minutes".
Available values can be found at



2020-05-12 15:27

administrator   ~0014332

Do you see any error in your Javascript console?



2020-05-15 15:57

reporter   ~0014342

sorry I was not at office this last days. I added SOGoRefreshViewCheck with "every_5_minutes", restarted Sogo, refreshed in my browser.
After about one minute, the threads was blocked as there are (collapsed, or expanded). I wait more than 5 minutes : not better.
I saw no js error in Chromium dev tools.

BUT, I discovered a behavior that I didn't detect before. In fact, not all threads was blocked. I find threads working in those who were not one the screen (lower in the folder). Then, returning on top of my folder... The blocked one work again !?
I can now confirm that : the threads blocked ARE ONLY THOSE AT SCREEN. Navigating in the folder (do the blocked threads disappear from screen) then returning to them fix the bug :/

Issue History

Date Modified Username Field Change
2020-04-22 09:32 fsoyer New Issue
2020-05-10 17:21 fsoyer Note Added: 0014318
2020-05-11 09:03 Christian Mack Note Added: 0014322
2020-05-11 09:11 fsoyer Note Added: 0014323
2020-05-11 09:25 Christian Mack Note Added: 0014324
2020-05-12 15:27 francis Note Added: 0014332
2020-05-15 15:57 fsoyer Note Added: 0014342