Open Bug 662056 Opened 13 years ago Updated 1 year ago

Implement move later functionality to prevent conflicts with filter actions needing the body (race condition)

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: rkent, Unassigned)

References

(Blocks 5 open bugs)

Details

(Keywords: dataloss, Whiteboard: [filterfails])

The "move" filter action is both the most common action, as well as the most disruptive, as it deletes the underlying message. Unfortunately, if you have other filter actions on the same message that require the message body (such as printing, attachment detach, saving the message as a file, etc.) then you enter a race condition, so either the move fails or the other action fails. In FiltaQuilla I have experimented with a workaround for this in an action I call "move later". With this, I set a property on the nsIMsgDBHdr for the object called "moveLaterCount". This count is incremented by the filter action that needs the body, and decremented when the async action is completed. When the count reaches zero, the move later is initiated. For this to be more transparent to the user, that same functionality should be implemented in the core "Move" filter action.
Assignee: nobody → kent
This is dealt with in the core code by making sure the move action is the last action performed, after all the other actions have finished. But, if you introduce async actions, but apply the actions synchronously, this breaks down.
> But, if you introduce async actions, but apply the actions synchronously, this breaks down. Right. The moveLater functionality deals with this breakdown by callbacks from the async actions that then trigger the move, if the moveLaterCount is zero.
Actually perhaps a better idea, and the one that I can make work more reliably, is to do the move first, and apply the other filters after the move. I've experimented with this concept with a detach attachments action, which is really tricky because it changes the message URI. Very difficult with moveLater, works really well with applying filter after the move. In FiltaQuilla, I have a new "folder name" search term, and in IMAP you have to enable incoming filters on the destination folder, and setup the complex filter action (like detachAttachments) to only apply if the folder name matches. This is way beyond the capabilities of the average user, while applying the filters after the move in core would be pretty straightforward to implement.
Status: NEW → ASSIGNED
Hi, any news on this enhancement?
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to :aceman from comment #4) > Hi, any news on this enhancement? I have not done any further work on this recently, though the issue remains.
Severity: normal → major
Whiteboard: [filterfails]
It will be great if someone could pick this up. Are these bugs involved? bug 1071628, bug 1096096, bug 589092, bug 971401
Assignee: rkent → nobody
Status: ASSIGNED → NEW
Summary: Implement move later functionality to prevent conflicts with filter actions needing the body → Implement move later functionality to prevent conflicts with filter actions needing the body (race condition)
Blocks: 1781792
Blocks: 567119
Blocks: 1265697
Blocks: 1071628
Keywords: dataloss

It has been demonstrated at https://bugzilla.mozilla.org/show_bug.cgi?id=1781792#c23 that filter actions 1) copy to Imap sub-folder and 2) move to local folder within the same filter leads to dataloss

Problem (Filters with dataloss):

Filter (A) fails with

1. Copy the matching message to Imap Sub-Folder
2. Move the matching message to Local Folder

--> All mails are moved to Local Folder and the body is fine, but only ONE (the first) mail was copied to imap Sub-Folder

Filter (B) fails with

1. Copy the matching message to Local Folder
2. Move the matching message to imap Sub-Folder

--> All mails are copied to Local Folder, but all mails lack body, except first mail. All mails are moved correctly to imap Sub-Folder.

Filter (C) fails with

1. Move the matching message to Local Folder
2. Copy the matching message to imap Sub-Folder

--> All mails are moved to Local Folder and the body is fine, but only ONE (the first) mail was copied to imap Sub-Folder

Solution (Filter without dataloss):

Details are at https://bugzilla.mozilla.org/show_bug.cgi?id=1781792#c25. Use following filter actions in given order:

1. "Move later" the matching message to Imap Sub-Folder
2. Copy the matching message to Local Folder

This solution depends on the Filtaquilla Addon.

Blocks: 1801464
Blocks: 1714389
You need to log in before you can comment on or make changes to this bug.