Bug 185785 - KMail tries to annotate a read only folder
Summary: KMail tries to annotate a read only folder
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: commands and actions (show other bugs)
Version: 4.9 pre
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-28 11:11 UTC by Thomas Zander
Modified: 2012-10-18 07:13 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Zander 2009-02-28 11:11:35 UTC
Version:           1.11.1 (using 4.2.00 (KDE 4.2.0), compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.26-1-686

I have some read-only folders (lrsa) on my imap server (cyrus) and every time I use disconnected imap to sync I get one warning per folder;

=====
Error while setting annotation: 

Setting the annotation /vendor/kolab/folder-type on folder imaps://zander@namlook:993/shared/  failed. The server returned: Permission denied
========

I don't think kmail should try to annotate a read only folder.
Comment 1 Jeroen van Meeuwen (Kolab Systems) 2012-06-08 13:50:05 UTC
You're right - it shouldn't.

However, the folder isn't entirely read-only - you seem to have 'admin' rights. Regrettably, 'admin' rights do not imply 'the other rights' which would still need to be set explicitely (by an admin).

Christian, I feel I have confirmed before this is no longer an issue in current KDE, but I would appreciate your confirmation.
Comment 2 Christian Mollekopf 2012-06-18 21:32:14 UTC
Note sure why you got in that situation in the first place (I couldn't find the relevant codepath), but I don't think it can happen with the current kolab resource.

Once an annotation has been erroneously set on a akonadi-collection without modify rights though, the imap resource indeed tries on every sync to write it to the server.
I'm not quite sure yet though how to resolve that in the imap resource(if at all) .

As a workaround you can delete the annotation using akonadiconsole:
Browser Tab -> Rightclick -> Folderproperties -> Attributes tab -> edit the folderannotations.

The admin rights do not play into the behaviour, it's just that ACL rights in akonadi are not enforced and clients need to check themselves (which the kolab resource obviously didn't).
Comment 3 Thomas Zander 2012-10-18 07:13:33 UTC
Lets close this one now :)