annotate junked messages with info from what folder a junk mail came from

NEW
Assigned to

Status

MailNews Core
Filters
--
enhancement
9 years ago
7 years ago

People

(Reporter: Przemyslaw Bialik, Assigned: rkent)

Tracking

(Blocks: 1 bug)

Trunk
Thunderbird 3.1a1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact] [needs r/sr bienvenu])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

9 years ago
Such info is needed to properly fix Bug 208197 (moving always to inbox is not perfect)
(Assignee)

Comment 1

9 years ago
The holdup in this has been the stability of the message database, which was originally viewed as a non-permanent index of the folders, but has been moving toward being a reliable permanent store of message metadata. For example, my junk folder metadata was blown away within the last few hours, in spite of some attempts that have been made to prevent that.

Actually storing the folder URL in the database is fairly trivial, and I have seriously thought of doing that.

Updated

9 years ago
Blocks: 466041
(Assignee)

Comment 2

9 years ago
My fix in bug 471682 seems to have solved the main issue that has been affecting junk folder database stability on my computer - at least for 4 days now. I'm going to take this bug now since there is now hope that it can be done.

However, I think that we need to fix bug 459680 so that the information in the database will survive the copy to a new folder.

I'm going to block this on both of those bugs.

If we get the folder URL of the originating folder listed in the database as requested in this bug, then the functionality of bug 208197 and bug 466091 could be implemented in an extension such as my JunQuilla.
Assignee: nobody → kent
Component: Backend → Filters
Depends on: 459680, 471682
QA Contact: backend → filters
Target Milestone: --- → Thunderbird 3.0b3
(Reporter)

Updated

9 years ago
No longer blocks: 208197
Blocks: 208197
No longer blocks: 208197
(Assignee)

Updated

9 years ago
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0rc1
(Assignee)

Comment 3

9 years ago
Created attachment 401468 [details] [diff] [review]
The fix, no known issues

I want to test this some more, but here's the fix. It creates a new message property that is used on all copies and moves, not just junk related moves. The test additions also exercise some additional copy code that I don't think has any other tests.
(Assignee)

Comment 4

9 years ago
Created attachment 401508 [details] [diff] [review]
URL->URI

I see that folder URL is virtually unused, URI is the norm.
Attachment #401468 - Attachment is obsolete: true
(Assignee)

Comment 5

9 years ago
Created attachment 402546 [details] [diff] [review]
Minor tweaks

This patch is clearly optional for TB3, since its primary purpose is to setup properties needed for bug 466041, and that bug is not likely to make it into TB3. But it is not a very risky patch either, so I'll let the drivers make the call. Most of the patch is additional testing of cross-account moves, which are useful tests anyway.
Attachment #401508 - Attachment is obsolete: true
Attachment #402546 - Flags: superreview?(bienvenu)
Attachment #402546 - Flags: review?(bienvenu)
Attachment #402546 - Flags: approval-thunderbird3?
(Assignee)

Updated

9 years ago
Whiteboard: [no l10n impact] [needs r/sr bienvenu]
Comment on attachment 402546 [details] [diff] [review]
Minor tweaks

Cancelling request whilst waiting for reviews.
Attachment #402546 - Flags: approval-thunderbird3?

Comment 7

9 years ago
+    // After many hours of debugging, I learned that an initial update
+    // of IMAP folders is needed, otherwise the URI validity is not

I think you mean UID validity here.

This patch looks OK, though it's going to increase our per-message overhead in the db for moved messages, which doesn't thrill me. But I imagine there could be some nice uses for it...
(Assignee)

Comment 8

9 years ago
> I think you mean UID validity here.

Yes, I meant UID validity.

> it's going to increase our per-message overhead in the db for moved messages

It would be great if we had some better testing of speed and bloat effects. I would hate for us to be reluctant to include new capabilities when we really don't know the impact. That being said, I'll have to rely on your judgement here.

> But I imagine there could be some nice uses for it

I'm picturing an extra column, probably through an extension initially, that displays the name of the source folder for a moved or copied message. I haven't really looked much at undo features, but that is another possible use.
(Assignee)

Updated

8 years ago
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.1a1

Comment 9

7 years ago
Comment on attachment 402546 [details] [diff] [review]
Minor tweaks

My main objection to this is that it introduces overhead without any current benefit for moves that aren't moves to the junk folder (I think we had this discusson over IRC, but I don't remember for sure). We can imagine extensions that use this information, but I think this would be an attribute that an extension could handle setting itself by listening for move events.

The overhead is slight, and I suppose the main victim would be the trash folder, but that's a database we open and keep open, so it would cause some bloat. So I'd prefer a patch that just does this for the junk folder...I'm willing to listen to arguments, however.
Attachment #402546 - Flags: superreview?(bienvenu)
Attachment #402546 - Flags: superreview-
Attachment #402546 - Flags: review?(bienvenu)
Attachment #402546 - Flags: review-
You need to log in before you can comment on or make changes to this bug.