Bug 292418

I'll confirm this bug.  This has been a problem for quite some time now.

The 'Move to This Folder' and/or 'Copy to This Folder' options when you right click on a local or IMAP sub folder is also missing.  There appears to be no way in KMail to either create a new top level folder or move an existing folder to the top of the IMAP level.

Confirmed in KDE 4.8.0: Right click on the imap toplevel folder, there is no entry called "Add folder...".

In akonadiconsole, there is a "New folder...", but it's grayed out. So right now, there is no way to add a toplevel folder.

Related issue: bug #251704.

*** Bug 290169 has been marked as a duplicate of this bug. ***

Always actual in 4.8.1 
Could this be fixed before next updates ( If it's possible to add a folder in a folder, I assume this is a quick fix to ui, no?)

This issue is a killer for me.  I cannot consider KDE with current kmail/akonadi for general use until this is addressed. Changing and then enforcing a no top level folder policy for more then a few users is unacceptable. Every other device and application I have seen in use on my server are fine with it and use it by default. My users have a long history of working with top level folders. Educating them all just for the sake of KDE is never going to happen.

It seems to me akonadi is making assumptions about IMAP which have no basis in the standard. 

I don't know much about akonadi, however, I know enough to notice it does work fine with preexisting top level folders and doesn't seem bothered when they are created by other means. Is it really that difficult to add folder creation? This has been open far too long considering it grossly subverts the IMAP standards.

Confirmed.

I'm using a local Dovecot IMAP-Server. With Thunderbird 12 (or lower) it's possible to easily create top level folders on my Dovecot Server (Maildir-Format). With KMail (4.8.3 Release 503) it's still not possible to do that since a long time. Only the creation of subfolders in the Inbox is permitted.

It's a disaster for me. This bug forces me to use Thunderbird instead of my beloved Kmail. Hope the devs will take care.. That would be great.

Created attachment 71323 [details]
HOWTO bypass limit by using kio imap

Okay this is not a patch, but to avoid using thunderbird, or a webmail to be able to create a top folder you can always use KIO imap(s) 

open konqueror and type an uri from the style 
imaps:/username@imapserver.domain.tld 

then use F10 (create a new folder) 
et voilà :-)

Thank you, Bruno, the kio-slave is able to create top level folders. It works with my dovecot imap server, but  KMail should do the job.

m00nraker, I can't agree more. It can't be explain to end users.

Git commit 4b120f8a875fb5fa27039998ad3b8aec17a2885d by Montel Laurent.
Committed on 07/06/2012 at 13:25.
Pushed by mlaurent into branch 'master'.

Fix Bug 292418 - Kmail can't create IMAP top level folders

FIXED-IN: 4.8.5

M  +1    -1    resources/imap/retrievecollectionstask.cpp

http://commits.kde.org/kdepim-runtime/4b120f8a875fb5fa27039998ad3b8aec17a2885d

Git commit 42adead2ac77eb675e9f9c0ebde7df9368ce5f4f by Montel Laurent.
Committed on 07/06/2012 at 13:25.
Pushed by mlaurent into branch 'KDE/4.8'.

Fix Bug 292418 - Kmail can't create IMAP top level folders

FIXED-IN: 4.8.5
(cherry picked from commit 4b120f8a875fb5fa27039998ad3b8aec17a2885d)

M  +1    -1    resources/imap/retrievecollectionstask.cpp

http://commits.kde.org/kdepim-runtime/42adead2ac77eb675e9f9c0ebde7df9368ce5f4f

*** Bug 218935 has been marked as a duplicate of this bug. ***

Bug is still present in KDE 4.9.1. Not resolved. Status has to be changed...

Reopening it, as the fix:
a) doesn't work  (as it cannot work)
b) introduces a regression: if the IMAP server doesn't support ACL's with this change the INBOX will become read-only. That happens because the 

root.setRights( Akonadi::Collection::CanCreateCollection );

call on a Collection that had no previous right set explicitely actually *removes* the rights and replaces with the only set right. See 
Collection::setRights and Collection::rights.

And it doesn't work, as the default right for the collection is anyway AllRights, so doing the above call cannot fix the issue.

Laurent, I will revert the change in master and 4.9.

Git commit 6f795978a6e544ff0bead90b4bca1a0e9b127fb0 by Andras Mantia.
Committed on 29/09/2012 at 21:42.
Pushed by amantia into branch 'master'.

Revert the fix for 292418, as it causes INBOX to be read-only for servers not supporting ACLs and doesn't fix the bug.

M  +0    -1    resources/imap/retrievecollectionstask.cpp

http://commits.kde.org/kdepim-runtime/6f795978a6e544ff0bead90b4bca1a0e9b127fb0

Git commit 0a4b18e366573385aacbf168bb8164f8b486fb1d by Andras Mantia.
Committed on 29/09/2012 at 21:44.
Pushed by amantia into branch 'KDE/4.9'.

Revert the fix for 292418, as it causes INBOX to be read-only for servers not supporting ACLs and doesn't fix the bug.
(cherry picked from commit 6f795978a6e544ff0bead90b4bca1a0e9b127fb0)

M  +0    -1    resources/imap/retrievecollectionstask.cpp

http://commits.kde.org/kdepim-runtime/0a4b18e366573385aacbf168bb8164f8b486fb1d

I've just been hit by this bug too. I created a top level folder, and it shows up in my Gmail account (through the web interface), but nowhere does the folder appear in Kmail. Every time kmail logs in, an error pops up, saying "Gmail: Unknown Error. (Could not create collection <folder> resourceId: 5)".
In Kmail's local folder subscriptions list, the folder is also missing. It looks like I'll need to delete my entire local email cache to get this folder I just created.. :(
I do like kmail, but remote IMAP commands like moving emails are really buggy...

I have the same problem and my attempts to create the folder seem to be remebered somehow: Now every 5 minutes (still present after a reboot) I get the message that the folder cannot be created! 

please do something! 
thx, piedro

sry, forgot to add: this is 4.9.2 in Kubuntu 12.10 ... 64bit

The same problem as Alax Leach and Piedro, kmail 4.8.5, KDE 4.8.5 on Kubuntu 12.04. When I created a folder I got the repeating message (Unknown Error. (Could not create collection <folder> resourceId: 5), even after restarting kontact or akonadi and after reboot. I decide to remove the account and add it again to stop the messages which worked.

Also I suddenly have the folder I tried to create listed on the IMAP server.

How do this one and Bug #251704 relate to each other?
They seem to be similar enough to mark the other one a duplicate of this, even though the other one is older. This one here has the commits though.

I have the same problem as Alax Leach #c18, Piedro #c19, and Chrstiaan ter Veen #c21. I'm using KDE 4.9.3 on Kubuntu 12.10.

The folder was created. It is available on the server. It is shown in other clients. It is even shown in Akonadi Console Browser. However it is shown as empty in Akonadi Console. But it is not shown in KMail and I get flooded with the error message "Could not create collection <folder> resourceId: 5"

Same here as #23: Fully updated KDE 4.8.5 on Ubuntu 12/04. 
The folder is created and accessible fine by other clients, but the popup appears every few minutes. The resource id is higher, might be an internal number.

Starting from the command line reveals nothing of insight about what might actually be wrong.

Confirm this bug on Gentoo Linux amd64
KDE 4.10.1

I confirm this bug for 4.10.1 and a dovecot IMAP server.

What happens is the same thing as described in this forum thread: http://forum.kde.org/viewtopic.php?f=215&t=109833

New folders, like the top-level folder "Test" have a letter "i" prepended to their name in the remoteId field of akonadi's CollectionTable. The expected entry is ".Test", but what I find is "iTest".

It appears that this may have to do with this patch: https://git.reviewboard.kde.org/r/102031/ , but it looks as if it was never committed? (See the first commend on that patch discussion.)

I have a local patch for this, and will push it hopefully in time for 4.10.2.

Also confirming this bug for 4.10.1 on Archlinux with a dovecot IMAP server.

Git commit d8fd7a28e7d6d8a89dd398311d423118ff529718 by Andras Mantia.
Committed on 28/03/2013 at 22:45.
Pushed by amantia into branch 'KDE/4.10'.

1) Fix creation of new toplevel folders (and all its subfolder): it used to generate a broken remote id and separtor ("i") causing weird problems.
2) Make sure toplevel imap folders are shown immediately, without a need to sync the account (workarounds an ETM bug 291143)
3) Warn the user if creating a folder failed on server-side and remove the folder locally. Otherwise if creation failed, it was impossible to create again a folder with the same name,
as it was already a folder with that name in the akonadi cache...
4) Make sure deleting folder "foo" doesn't deleted all folders starting with "foo" as it did before.
5) Just fix folder deletion. :) It could fail in certain cases.
6) Fix and adapt the tests.

Reporters of closed bugs: if you can still see the bug in 4.10.2, please reopen and state the details.

REVIEW: 109276
FIXED-IN: 4.10.2291143291143
Related: bug 312435, bug 305269, bug 301088, bug 305987, bug 291143

M  +6    -1    resources/imap/addcollectiontask.cpp
M  +1    -1    resources/imap/changecollectiontask.cpp
M  +16   -0    resources/imap/imapresource.cpp
M  +7    -0    resources/imap/imapresource.h
M  +11   -8    resources/imap/removecollectionrecursivetask.cpp
M  +1    -0    resources/imap/removecollectionrecursivetask.h
M  +10   -0    resources/imap/resourcetask.cpp
M  +2    -0    resources/imap/resourcetask.h
M  +4    -1    resources/imap/tests/dummyresourcestate.cpp
M  +7    -5    resources/imap/tests/testremovecollectiontask.cpp

http://commits.kde.org/kdepim-runtime/d8fd7a28e7d6d8a89dd398311d423118ff529718

I'm still having what I assume is the same problem with KMail: 4.10.4
I'm running KMail on my Fedora-19/KDE laptop,
collecting email from a dovecot server on a CentOS-6.4 machine.
When I try to create a top-level folder "Spam" on my laptop
I get the message from the server (ie dovecot machine)
"alfred: Could not create collection Spam:resourceId: 13"
I see that a maildir folder ~/Maildir/.Spam/[cur,new,tmp]
is actually created on the server,
but it is not visible on the laptop KMail menu.
If I right-click on the account "alfred" on the laptop
and choose "Serverside subscriptions"
I do see the folder "Spam" listed, and ticked.
The new folder is visible with KMail on the server,
and I am able to transfer email to the folder in KMail
(always running on the server).
So the only problems are
(1) the folder is not visible on the laptop in KMail
(2) I get regular messages on my laptop as stated above
  "alfred: Could not create collection Spam:resourceId: 13"

I was slightly in error in the above comment.
The message
 "alfred: Could not create collection Spam:resourceId: 13"
did not come from my server ("alfred") but from my laptop;
the "alfred" in the message referred to the KMail account name
and resulting resource name.

Do you still want this reopened? As a KDE Developer, I can reopen it for you.

No thank you.
I am running Fedora-19/KDE on my laptop "rose",
and CentOS-6.4 on my server "alfred".
I am running a dovecot/IMAP server on alfred,
with email coming from various sources.

I find that now I can create a top-level KMail folder on alfred,
which is visible on rose (after re-booting).
This fulfils all my needs.

However, there are problems trying to create
a top-level KMail folder on my laptop.
I am apparently allowed to do this,
and if I do the folder is visible on my server,
but not on my laptop.
I receive repeated messages on my laptop
that it is unable to create a resource.
I have to delete the new folder on my server
to stop these messages.

However, as I said this is not a problem for me,
as there is a viable alternative.

Hi, i have ubuntu 13.04 laptop, clean install and kmail 4.11 and i have the sam problem with folder

in  desktop with diferente upgrade and kmail 4.11i have  same problem

I'm running Kmail 4.14.2 on Debian testing/unstable and I still have this problem. I can't create top-level folders for IMAP resources. It can be reproduced exactly as described in the bug report above, i.e.:

1. right click on the imap account name/folder and there will be no "Add folder" entry.
2. Select an imap account name/folder and then click main menu "Folder": "Add folder" is greyed out.

I work around this by creating folders in a roundcube installation that runs on the server. For what it's worth, the IMAP server is Dovecot.

I just had a go at adding top level IMAP folders in akonadiconsole, and it works fine. They show up in kmail and on the server just fine. So it really seems to be a kmail problem and not a back-end problem.

And also, for what it's worth, another recent case of somebody with the same problem: https://forum.kde.org/viewtopic.php?f=215&t=123688

Problem remains unfixed for me @ KMail 4.14.5 Arch.

I don't understand why this bug is described as "RESOLVED, FIXED", since it seems to me to be in the same unfixed state that it has been in for at least 2 years.
Neither of the 2 solutions suggested - using kio IMAP and throug akonadi console - seem to work for me.

I can create a top level folder through Akonadi console but not through Kmail.

On Monday 01 June 2015 22:27:25 you wrote:

> I can create a top level folder through Akonadi console but not through
> Kmail.

How does one do that, as a matter of interest?

Actually, the last time I tried to create a top-level folder 
with KMail on my Fedora-21 laptop I was able to. 
That was a few weeks ago,
with dovecot running on a Centos-7 server

Before CentOS-7 came out I was able to do this on the server,
with KMail, but KMail does not seem to run under CentOS-7.
It would be useful to know how to do it with Akonadi.

Open Akonadi console and click the Browser tab. Right click on the name of your email account and select New Folder. That will create a top level folder. I'm using Kmail 4.14.6 and I don't even have an option in the right click menu (grayed out or not) to make a new folder at the top level.

*** Bug 348662 has been marked as a duplicate of this bug. ***

I vote for re-opening this bug, as I have the same problem as Nick in comment #39: I can create a new top-level folder in my IMAP account (on dovecot) via the akonadi console, but not via kmail/kontakt (Kontact Version 4.14.6, Kmail version 4.14.6, Kubuntu 15.04). After creating a new folder via akonadi console, it immediately appears in kmail. So there is a workaround, but it is a bit frustrating.

I agree with  Kai Petzke; I don't think the akonadi console work-around can be considered as an answer to this bug,

Hi,

a funny observation (4.14.2, server side is dovecot 2.2.13):
After I create a new imap account, everything works. I can create folders, edit folder settings etc.
After a while (without any appearent reason), the post box loses the ability to create top level folders.

And now the funny part - if I change the *name* of the imap account, everything works again.

Hi,

a funny observation (4.14.2, server side is dovecot 2.2.13):
After I create a new imap account, everything works. I can create folders, edit folder settings etc.
After a while (without any appearent reason), the post box loses the ability to create top level folders.

And now the funny part - if I change the *name* of the imap account, everything works again.

Ack. Renaming the account in settings, kmail, accounts reinstates the new folder item in the file menu.

Kmail 4.14.6 on Ubuntu 15.04

Can also confirm that works. Very bizarre. Who knows how long it will last though :\

My KMail has stopped being able to create them again. So worked for a few weeks then broke itself.

Yep. Mine broke again after only a couple days.

Same here on Fedora 21 with kmail 4.14.9-1 and akonadi 1.13.0-16: for an IMAP account (with messages downloaded for offline use, server-side subscriptions enabled), I cannot create top level folders from kmail (the contextual menu doesn't have the option and the main menu has the option greyed out), but the creation of a folder still works fine from akonadiconsole.

The Imap server seems to be "SquirrelMail version 1.4.23".

Please reopen this bug, it is not fixed.

I agree emphatically.
Who is able to change the status of this bug to or from FIXED?
Whoever that is apparently never reads bug reports.
How old is this bug? I see from comment 1 in January 2012 that it was already old hat then.
Why is the bug so difficult to remedy? Since it can be got around by going to akonadi console it cannot be beyond human ingenuity.

This bug has been fixed, but apparently this broke again somehow.

But there's no point in reopening this bug report, there's another open one anyway.
See Bug#350219