Try to right click on the imap account name/folder and there will be no "Add folder" entry. Reproducible: Always Steps to Reproduce: Try to right click on the imap account name/folder and there will be no "Add folder" entry. Actual Results: No add folder entry Expected Results: Add folder entry
Can confirm. You can actually create a top level folder though Akonadi Console. Also if you rename the account in Kmail it will work for a short period of time before breaking again.
Ack, Kubuntu 15.04
This one is a duplicate of https://bugs.kde.org/show_bug.cgi?id=292418 Let redo the work here if it's what devs want. The status is over over over confirmed, and has nothing to do with kubuntu package, this bug is availiable in almost all flavor of linux distribution. openSUSE, fedora, debian, kubuntu, arch linux etc ...
That one is closed as fixed and it doesn't look like anyone is going to reopen it.
I don't understand why the same bug was marked as FIXED, and now a new bug report has been opened concerning exactly the same problem. The statement that the bug was FIXED is manifestly false, since there are reports virtually every month since January 2012 confirming the problem. Also if the problem cannot be solved, the akonadi console workaround should be made available to KMail users, eg by adding it to the KMail Handbook.
I can confirm this bug for Kubuntu 15.04. The workaround using the akonadi console is somewhat useable, but this bug should be fixed, nonetheless.
Confirmed on Arch After a fresh install It was functioning for some hours. I this short time I succeeded in adding several top level folders. However that was yesterday. Today the functionality has strangly dissapeared and I am no longer able to add top level folders. Very dissapointed. This is very important to me. Something in the background is clearly messing things up. I suspect akonadi and or its database. Previously I could not add top level folders and somehow my sql database was getting errors. I cleaned up by deleteing the sql database and removing the akonadi folder in my home dir forcing akonadi to recreate everything. After this, to my delight, the ability to add top level folders returned. The joy was however short lived. It has gone again and I'm not going to hose my database every time I want to add a folder. Please change the status of this bug to confirmed. Considering the impact of this bug on kmails overall usability, it should, in my opinion, be considered high priority. KMail 5.0.1 KDE Frameworks 5.14.0 Qt 5.5.0 (built against 5.5.0) The xcb windowing system 4.2.2-1-ARCH akonadi 15.08.1-1
Same on openSUSE Tumbleweed, but KMail version 4.14.10 Platform Version 4.14.14 Qt4 4.8.7 (Qt5Core 5.5.1) I also, as added fun, suddenly can't access my Inbox anymore. It has disappeared from my favorites and is greyed out. This started, like, 1 minute ago, I was just doing a search and replied to an email.
*** This bug has been confirmed by popular vote. ***
Still true with a dovecot 2.2 imap serveur ( roundcube and thunderbird work well in this use case) Kmail Using: 5.2.2 KDE Frameworks 5.23.0 Qt 5.6.1 (built against 5.6.1) The xcb windowing system Should we increase the version in the bug report ?
Yes, you should bump the version to the latest to try and get some traction. For what it is worth, Kontact 5.1.3 in Kubuntu 16.04 LTS still has this critical bug.
Even 5.2.3 on openSUSE TW has still this trouble.
Confirmed. New manually created dovecot maildir folder doesn't appear either, regardless what I try.
(In reply to Juha Tuomala from comment #13) > Confirmed. New manually created dovecot maildir folder doesn't appear > either, regardless what I try. I can't create top-level IMAP folders either (KMail 5.3.0). If I create the folder in another e-mail client, it doesn't appear immediately in KMail (even if in the "Manage Local Subscriptions" dialog). However, going offline via File->Work Offline and then back online again makes the new folders visible.
Same effect on Gentoo, kmail 5.4.1 New top-level IMAP folders cannot be created in kmail / kontact. Creating one in akonadiconsole works fine. Updating the bug data to show it's still current / applicable
(In reply to Andreas K. Huettel from comment #15) > What |Removed |Added > ---------------------------------------------------------------------------- > Version|5.1.3 |5.4.1 > > Updating the bug data to show it's still current / applicable Does it not make more sense for the version field to list the *earliest* known version in which the bug occurs?
I think it's important to keep bumping the version so KDE know it's an issue in latest version. Still broken in KMail 5.2.3 from KDE backports (http://www.kubuntu.org/news/plasma-bugfix-releases-frameworks-selected-app-updates-now-available-in-backports-ppa-for-zesty-and-xenial/)
(In reply to Tom Chiverton from comment #17) > I think it's important to keep bumping the version so KDE know it's an issue > in latest version. That will make it harder for the developers to narrow down which commit introduced the bug. If you know a feature was working in version x, and not working any more in version y, then one way of finding the cause of the bug is to review code that changed in the last (y-x) versions. Keeping y low is therefore of great benefit. If you want to confirm that an issue hasn't yet been fixed, why not just post a comment?
There's no need to keep the version number low to help find the issue by giving the first breaking version. We already found the problematic commit *3 years ago* : https://bugs.kde.org/show_bug.cgi?id=339576#c3 The problem is getting anyone at KDE to notice that a core feature of a flag ship part of the suite is broken. And has been for years. Saying it's a bug in the latest version helps there I think.
Fixed by today's KDE Neon update to KDE 17.04.2
Definitely not fixed in 17.04.2, symptoms remain exactly the same.
Ack. Now broken again. Kmail 4:17.04.2-0neon+16.04+xenial+build21
Confirmed I can't add a top level folder with kmail-17.04.1-3.fc26.x86_64 (server cyrus-imapd-3.0.2-4.fc26.x86_64)
Git commit 97a191a5df7b307c70e662996c4846d3d586ff61 by Daniel Vrátil. Committed on 08/09/2017 at 15:09. Pushed by dvratil into branch 'Applications/17.08'. LIST: correctly return mimetypes for all Collections LIST was only returning mimetypes for Collections that were resolved in the initial filter pass. All Collections that were resolved in the second pass to complete the tree were missing mimetypes, because their IDs were not passed to the mimetype query. This in included mainly Collections that don't match the initial mimetype filter, like top-level Collections. This caused, among other things, KMail to refuse to create Collections under the top-level Collection, because the top-level Collections did not match KMail's mimetype filter (inode/directory). FIXED-IN: 5.6.2 M +1 -0 src/server/handler/list.cpp https://commits.kde.org/akonadi/97a191a5df7b307c70e662996c4846d3d586ff61
Did this make Neon 17.08.1 ?