Summary: | Can't add a local folder in kmail | ||
---|---|---|---|
Product: | [Applications] kmail2 | Reporter: | cpradio <forums> |
Component: | folders | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | ahn567, tobias |
Priority: | NOR | ||
Version: | 4.14.1 | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
cpradio
2015-05-09 17:16:16 UTC
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. |