I am currently on the softfork Betterbird 102.4.0 **Solution?:** I found a fix using the "__Move later__" filter action provided by the [Filtaquilla Addon](https://quickfilters.quickfolders.org/filtaquilla.html) Following actions in the given order work without dataloss: ``` 1. "Move later" the matching message to Imap Sub-Folder 2. Copy the matching message to Local Folder ``` **To Do:** Test - if this creates problems with additional other filter actions. - what happens, if switching to offline mode, sending messages, running filters and then switching into online mode. **How to fix regular Thunderbird?** Maybe Thunderbirds code could be adapted to fall back to "move later" behaviour, if both the `move` and `copy` filter actions are set at the same time (such as described in comment 19)? Since we are dealing with **data loss**, I would like to ask for a fix in Thunderbird core. Additionally, once this is fixed, I think adding this case to unit tests to prevent future regressions would be nice.
Bug 1781792 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I am currently on the softfork Betterbird 102.4.0 **Solution?:** I found a fix using the "__Move later__" filter action provided by the [Filtaquilla Addon](https://quickfilters.quickfolders.org/filtaquilla.html) Following actions in the given order work without dataloss: ``` 1. "Move later" the matching message to Imap Sub-Folder 2. Copy the matching message to Local Folder ``` **To Do:** Test - if this creates problems with additional other filter actions. - what happens, if switching to offline mode, sending messages, running filters and then switching into online mode. **How to fix regular Thunderbird?** Maybe Thunderbirds code could be adapted to fall back to "move later" behaviour, if both the `move` and `copy` filter actions are set at the same time (such as described in comment 23)? Code by Filtaquilla could serve as inspiration? Since we are dealing with **data loss**, I would like to ask for a fix in Thunderbird core. Additionally, once this is fixed, I think adding this case to unit tests to prevent future regressions would be nice.
I am currently on the softfork Betterbird 102.4.0 ## Solution?: I found a fix using the "__Move later__" filter action provided by the [Filtaquilla Addon](https://quickfilters.quickfolders.org/filtaquilla.html) Following actions in the given order work without dataloss: ``` 1. "Move later" the matching message to Imap Sub-Folder 2. Copy the matching message to Local Folder ``` **To Do:** Test - if this creates problems with additional other filter actions. - what happens, if switching to offline mode, sending messages, running filters and then switching into online mode. **How to fix regular Thunderbird?** Maybe Thunderbirds code could be adapted to fall back to "move later" behaviour, if both the `move` and `copy` filter actions are set at the same time (such as described in comment 23)? Code by Filtaquilla could serve as inspiration? Since we are dealing with **data loss**, I would like to ask for a fix in Thunderbird core. Additionally, once this is fixed, I think adding this case to unit tests to prevent future regressions would be nice.
## Solution?: I found a fix using the "__Move later__" filter action provided by the [Filtaquilla Addon](https://quickfilters.quickfolders.org/filtaquilla.html) Following actions in the given order work without dataloss: ``` 1. "Move later" the matching message to Imap Sub-Folder 2. Copy the matching message to Local Folder ``` **To Do:** Test - if this creates problems with additional other filter actions. - what happens, if switching to offline mode, sending messages, running filters and then switching into online mode. **How to fix regular Thunderbird?** Maybe Thunderbirds code could be adapted to fall back to "move later" behaviour, if both the `move` and `copy` filter actions are set at the same time (such as described in comment 23)? Code by Filtaquilla could serve as inspiration? Since we are dealing with **data loss**, I would like to ask for a fix in Thunderbird core. Additionally, once this is fixed, I think adding this case to unit tests to prevent future regressions would be nice.