Open
Bug 465794
Opened 16 years ago
Updated 2 years ago
annotate junked messages with info from what folder a junk mail came from
Categories
(MailNews Core :: Filters, enhancement)
MailNews Core
Filters
Tracking
(Not tracked)
NEW
Thunderbird 3.1a1
People
(Reporter: maxxmozilla, Assigned: rkent)
References
(Blocks 1 open bug)
Details
(Whiteboard: [no l10n impact] [needs r/sr bienvenu])
Attachments
(1 file, 2 obsolete files)
11.71 KB,
patch
|
Bienvenu
:
review-
Bienvenu
:
superreview-
|
Details | Diff | Splinter Review |
Such info is needed to properly fix Bug 208197 (moving always to inbox is not perfect)
Assignee | ||
Comment 1•16 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.
Assignee | ||
Comment 2•15 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 | ||
Updated•15 years ago
|
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0rc1
Assignee | ||
Comment 3•15 years ago
|
||
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•15 years ago
|
||
I see that folder URL is virtually unused, URI is the norm.
Attachment #401468 -
Attachment is obsolete: true
Assignee | ||
Comment 5•15 years ago
|
||
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•15 years ago
|
Whiteboard: [no l10n impact] [needs r/sr bienvenu]
Comment 6•15 years ago
|
||
Comment on attachment 402546 [details] [diff] [review] Minor tweaks Cancelling request whilst waiting for reviews.
Attachment #402546 -
Flags: approval-thunderbird3?
Comment 7•15 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•15 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•15 years ago
|
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.1a1
Comment 9•13 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-
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•