Bug 292418 - Kmail can't create IMAP top level folders
Summary: Kmail can't create IMAP top level folders
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Unclassified
Component: general (show other bugs)
Version: Git (master)
Platform: Fedora RPMs Linux
: NOR major with 120 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 218935 290169 348662 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-25 22:38 UTC by Marco Vittorini Orgeas
Modified: 2016-05-10 08:55 UTC (History)
37 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10.2


Attachments
HOWTO bypass limit by using kio imap (279.25 KB, image/jpeg)
2012-05-23 14:26 UTC, Bruno Friedmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Vittorini Orgeas 2012-01-25 22:38:55 UTC
Version:           4.7 (using KDE 4.7.4) 
OS:                Linux

Simple as in subject: Kmail can't create IMAP top level folders.

Try to right click on the imap account name/folder and there will be no "Add folder" entry.

Select an imap account name/folder and then click main menu "Folder": "Add folder" is greyed out.

Reproducible: Always

Steps to Reproduce:
right click on the imap account name/folder and there will be no "Add folder" entry.

Select an imap account name/folder and then click main menu "Folder": "Add folder" is greyed out.


Expected Results:  
To find a way to create top level IMAP folders!

I've select Major severity: even if there's no data loss, this issue severely prevents normal work with imap accounts!
Comment 1 lnxusr 2012-01-26 01:06:09 UTC
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.
Comment 2 Dominik Haumann 2012-01-29 11:47:45 UTC
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.
Comment 3 Dominik Haumann 2012-01-29 11:50:26 UTC
Related issue: bug #251704.
Comment 4 Dominik Haumann 2012-01-29 11:57:14 UTC
*** Bug 290169 has been marked as a duplicate of this bug. ***
Comment 5 Bruno Friedmann 2012-03-21 16:38:50 UTC
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?)
Comment 6 Jon Skanes 2012-04-14 21:44:28 UTC
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.
Comment 7 m00nraker 2012-05-21 11:10:12 UTC
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.
Comment 8 Bruno Friedmann 2012-05-23 14:26:26 UTC
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à :-)
Comment 9 m00nraker 2012-05-24 10:00:03 UTC
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.
Comment 10 Bruno Friedmann 2012-05-25 16:59:30 UTC
m00nraker, I can't agree more. It can't be explain to end users.
Comment 11 Laurent Montel 2012-06-07 11:25:57 UTC
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
Comment 12 Laurent Montel 2012-06-07 11:26:30 UTC
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
Comment 13 Christian Mollekopf 2012-06-18 18:02:55 UTC
*** Bug 218935 has been marked as a duplicate of this bug. ***
Comment 14 m00nraker 2012-09-19 08:09:36 UTC
Bug is still present in KDE 4.9.1. Not resolved. Status has to be changed...
Comment 15 András Manţia 2012-09-29 19:39:46 UTC
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.
Comment 16 András Manţia 2012-09-29 19:43:05 UTC
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
Comment 17 András Manţia 2012-09-29 19:44:15 UTC
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
Comment 18 Alex Leach 2012-10-09 09:56:57 UTC
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...
Comment 19 piedro 2012-10-26 11:23:16 UTC
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
Comment 20 piedro 2012-10-26 11:25:22 UTC
sry, forgot to add: this is 4.9.2 in Kubuntu 12.10 ... 64bit
Comment 21 Christiaan ter Veen 2012-10-28 09:05:51 UTC
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.
Comment 22 Bernd Oliver Sünderhauf 2012-11-28 20:33:53 UTC
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.
Comment 23 Rüdiger 2012-12-29 08:30:26 UTC
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"
Comment 24 Tom Chiverton 2013-02-21 20:04:20 UTC
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.
Comment 25 Andrey 2013-03-11 00:11:36 UTC
Confirm this bug on Gentoo Linux amd64
KDE 4.10.1
Comment 26 Michael Büker 2013-03-18 18:49:48 UTC
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.)
Comment 27 András Manţia 2013-03-19 08:06:15 UTC
I have a local patch for this, and will push it hopefully in time for 4.10.2.
Comment 28 Mark Constable 2013-03-21 07:54:14 UTC
Also confirming this bug for 4.10.1 on Archlinux with a dovecot IMAP server.
Comment 29 András Manţia 2013-03-28 21:45:46 UTC
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
Comment 30 Timothy Murphy 2013-07-15 11:50:53 UTC
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"
Comment 31 Timothy Murphy 2013-07-15 16:23:33 UTC
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.
Comment 32 Kevin Kofler 2013-08-12 00:31:28 UTC
Do you still want this reopened? As a KDE Developer, I can reopen it for you.
Comment 33 Timothy Murphy 2013-08-12 10:18:21 UTC
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.
Comment 34 Alejandro G Sánchez Martínez 2013-09-28 02:29:40 UTC
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
Comment 35 Shane 2015-02-21 12:47:23 UTC
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.
Comment 36 Shane 2015-02-21 13:21:59 UTC
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
Comment 37 Florian Lindner 2015-02-21 18:48:10 UTC
Problem remains unfixed for me @ KMail 4.14.5 Arch.
Comment 38 Timothy Murphy 2015-04-06 00:13:41 UTC
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.
Comment 39 Nick 2015-06-01 22:27:25 UTC
I can create a top level folder through Akonadi console but not through Kmail.
Comment 40 Timothy Murphy 2015-06-02 01:12:48 UTC
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.
Comment 41 Nick 2015-06-02 02:20:54 UTC
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.
Comment 42 Laurent Montel 2015-06-04 07:13:47 UTC
*** Bug 348662 has been marked as a duplicate of this bug. ***
Comment 43 Kai Petzke 2015-07-18 16:07:18 UTC
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.
Comment 44 Timothy Murphy 2015-07-18 22:36:56 UTC
I agree with  Kai Petzke; I don't think the akonadi console work-around can be considered as an answer to this bug,
Comment 45 dietz 2015-08-05 09:20:44 UTC
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.
Comment 46 dietz 2015-08-05 09:21:24 UTC
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.
Comment 47 Tom Chiverton 2015-08-05 18:32:50 UTC
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
Comment 48 Nick 2015-08-05 20:53:33 UTC
Can also confirm that works. Very bizarre. Who knows how long it will last though :\
Comment 49 Tom Chiverton 2015-08-16 11:44:26 UTC
My KMail has stopped being able to create them again. So worked for a few weeks then broke itself.
Comment 50 Nick 2015-08-16 18:58:25 UTC
Yep. Mine broke again after only a couple days.
Comment 51 Éric Brunet 2015-09-10 09:12:20 UTC
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.
Comment 52 Timothy Murphy 2015-09-10 09:53:07 UTC
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.
Comment 53 Wolfgang Bauer 2015-09-11 13:37:16 UTC
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