464355 - Retention policy option "Use server defaults" incorrectly described

Status: RESOLVED FIXED

(MailNews Core :: Account Manager, defect)

Description

[Neville Hillyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.17) Gecko/20080915 Camino/1.6.4 (like Firefox/2.0.0.17)
Build Identifier: version 2.0.0.17 (20080914)

The option at:

Edit/Folder Properties/Retention Policy/Use server defaults

is incorrectly described.

'Use server defaults' should be 'Use account defaults'.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Nikolay Shopik]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090623 Shredder/3.0b3pre

Comment 2

[rsx11m]

Technically the current label is correct; the retention policy is reflected by a server-specific preference, and in turn the account is associated with a server. On the other hand, there is one server for each account, thus it may be easier for the user to understand "account" than "server". There also may be multiple server settings defined for the same physical server (e.g., if you have two accounts with different user names), adding to a possible confusion.

Comment 3

[rsx11m]

The ambiguity for deferred POP accounts mentioned in bug 449714 persists with either phrasing though.

Comment 4

[Neville Hillyer]

I have found that even experienced users are confused by the existing wording unless they have read:

http://www.freeemailtutorials.com/mozillaThunderbird/generalMaintenance.cwd

It is strictly a 'client' and not a 'server' setting. As worded it gets confused with 'Leave messages on server'. Whilst there are 'Server Settings' in the 'Account Settings' preference panel these are similar to many other mail clients and are better understood. Perhaps an alternative form of words or local explanation would resolve this.

My view is that the 'Retention Policy' would be better described as a 'Deletion Policy' because of the way in which it departs from the norm. It is particularly dangerous and would benefit from a warning in the settings panel. I understand that emails are permanently deleted without going via the Trash.

Comment 5

[rsx11m]

(In reply to comment #4)
> It is strictly a 'client' and not a 'server' setting.

I agree, and it is also not clear from the current phrasing whose "default" settings are actually referred to. Either of the terms "server defaults" or "account defaults" may be misunderstood to be a setting on the provider's end.

How about "[ ] Use my account settings" instead, to make it (a) clear that this is relative to an account, and (b) whose settings are used?

Comment 6

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #4)
> My view is that the 'Retention Policy' would be better described as a 'Deletion
> Policy' because of the way in which it departs from the norm. It is
> particularly dangerous and would benefit from a warning in the settings panel.
> I understand that emails are permanently deleted without going via the Trash.

We have another bug on this somewhere and it should be blocking the TB3 release as it's critical to have this fixed with at least a warning.

(In reply to comment #5)
> How about "[ ] Use my account settings" instead, to make it (a) clear that this
> is relative to an account, and (b) whose settings are used?

That sounds like a good improvement.

Comment 7

[rsx11m]

Ok, I'll work on a patch for changing the checkbox label. I found bug 323160 on moving messages to the trash folder when deleted based on message aging.

Comment 8

[Neville Hillyer]

If I recall correctly others have questioned (may not be on Mozilla site) the use of the term 'message ageing'. Are messages deleted a fixed time after they were created, sent, received at server, received at client or received at folder?

Intuitive interfaces, or the lack of them, are more critical when (as with Thunderbird) documentation is not supplied with the software and is not always easy to find on web sites. I would prefer to see 'hot' or copy/paste links where there are critical preferences which are not practical to define fully in the panel.

I would prefer to have a new global user defined default rather than refer to any server or account. Messages can come from several servers and be moved to folders associated with other servers by various means including filters. This setting will also need a warning and be initially set to not delete.

Comment 9

[rsx11m]

Neville, there has been quite a bit of work recently to clarify the labels
in the respective dialogs and to make them more specific, you can see those when looking into a 3.0 beta3-pre nightly build. Also, while SeaMonkey has a build-in help viewer which allows to provide detailed information how an option works, such a viewer is not available for Thunderbird yet (bug 253334). This would certainly make things easier.

For now, I'll focus on the specific label that you have opened this bug for.
If there are any issues pending you would like to have resolved, and which are not implemented in the current nightlies or covered by other bugs, it probably would be the best to file follow-up bug reports for each of them (one topic per bug report).

Comment 10

[rsx11m]

Attachment: Proposed patch

Bryan, this is the patch for the string change per comment #5. If there is anything else on Neville's list that could/should go into this patch please let me know.

> (comment #8) I would prefer to have a new global user defined default rather
> than refer to any server or account.

This could be part of bug 499306 on the retention-period backend. Indeed, in contrast to other server or account preferences, the defaults are hardwired and there are no mail.server.default.* global preferences for these settings.

Comment 11

[Neville Hillyer]

This looks good - many thanks.

I could not follow bug 499306 but it appears that something needs to be done both to resolve this satisfactorily and document it in a way which is easily understood by all. If, as it appears to me, this is in such a mess would it not be better to remove the 'Use server defaults' check-box until it has been both resolved and documented?

Comment 12

[rsx11m]

The problem is that using the account settings is the default, thus removing
that feature wouldn't be helpful. Giving UI-backend bugs like bug 472203 a
higher priority and make sure the feature can be used safely would be better.

Comment 13

[Neville Hillyer]

I find the request at bug 472203 worrying.

My method of working is to use Pop on two computers (at two locations) with 'Leave messages on server' set to 60 days. As long as I access Pop from both locations within 60 days one acts as a backup for the other. My aim is to keep all email indefinitely. This has been exceptionally useful in the past.

PLEASE do not do what Eudora used to do and have defaults set to delete mail.

What exactly are the server defaults?

Comment 14

[rsx11m]

Don't worry, the defaults are to keep all messages (Don't delete any messages)
and also the new "Always keep flagged messages" is checked by default.

I'm not aware of any intentions to change that behavior.

Comment 15

[rsx11m]

Comment on attachment 387360 [details] [diff] [review]
Proposed patch

Bryan, thanks for the ui-review. I realize that everybody is busy with the beta release, but requesting r/sr anyway, whenever you find the time to get to it...

Comment 16

[[e-mail]]

Comment on attachment 387360 [details] [diff] [review]
Proposed patch

>+<!ENTITY retentionUseAccount.label "Use my account settings">
>+<!ENTITY retentionUseAccount.accesskey "U">
Nit: we like to keep the case of the accesskey matching the label (the code internally does a case sensitive match first for speed and only tries a case insensitive match if that fails.)

Comment 17

[rsx11m]

Neil, the accesskey matches the capital "U" of "Use", thus that's considered.
Or did you mean anything else?

Comment 18

[[e-mail]]

(In reply to comment #17)
> Neil, the accesskey matches the capital "U" of "Use", thus that's considered.
> Or did you mean anything else?
No, that's just me being blind. D'oh.

Comment 19

[rsx11m]

No problem, the lower-case "u" would have found a target as well. ;-)

Comment 20

[Mark Banner (:standard8)]

Comment on attachment 387360 [details] [diff] [review]
Proposed patch

r=Standard8. There was one bit of bitrot (due to the resources/ directory elimination) which I've fixed and I've checked the patch in:

http://hg.mozilla.org/comm-central/rev/a96f5851cf1e

Comment 21

[rsx11m]

Thanks, I've unbitrotted my other affected patch respectively.

Bryan, are you looking into blocking status for related bugs per comment #6?
I'd think that bug 472203 and bug 323160 (or whichever other bug you had in mind) would be good candidates.