I have a remote IMAP server that goes offline each night. So the IMAP resource goes offline as well. However in previous versions of KDE when the IMAP server is back online, the offline status in KMail goes back to online without any user action. Now I have to manually set the resource online again by selecting a folder, pressing F5 and selecting Yes or pressing Return. Reproducible: Always Steps to Reproduce: 1. Observe the online status of the IMAP resource 2. Stop the server. 3. Observe the offline status. 4. Start the server again. Actual Results: 5. The IMAP resource stays offline. Expected Results: 5. After some time, i.e. the time set to fetch new mail from this resource, the status should go back to online without user interaction.
Same here. In place of the message body can be seen a "KMail is currently in offline mode. Click <here> to go online . . ." notification but "Work offline" option in File menu means that KMail is not in offline mode. Clicking on the link <here> nothing happens, switching Kmail off- then online in File menu helps.
The situation has become worth in 4.9.4. Now the Mailbox does not show the status Offline anymore and applying Update Maps and Sub maps apparently does nothing. I have to log off and on again to get to the waiting messages in the IMAP account.
Same problem here, actually with KDE 4.9.4, openSUSE, but observable since KDE 4.7 or so. When I lose connection (turn off wifi, ...), KMail IMAP accounts go off-line. When I'm back on-line, those accounts do not get on-line automatically, I have to turn the on manually.
But with 4.9.4 I am unable to turn it on manually. I have to log off and log on again. So I raised the importance to high.
I wonder if this was caused by my fix that made sure resources stay offline, even if the network comes back, if they were requested prior to stay offline by the user (KMail's File->Work Offline). I will do a check later.
Addition: my change affects only 4.9.4, and I just saw it was also there before, but neverthless I will check. Offline state handling needs a rework as you can see here: http://lists.kde.org/?l=kde-pim&m=135473779707637&w=2
The effect is still visible in 4.10.2.
Recently I learned that akonadi logs to .xsession-errors ... and found the following lines multiple times in a row (sometimes hundreds of them): "Cannot connect to agent instance with identifier 'akonadi_imap_resource_2', error message: 'Could not get owner of name 'org.freedesktop.Akonadi.Resource.akonadi_imap_resource_2': no such name'" I don't know whether this is related to the bug. At least I can say that this error message occurs in the log when it happens. Looking into akonadiconsole, I found that sometimes the current activity of the respective resource is stalled. For example "Getting additional folder information ...". Also this seems to be related to the error message above.
This bug is most certainly related to bug #315382. More precisely, this behaviour is observed coincidently by our admin whenever I get these errors at the client side. Please help, he starts to get angry about my mail client;)
I use KDE 4.10.3 currently and have 2 IMAP accounts: (1) on GMail (2) on my own server When I lose network connectivity (unplug Ethernet cable or wake up from suspend), (1) goes offline and never comes back from it until do it manually. (2) never goes offline, it displays syncing status in account properties. As a workaround I ticked 2 boxes for (2): 1. "Switch offline on KMail shutdown" 2. Check mail on startup. This way I only have to restart KMail to get (2) back online. I don't have to do "akonadictl restart" or re-login into KDE.
Another work around is to cancel the stalled connection, which can be seen right below in the status bar by pressing the blue up arrow, which changes in a blue down arrow and above it shows the stalled connection and press the cancel icon. After that you can press on the inbox of GMail and new messages will be fetched.
The IMAP resource has a new maintainer, reassigning to him.
This should work now in 4.13 (it retries after the specified sync interval, or 5 minutes if set to sync manually).