Bug 295478

Summary:	IMAP Folder properties suddenly not accessible
Product:	[Applications] kmail2	Reporter:	itsef-admin
Component:	folders	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	korossy, mkay, silver.salonen
Priority:	NOR
Version:	4.8
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description itsef-admin 2012-03-07 16:28:14 UTC

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build Identifier:

One of our users reported that he can no longer access the "properties" dialogue for two of his (disconnected) IMAP folders.

Reproducible: Couldn't Reproduce

Actual Results:
When right-clicking on the folders in question, the context menu is missing the "Folder properties" completely. Also, "Move folder to trash", "Assign shortcut" and "archive" are greyed out and the menu is shorter than normal (haven't checked what else is missing). The same goes for the "Folder" menu from the menubar.

Tried with Kubuntu 11.10 and Kubuntu-ppa 4.8.1 packages.
The problem was detected after the upgrade from 4.8.0 to 4.8.1, but it is not certain that it did not exist earlier.
Overall, two folders are affected. Both folders were working normally right after the account was initially added to KMail2. Both folders have several subfolders and also contain mail themselves.

I have tried the following (without success) to regain access to the properties dialogue:
- Serverside unsubscribe and re-subscribe - this resulted in the folders becoming completely inaccessible (i.e. subfolders still listed, but no mails could be added or deleted in the folder itself)
- Delete the account in question plus the corresponding akonadi DBs and re-add it to KMail. After this, the folders were accessible again - but still no properties dialogue

I have also used akonadiconsole to try and gain more information. In akonadiconsole, I was able to access the folder properties without problems.
The ACL on the IMAP server (Cyrus) are the same as for all other folders, so that should not be a problem, either.

Comment 1 Silver Salonen 2012-03-13 13:42:20 UTC

I have 2 IMAP-accounts in KMail and one of the accounts is set to use non-default identity. It works OK for most of the folders, but when I start sending a message (or reply to a message from that folder) on this particular folder which properties cannot be opened, my default identity is used (incorrectly).

Comment 2 itsef-admin 2012-03-13 14:25:25 UTC

We have just tried the following:

1) Create a new folder ARCHIVE2 under INBOX in KMail
2) Verify that the properties are accessible
3) On the IMAP server, copy all subfolders from one of the faulty folders into the newly created one and let Cyrus rebuild all necessary indexes (reason we did this on the server rather than in KMail: Performance plus KMail tends to crash frequently when moving IMAP folders)
4) In KMail, subscribe to all new subfolders of ARCHIVE2

Shortly thereafter, the properties of ARCHIVE2 became inaccessible again. What's worse: We use "Properties -> Retrieval" to set the ARCHIVE folder plus all subfolders to "never update" in order to improve performance. With the folders where the properties vanish, this inheritance no longer works and the subfolders are still updated each mailcheck, causing a huge performance drain.

Comment 3 mkay 2012-04-01 23:37:40 UTC

i have the same problem with normal, local folders (i'm using pop3 and store mail locally), so it's not related with imap. additionaly the 'next/previous unread mail'  buttons and greyed out and keyboard shortcuts for that actions deos not work....
here's a screenshot of 'broken' folder: http://mkay.luminos.pl/kmail/kmail_2a.jpg

Comment 4 Denis Kurz 2016-09-24 18:08:02 UTC

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.

Comment 5 Denis Kurz 2017-01-07 22:51:03 UTC

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.