Zimbra 5.0 Beta 3 - User-definable expiration policy

[soxfan]

I've been doing some testing on the Zimbra 5.0 Beta 3 release. One of the new features that caught my eye was the following (from the release notes):

13435 - Users can configure when mail in their mailbox system folders-
Inbox, Sent, Junk, and Trash, should be deleted. This is done in their
Preferences, Mail tab (previously called Options tab).

I've played around with this a bit, and while I like the idea, there are a few things about the current implementation at least that I didn't like:
1) There doesn't appear to be any way to take this option away from a user. I think in certain cases or environments this would be something that you wouldn't want the user to have control over.
2) The UI for these settings only allow pre-determined days to be picked via radio buttons. For example, Inbox (Unread), Inbox (Read), and Sent only allow for 30, 45, 60, 90, 120 days or never; and the possible settings for Junk and Trash are 1, 3, 7, and 30 days. Why limit it to just these settings? Why not allow the user to simply enter the number of days they wish to keep the messages?
3) It is unclear how these settings interact with the Administrative settings for a user, on the Advanced tab, under Timeout Policy; E-mail message lifetime, Trashed message lifetime, and Spam message lifetime. On the user settings I changed the setting for Junk to 7 days, and this setting is not reflected on the Administrative page. Which setting takes precedence? From an administrative standpoint I think this could get confusing.

Not sure if I'm missing something here. I searched around Bugzilla, but didn't find any open RFE's for these issues. I'm wondering what others think, and whether or not it is worth filing new RFE's for any or all of these things.

[Rich Graves]

I have 5b3 installed but haven't played with it much. I'd noticed this and forgot about it, thanks for the reminder.

If that setting cannot be locked by the administrator, I think that's a bad thing. We just migrated thousands of users to Zimbra and have been re-educating users who, for a decade, have been accustomed to the legacy IMAP "mark deleted/expunge" model to rely on a specific, system-wide trash expiration policy instead. In order to reduce the need for per-message restore, we have been teaching users not to empty their own trash. A user-accessible option to break this would make things difficult for support people.

[mmorse]

Added some notes for ya: Bug 13435 - User-definable expiration policy for systems folders

[soxfan]

Thanks mmorse. Didn't know if re-opening or creating new RFE's was the way to go.

[mmorse]

I actually didn't reopen it-someone else did.

A)
The original RFE was for "It should be possible for end-users to define expiration policy for system folders with COSible defaults (max value)."
-by doing it off of the max lifetime for a message, you force cleanup of old emails

-With a checkbox to prevent users from selecting the 'never' feature. As John Robb said: "There should also be a COS setting so that some users may not be able to turnoff the deletion policy".

And if you can show the current applied/actual value in the admin console gui & explained there how these values are the max a user can set a message lifetime too, that would work well enough on it's own.

-ok still have to show the inbox & sent lifetime options in the admin console (not just trash & spam/junk) but assuming that gets done.

So that would be the end state of the current RFE.

----
B)
Additional ideas:
Have an "allow user to set folder lifetimes" checkbox on each setting?
(so that would be 2 checkboxes, one for 'allow user to set' & one for 'disable never')

----
C)
For this next part, I apologize in advance for adding to the level of complexity...

However what about a range? (and thereby a minimum setting for the lifetime)

-So that would be 3 columns/attributes...Max allowed value, Min allowed value (both of which can be set/reset to the cos just like it can now) & then an 'current value' column that simply displays the applied.

-For the most part the 'min' does all the work of an 'actual' until the user decides they want to change something.
-This gets rid of the need for the 'disable never' checkbox.

From the user side-

Non drop-down route:
-display directions: 0 = never, 7 = 7days etc
-display their current value for each
-blank for the user to enter a value for each
-if they set it too low/high show them a "You must select lifetime value over/under x days" warning

Drop-down:
-Would be harder to implement with the minimum idea, but you would show them available choices based on the range allowed:
so if I set min to: 30 & max to: 120 they might see: 30 with other choices of: 60, 90, 120
and if I set min to: 0 they might see: never with other choices of: 3, 7, 30 etc, etc, up to the high value

Personally I think the non drop-down method is way easier to design, with the drop down method (though it would be much slicker) you'd still have to:
a) Incorporate the current choice into the options, which may be non-standard; so if the min is 41 then you have to show that value as one of the choices
-There will be tons of possibilities, so present a similar spacing based off the min value; or for starters +3, +7, & continue by +30 till you hit the max value? (man this just gets complex)
or
b) Show them the current value next to it (but what if they wanted to go back to that 'current'? A reset to default would be needed-ah!)


A while ago I opened Bug 16234 - Trash/Junk lifetime warning message so they would know the current value when actually in the trash & junk folders. While still a good idea, I'll concede that this will kind render that RFE less important. As either obtains the goal of letting the user's know how long the current lifetime is...

[mmorse]

------- Additional Comment #33 From Anand Palaniswamy 2007-09-05 16:41 CST -------
this bug has been re-opened so that these end user expiration options will be hidden in all skins except the specific customer skin developed by professional services.

If you want exposed feature in the standard zimbra skins, then that is a new feature request, and when we add that we will add it with a zimbraFeatureSystemFolderExpirationOptions boolean that admin can turn off for specific users (there should be a RFE on this, but isn't.)

Lol-lucky comcast, guess they got the $ though...so...want to create a new RFE? Obviously it won't make any initial v5 releases (they are fully bogged down with work as it is!) but I remember a lot of people wanting the sent folder lifetime...
There's also: Bug 6229 - Individual Folder Max Messages and Max Lifetime


andy made a new one for the chats: Bug 20753 - Allow user to set chat folder lifetime

[andyc]

Originally Posted by soxfan

1) There doesn't appear to be any way to take this option away from a user. I think in certain cases or environments this would be something that you wouldn't want the user to have control over.

This can be done by overriding the Mail preferences page template in the skin. At the moment, this requires a dev environment in order to compile the template file into native JavaScript and build the skin package. Eventually, we would like to have a skin installer that will do that work for you at installation time.

Originally Posted by soxfan

2) The UI for these settings only allow pre-determined days to be picked via radio buttons. For example, Inbox (Unread), Inbox (Read), and Sent only allow for 30, 45, 60, 90, 120 days or never; and the possible settings for Junk and Trash are 1, 3, 7, and 30 days. Why limit it to just these settings? Why not allow the user to simply enter the number of days they wish to keep the messages?

The exact control used to allow the user to modify this setting is determined by a preference descriptor. By default, this is a radio group with the options you mention. However, the values for the radio group can be changed or the control could be changed entirely -- for example, an input field could be used instead.

The only way to do this, at the moment, is by writing some code. In short, the skin would register a callback to be called when the preferences app is first launched. Then the mail lifetime preference objects can be queried and modified, changing the display options or the input type. Once that is done, the preferences will create the control with the settings you want.

Originally Posted by soxfan

3) It is unclear how these settings interact with the Administrative settings for a user, on the Advanced tab, under Timeout Policy; E-mail message lifetime, Trashed message lifetime, and Spam message lifetime. On the user settings I changed the setting for Junk to 7 days, and this setting is not reflected on the Administrative page. Which setting takes precedence? From an administrative standpoint I think this could get confusing.

The administrator settings take precedence if they are are shorter duration than the user setting. For example, if the admin says that trash is deleted after 7 days, then the user can't set it to be deleted at 30 days, etc. The UI is currently smart enough to disable those options that cannot be set by the user because they would conflict with admin settings.