Better support for READ-ONLY folders (possibly with ACL support?) #3108

rcubetrac opened this Issue Oct 26, 2010 · 3 comments


None yet

1 participant


Reported by brandond on 26 Oct 2010 09:04 UTC as Trac ticket #1487083

If I've got a folder that is listed by the server as READ-ONLY when selected, Roundcube does not handle this folder any differently. If I have a folder called 'Public/Read-only' that I only have list and read rights on, Roundcube lets me try to move messages into or out of the folder, or change flags on messages within the folder.

Ideally, if the server advertises the ACL capability, Roundcube would check the current user's rights to the selected folder to determine what actions should be disallowed. On servers without ACL support, all actions on the selected folder should probably be disallowed.

Here's what a read-only folder looks like:

[01:22:07 -0700](26-Oct-2010): C: A0003 SELECT Public/Read-only
[01:22:07 -0700](26-Oct-2010): S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
[01:22:07 -0700](26-Oct-2010): S: * OK [()](PERMANENTFLAGS) Read-only mailbox.
[01:22:07 -0700](26-Oct-2010): S: * 1 EXISTS
[01:22:07 -0700](26-Oct-2010): S: * 0 RECENT
[01:22:07 -0700](26-Oct-2010): S: * OK 1287825919(UIDVALIDITY) UIDs valid
[01:22:07 -0700](26-Oct-2010): S: * OK [2](UIDNEXT) Predicted next UID
[01:22:07 -0700](26-Oct-2010): S: * OK [1](HIGHESTMODSEQ) Highest
[01:22:07 -0700](26-Oct-2010): S: A0003 OK [Select completed.

Here's what happens when you try to delete a message from a folder that is read-only. Notice the lack of a FETCH response after attempting to store the DELETED flag, which Roundcube handles by throwing an error and disconnecting:

[26-Oct-2010 01:36:17 -0700](READ-ONLY]): S: A0003 OK [Select completed.
[26-Oct-2010 01:36:17 -0700](READ-ONLY]): C: A0004 FETCH 1 (UID)
[01:36:17 -0700](26-Oct-2010): S: * 1 FETCH (UID 1)
[01:36:17 -0700](26-Oct-2010): S: A0004 OK Fetch completed.
[01:36:17 -0700](26-Oct-2010): C: A0005 UID STORE 1 +FLAGS (\Deleted)
[01:36:17 -0700](26-Oct-2010): S: A0005 OK Store completed.
[01:36:17 -0700](26-Oct-2010): C: A0006 LOGOUT

Here's what happens if you try to move a message from a read-only folder to the trash. Note that unlike the immediate deletion case, there is no error displayed to the client - the message is successfully copied to the Trash, but not removed from the original folder, so it will reappear when the folder is re-selected:

[01:44:31 -0700](26-Oct-2010): C: A0004 FETCH 1 (UID)
[01:44:31 -0700](26-Oct-2010): S: * 1 FETCH (UID 1)
[01:44:31 -0700](26-Oct-2010): S: A0004 OK Fetch completed.
[01:44:31 -0700](26-Oct-2010): C: A0005 LSUB "" Trash
[01:44:31 -0700](26-Oct-2010): S: * LSUB () "/" "Trash"
[01:44:31 -0700](26-Oct-2010): S: A0005 OK Lsub completed.
[01:44:31 -0700](26-Oct-2010): C: A0006 UID STORE 1 +FLAGS (\Seen)
[01:44:31 -0700](26-Oct-2010): S: A0006 OK Store completed.
[01:44:31 -0700](26-Oct-2010): C: A0007 UID COPY 1 Trash
[01:44:31 -0700](26-Oct-2010): S: A0007 OK [1287823748 1 3](COPYUID) Copy completed.
[01:44:31 -0700](26-Oct-2010): C: A0008 UID STORE 1 +FLAGS (\Deleted)
[01:44:31 -0700](26-Oct-2010): S: A0008 OK Store completed.
[01:44:31 -0700](26-Oct-2010): C: A0009 EXPUNGE
[01:44:31 -0700](26-Oct-2010): S: A0009 OK Expunge completed.
[01:44:31 -0700](26-Oct-2010): C: A0010 SELECT Public/Read-only

I also note that for some reason the destination-folder check for the copy-to-trash action is just checking to see if the Trash folder is subscribed, which is no guarantee that it exists.

Some actions like copying messages into read-only folders currently fail with a generic "Could not copy message" error. If checking ACLs or READ-WRITE state on all subscribed folders in order to determine drag-target eligibility is too expensive, Roundcube could instead catch the 'NOPERM' error from the server and display a specific error when the copy fails. The NOPERM error looks like:

[01:59:25 -0700](26-Oct-2010): C: A0008 UID COPY 1 Public/Read-only
[01:59:25 -0700](26-Oct-2010): S: A0008 NO [NOPERM] Permission denied

The Public/Read-only folder is on the test server I set up for you, if you want to play with it there. The read-only state is done with ACLs, in case you want to work on reading rights to determine what can and cannot be done to the folder.



Milestone changed by @alecpl on 6 Dec 2010 20:21 UTC

later => 0.5-stable


Comment by @alecpl on 8 Dec 2010 12:52 UTC

Done in 90f81a6. Already without ACL support.


Status changed by @alecpl on 8 Dec 2010 12:52 UTC

new => closed

@rcubetrac rcubetrac closed this Dec 8, 2010
@rcubetrac rcubetrac added this to the 0.5-stable milestone Mar 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment