So my issue is two-fold, I have a lot of folders stored under KMail Folders, right-clicking on KMail Folders does not give me the option to create a folder. The second right-clicking on any of my existing folders, does give me the option to add a folder, but fails with the following message: "Could not create folder: Unable to append mimetype for collection test resourceid: 26" It doesn't matter where I try to add the folder (under inbox, sent, an existing folder, they all fail with the same message. When I upgraded to Debian Jessie (once it became stable), kmail ran through a lengthy migration process (which says it is 100% complete) and now I'm left without the ability to add folders. Please treat me as a complete newbie to this process. I'm more than willing to collect any additional data you may require, but will need some hand-holding (sorry in advance). Reproducible: Always Steps to Reproduce: 1. Migrate folders/emails into KMail from a prior version 2. Try to add a folder named 'test' Actual Results: Get an error with the following: "Could not create folder: Unable to append mimetype for collection test resourceid: 26" Expected Results: Folder to be created
Is there anything more I can provide anyone? Or if the solution is to wipe out your .KDE folder so it creates a new one, that'd be fine and all if I can have a way to re-import my existing emails, accounts, and filters.
I can reproduce this behavior on two Debian / Jessie systems. A workaround for this is to open akonadiconsole -> browser tab, select KMail Folders, rightclick->Folder Properties and add the Item Access Rights Create, Modify, Delete which were missing before. Afterwards creating the folder is possible again.
I too have this problem on Debian Jessie. The workaround that has was suggested in Comment 2 (to add the "Create" item in akonadiconsole -> browser tab, select KMail Folders, rightclick->Folder Properties -> Item Access Rights ) does work, but only until KMail is closed. When KMail is started for the 2nd time, the workaround fails because that setting in akonadiconsole has been re-set to its default state of no Item Access Rights, as per the message on that dialog: "These values are provided by the corresponding backend and not intended to be changed by you ...." So the obvious fix is to get the "corresponding backend" to turn "Create" on as one of the Item Access Rights (instead of turning it off). My guess is that the default has been set to "no folder creation at top level" because when it is allowed, a different context menu is being used that includes not only Add Folder, but also Delete Folder (regardless of whether Delete has been selected as an Item Access Right). This looks a bit dangerous at top level. In summary, the previously suggested workaround is not useful, and this still needs to be fixed.
This bug has never been confirmed for a Kontact version that is based on KDE Frameworks, except possibly a Technology Preview version 5.0.x. Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the opportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.