Change Details

cyrus-imapd.x86_64 2.5.8-13.1.el6.kolab_14 roundcubemail.noarch 1.1.5.21-1.1.el6.kolab_14 roundcubemail-plugins-kolab.noarch 3.2.15-4.1.el6.kolab_14 In our setup we discovered that if users are disributed over different backends the delete behavior doesn't work as expected. Let's say we got three users: ``` User1 on backend1 User2 on backend1 User3 on backend2 ``` Now User1 Creates a Folder ```MyPublicReadOnlyFolder``` moves some mails into this folder and grants ReadOnly permissions to User2 and User3. Now the following happens when both User2 and User3 each 1. goto settings -> folders 2. subscribe to User1->MyPublicReadOnlyFolder 3. goto E-Mail -> User1->MyPublicReadOnlyFolder 4. select one of the mails listend 5. hit delete key (on keyboard) a) User2 is logged in 6. roundcube shows the permission/action denied message and stops the delete 7. click F5 to refresh 8. the selected mail was visible before the F5 and is still visible in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicReadOnlyFolder was not copied/moved here b) User3 is logged in 6. roundcube copies the item to User3->Trash and delists it from the GUI 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected but false the mail of User1->MyPublicReadOnlyFolder was copied here Here 6. and 10. for User3 are not working correctly. The second and as we think related or same problem is: Now User1 Creates a Folder ```MyPublicPermitDeleteFolder``` moves some mails into this folder and grants Read&Delete permissions to User2 and User3. Now the following happens when both User2 and User3 each 1. goto settings -> folders 2. subscribe to User1->MyPublicPermitDeleteFolder 3. goto E-Mail -> User1->MyPublicPermitDeleteFolder 4. select one of the mails listend 5. hit delete key (on keyboard) a) User2 is logged in 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail removed from th elist before the F5 and that's how it stays 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder was moved here b) User3 is logged in 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicPermitDeleteFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder now available here too, but it was copied Here 8. and 10. for User3 are not working correctly. If delete is permitted to User3 and he uses shift+del, the mail is realy removed (as the ACL permits) but not available in any trash folder (what is expected by shift+del). So it seams to be a problem with moving and determining correct ACL over different IMAP backends here. We tested this with about a douzent users and can reproduce the behavior with our four avaliable backends by 100%.

cyrus-imapd.x86_64 2.5.8-13.1.el6.kolab_14 roundcubemail.noarch 1.1.5.21-1.1.el6.kolab_14 roundcubemail-plugins-kolab.noarch 3.2.15-4.1.el6.kolab_14 In our setup we discovered that if users are disributed over different backends the delete behavior doesn't work as expected. Let's say we got three users: ``` User1 on backend1 User2 on backend1 User3 on backend2 ``` Now User1 Creates a Folder ```MyPublicReadOnlyFolder``` moves some mails into this folder and grants ReadOnly permissions to User2 and User3. Now the following happens when both User2 and User3 each ``` 1. goto settings -> folders 2. subscribe to User1->MyPublicReadOnlyFolder 3. goto E-Mail -> User1->MyPublicReadOnlyFolder 4. select one of the mails listend 5. hit delete key (on keyboard) ``` a) User2 is logged in ``` 6. roundcube shows the permission/action denied message and stops the delete 7. click F5 to refresh 8. the selected mail was visible before the F5 and is still visible in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicReadOnlyFolder was not copied/moved here ``` b) User3 is logged in ``` 6. roundcube copies the item to User3->Trash and delists it from the GUI 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected but false the mail of User1->MyPublicReadOnlyFolder was copied here ``` Here 6. and 10. for User3 are not working correctly. The second and as we think related or same problem is: Now User1 Creates a Folder ```MyPublicPermitDeleteFolder``` moves some mails into this folder and grants Read&Delete permissions to User2 and User3. Now the following happens when both User2 and User3 each ``` 1. goto settings -> folders 2. subscribe to User1->MyPublicPermitDeleteFolder 3. goto E-Mail -> User1->MyPublicPermitDeleteFolder 4. select one of the mails listend 5. hit delete key (on keyboard) ``` a) User2 is logged in ``` 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail removed from th elist before the F5 and that's how it stays 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder was moved here ``` b) User3 is logged in ``` 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicPermitDeleteFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder now available here too, but it was copied ``` Here 8. and 10. for User3 are not working correctly. If delete is permitted to User3 and he uses shift+del, the mail is realy removed (as the ACL permits) but not available in any trash folder (what is expected by shift+del). So it seams to be a problem with moving and determining correct ACL over different IMAP backends here. We tested this with about a douzent users and can reproduce the behavior with our four avaliable backends by 100%.

cyrus-imapd.x86_64 2.5.8-13.1.el6.kolab_14 roundcubemail.noarch 1.1.5.21-1.1.el6.kolab_14 roundcubemail-plugins-kolab.noarch 3.2.15-4.1.el6.kolab_14 In our setup we discovered that if users are disributed over different backends the delete behavior doesn't work as expected. Let's say we got three users: ``` User1 on backend1 User2 on backend1 User3 on backend2 ``` Now User1 Creates a Folder ```MyPublicReadOnlyFolder``` moves some mails into this folder and grants ReadOnly permissions to User2 and User3. Now the following happens when both User2 and User3 each ``` 1. goto settings -> folders 2. subscribe to User1->MyPublicReadOnlyFolder 3. goto E-Mail -> User1->MyPublicReadOnlyFolder 4. select one of the mails listend 5. hit delete key (on keyboard) ``` a) User2 is logged in ``` 6. roundcube shows the permission/action denied message and stops the delete 7. click F5 to refresh 8. the selected mail was visible before the F5 and is still visible in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicReadOnlyFolder was not copied/moved here ``` b) User3 is logged in ``` 6. roundcube copies the item to User3->Trash and delists it from the GUI 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicReadOnlyFolder 9. check User2->Trash folder 10. as expected but false the mail of User1->MyPublicReadOnlyFolder was copied here ``` Here 6. and 10. for User3 are not working correctly. The second and as we think related or same problem is: Now User1 Creates a Folder ```MyPublicPermitDeleteFolder``` moves some mails into this folder and grants Read&Delete permissions to User2 and User3. Now the following happens when both User2 and User3 each ``` 1. goto settings -> folders 2. subscribe to User1->MyPublicPermitDeleteFolder 3. goto E-Mail -> User1->MyPublicPermitDeleteFolder 4. select one of the mails listend 5. hit delete key (on keyboard) ``` a) User2 is logged in ``` 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail removed from th elist before the F5 and that's how it stays 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder was moved here ``` b) User3 is logged in ``` 6. roundcube performs the delete and shows a success message 7. click F5 to refresh 8. the selected mail was not visible before the F5 but comes back now, because it's still in User1->MyPublicPermitDeleteFolder 9. check User2->Trash folder 10. as expected the mail of User1->MyPublicPermitDeleteFolder now available here too, but it was copied ``` Here 8. and 10. for User3 are not working correctly. If delete is permitted to User3 and he uses shift+del, the mail is realy removed (as the ACL permits) but not available in any trash folder (what is expected by shift+del). So it seams to be a problem with moving and determining correct ACL over different IMAP backends here. We tested this with about a douzent users and can reproduce the behavior with our four avaliable backends by 100%.