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

Status: NEW

(MailNews Core :: Filters, enhancement)

Description

[Przemyslaw Bialik]

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

Comment 1

[Kent James (:rkent)]

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.

Comment 2

[Kent James (:rkent)]

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.

Comment 3

[Kent James (:rkent)]

Attachment: 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.

Comment 4

[Kent James (:rkent)]

Attachment: URL->URI

I see that folder URL is virtually unused, URI is the norm.

Comment 5

[Kent James (:rkent)]

Attachment: 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.

Comment 6

[Mark Banner (:standard8)]

Comment on attachment 402546 [details] [diff] [review]
Minor tweaks

Cancelling request whilst waiting for reviews.

Comment 7

[David :Bienvenu]

+    // 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...

Comment 8

[Kent James (:rkent)]

> 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.

Comment 9

[David :Bienvenu]

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.