Not sure if you consider this to be a bug, but at the very least I feel like it
an undesirable feature...
Using the latest ZCO build (ZimbraConnectorOLK_184.108.40.20656_x86.msi) with Outlook
2007 SP3, I created shared folders (have tried calendars and contacts so far). I assigned permissions to another Zimbra user who is also running the same version of Outlook and ZCO, giving them "Reviewer" status. They cannot alter the items, nor the shared folders (as expected). However, if I change them to a "Delegate", the can modify the items (again, expected)...BUT THEY CAN ALSO DELETE THE SHARED FOLDERS (not expected)!
The deleted items (and folders) cannot be restored using the "Recover Deleted Items" feature of the webmail client (even though they appear in my listing of "recoverable deleted items", nothing happens when I attempt to recover them).
Am I overlooking a subtle permission issue/option here, or is this otherwise a
desired design feature? Shouldn't the deletion of the shared folder itself only be allowed for an "Administrator" role?
I submitted a ticket to Zimbra Support. As a response, I am being told that this is by design.
If that is the case, then I feel there should be a permission level added in a
future update that is “higher” than Reviewer, and “lower” than “Delegate”.
If the user is a Reviewer, they CANNOT add/edit/delete individual items within
the shared folder (which I agree with). If the user is a Delegate, they CAN add/edit/delete individual ITEMS (which is good), but they can ALSO delete the SHARED FOLDER (which is BAD…I feel only the Administrator rights should allow that ability!).
I propose a new permission level that is in between the two, such as “Editor”: Can create/edit/delete ITEMS inside a shared folder, BUT cannot
edit/delete the SHARED FOLDER itself!
My users have already caused problems because they “accidentally” deleted
or moved the shared folder (they cannot simply be Reviewers, because they need to update shared calendar and contact items…so I must make them Delegates at the present time).
Thank you for this consideration. Please add this feature request to the