Closed Bug 324147 Opened 18 years ago Closed 15 years ago

Retention policy should not delete flagged/starred messages

Categories

(MailNews Core :: Backend, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: holger, Assigned: mkmelin)

References

Details

Attachments

(2 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Thunderbird 1.5 (Windows/20051201)

It is often desired to keep interesting or important messages for later reference by flagging or labeling ("To do"...) them. However, when using "Folder Properties / Retention Policy" these messages are deleted.

I propose either that keeping flagged/labeled messages should be the default behaviour or to add one ore more new checkboxes to the exististing Retention Policy UI, for example:
[x] Never delete flagged or labeled messages
[x] Never delete unread messages


Reproducible: Always

Steps to Reproduce:
that's a reasonable request, though I don't know when I might get to it.
Assignee: mscott → bienvenu
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
I agree either with this, or perhaps adding another flag for messages that would allow the auto-retention policy to recognize that the message should not be deleted, regardless of the deletion settings in the auto-retention policy.

For example, in addition to flagging/labelling messages, messages could be "Marked" as "Retain Message -- do not allow auto-retention deletion."
Only flaw I see with this RFE is server retention limits.  Some server admins set retention for periods of 14 or fewer days.

Would a message copy or move action be more permanent and better serve the Requesters need?  This may need a thread save to keep the context of the discussion.
Product: Thunderbird → Core
Summary: Retention policy should not delete flagged/labeled messages → Retention policy should not delete flagged/star or labeled messages
Version: unspecified → Trunk
Component: General → MailNews: Backend
This really should be implemented. I want my email to be automatically deleted after I read it UNLESS I mark it. Almost every email client assumes that any email received and read should be retained. This was fine in the 80's and early 90's before the days of SPAM and just general noise that comes through email at companies these days. Seems like any email client  today should assume a paradigm that unless an email is marked it's to be deleted after a certain time.

That's why I'm STILL using gnus. God bless it! You can set it up to do exactly that, delete email unless it's marked (tic'd) after a user-adjustable period of time.
I hope folks won't mind me copying here my original feature request filed as bug 374480 (now closed as a duplicate of this one).  It explains in some detail why I feel that this feature is so important:

I'm in the process of changing from another email client to Thunderbird for my email.  In my other client I can set a flag on an email message (termed a "Bookmark").

This client has a "Purge" feature which is similar to Thunderbird's "Disk Space" feature in that I can specify that all messages over a certain number of days are to be deleted, or that only the last x messages should be retained.  Now, when the "Purge" is carried out, messages with the "Bookmark" flag are immune from deletion.

What this means is that the messages which I have bookmarked (because I want to keep them) end up at the beginning (or end - depending on sort) of the folder. I can then look through them, delete any I've decided I don't need to keep any longer, then CLICK and SHIFT-CLICK on a block of them and drag the block to an archive folder that I have created for the purpose.

I could, of course, move these messages to an archive individually as I read them but I prefer to leave them in situ initially as they may form part of an email "conversation" or require some action on my part.

So, in short, I want to be able to:

1. Expire all messages over a certain number of days old, apart from my "bookmarked" ones.
2. Periodically move (manually will do) my earliest "bookmarked" messages from my normal folders to archive folders.

As I see it, the only feature missing from Thunderbird is the ability to set a "read-only" or "do not delete" flag on individual messages, equivalent to the "Bookmark" feature in my other client.
QA Contact: general → backend
I suppose not deleting unread messages would be good too...
I plan to take a look at this.
Assignee: bienvenu → mkmelin+mozilla
Keywords: helpwanted
Product: Core → MailNews Core
Flags: wanted-thunderbird3?
I'm modding the summary a bit. I don't really see the point of not including labeled messages as they are mostly for organization.
Flags: wanted-thunderbird3? → wanted-thunderbird3+
Priority: -- → P2
Summary: Retention policy should not delete flagged/star or labeled messages → Retention policy should not delete flagged/stared or unread messages
Target Milestone: --- → Thunderbird 3.0b2
I decided no to do the unread part.
Status: NEW → ASSIGNED
Summary: Retention policy should not delete flagged/stared or unread messages → Retention policy should not delete flagged/starred messages
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Attached patch proposed fix (obsolete) — Splinter Review
Allows excluding starred messages from all automatic deletion.
Attachment #355467 - Flags: ui-review?(clarkbw)
Attachment #355467 - Flags: superreview?(neil)
Attachment #355467 - Flags: review?(bienvenu)
Attached image proposed fix screenshot (thunderbird) (obsolete) —
SeaMonkey has it's own strings... which is fairly confusing.
(In reply to comment #11)
> I decided no to do the unread part.

It looks like you included the unread part...  is that correct?

Just checking, because I don't think I understand the code.  You're defaulting to keeping the starred messages, right?

Also I would make the pref in the inverse:

[x] Always keep starred messages
No, that's partly why I didn't include the "unread part"... it get's confusing. 
What you see is the existing pref to always delete after read, as opposed to *keep* all unread. 

But yes, I'm defaulting to keeping starred messages.
Attached patch proposed fix, v2 (obsolete) — Splinter Review
Updated to Bryan's comments.
Attachment #355467 - Attachment is obsolete: true
Attachment #355468 - Attachment is obsolete: true
Attachment #355481 - Flags: ui-review?(clarkbw)
Attachment #355481 - Flags: superreview?(neil)
Attachment #355481 - Flags: review?(bienvenu)
Attachment #355467 - Flags: ui-review?(clarkbw)
Attachment #355467 - Flags: superreview?(neil)
Attachment #355467 - Flags: review?(bienvenu)
Attachment #355481 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 355481 [details] [diff] [review]
proposed fix, v2

looks good from my side of things
Comment on attachment 355481 [details] [diff] [review]
proposed fix, v2

>   nsMsgRetainByPreference retainByPreference;
>   PRUint32 daysToKeepHdrs = 0;
>   PRUint32 numHeadersToKeep = 0;
>   PRBool keepUnreadMessagesOnly = PR_FALSE;
>   aMsgRetentionSettings->GetRetainByPreference(&retainByPreference);
>   aMsgRetentionSettings->GetKeepUnreadMessagesOnly(&keepUnreadMessagesOnly);
> 
>+  PRBool applyToFlaggedMessages = PR_FALSE;
>+  aMsgRetentionSettings->GetApplyToFlaggedMessages(&applyToFlaggedMessages);
>+
[Hmm, the variable ordering here is odd]

>+    nsMsgKey msgKey;
>+    pHeader->GetMessageKey(&msgKey);
>+
>+    if (!applyToFlaggedMessages)
>+    {
>+      PRBool isFlagged;
>+      rv = IsMarked(msgKey, &isFlagged);
IsMarked turns its msgKey back into an nsIMsgHdr. Better would be to rewrite IsMarked (there don't appear to be any existing consumers). Or just inline it.
Attachment #355481 - Flags: superreview?(neil) → superreview+
Attached patch proposed fix, v3Splinter Review
Adjusting to neil's comments.

Carrying over ui-r=clarkbw, sr=neil
Attachment #355481 - Attachment is obsolete: true
Attachment #355801 - Flags: ui-review+
Attachment #355801 - Flags: superreview+
Attachment #355801 - Flags: review?(bienvenu)
Attachment #355481 - Flags: review?(bienvenu)
Attachment #355801 - Flags: review?(bienvenu) → review+
Comment on attachment 355801 [details] [diff] [review]
proposed fix, v3

looks good. Technically, you should rev the uuid on the idl interface change. r=me with that nit addressed.
Is uuid rev really needed? I only add (not change/remove) the interface.
... add - a property.
in theory, anything that would change the c++ v-table for a class implementing this property should cause a uuid rev. In practice, no one is doing a binary linkage to this code.
changeset:   1615:fc2a53dec61b
http://hg.mozilla.org/comm-central/rev/fc2a53dec61b

->FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 497383
You need to log in before you can comment on or make changes to this bug.