I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has 13 duplicates, 96 comments, and 44 users CC'ed. - The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss], which only works up to TB 78.* (3741 users as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (914 users as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (456 users as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
Bug 92146 Comment 96 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has 13 duplicates, 96 comments, and 44 users CC'ed. - The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss], which only works up to TB 78.* (3741 users as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (914 users as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (456 users as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has 13 duplicates, 96 comments, and 44 users CC'ed. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss], which only works up to TB 78.* (3741 users as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (914 users as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (456 users as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has 13 duplicates, 96 comments, and 44 users CC'ed. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (3741 users as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (914 users as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (456 users as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has **13 duplicates, 96 comments, and 44 users CC'ed**. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (3741 users as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (914 users as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (456 users as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has **13 duplicates, 96 comments, and 44 users CC'ed**. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (**3741 users** as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (**914 users** as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (**456 users** as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may depend on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has **13 duplicates, 96 comments, and 44 users CC'ed**. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (**3741 users** as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (**914 users** as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (**456 users** as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may *depend* on 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). There has been significant user interest in this ux-efficiency feature set, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has **13 duplicates, 96 comments, and 44 users CC'ed**. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (**3741 users** as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (**914 users** as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (**456 users** as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may *depend* on bug 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.
I believe the main purpose of this RFE since its inception 22 years ago has been to keep track of the idea of a much-wanted UX improvement, mass-acting on all attachments of multiple selected messages (save/open/detach/delete). **There has been significant user interest in this ux-efficiency feature set**, which would obviously make many repetitive attachment-related workflows much easier and faster. - This bug currently has **13 duplicates, 96 comments, and 44 users CC'ed**. - **The original [Attachment Extractor addon](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor/) had 36.000 users** (per my comment 37) before it was discontinued due to webextension compatibility issues (see comment 41 by Alexander Ihrig, one of the two original authors of the add-on). - Alexander Ihrig then published [Attachment Extractor continued](https://addons.thunderbird.net/en-US/thunderbird/addon/attachmentextractor-continued/?src=ss), which only works up to TB 78.* (**3741 users** as of today). - Somebody else published a [new add-on also called Attachment Extractor](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-extractor/?src=ss), which works with current Thunderbird (**914 users** as of today). - There's another add-on called [Attachment Saver](https://addons.thunderbird.net/en-US/thunderbird/addon/attachment-saver/?src=ss), which saves all attachments of multiple selected messages into a zip file (**456 users** as of today). It's fair to say that bug 292067 may help much towards the technical implementation of this feature set. However, bug 292067 does not cover the UX side of this at all, and - per its current title "Allow creation of a filter to *detach* attachment upon mail receipt/send" - is also much more limited in scope, because it only covers `detach` action. So this bug 92146 may *depend* on bug 292067, but if only for all the UX discussion and loads of genuine user support which we want to respect and preserve here, we shouldn't just tuck this away as a duplicate of an implementation-centered subset bug. I appreciate that this bug 92146 is historically grown and hence untidy/bulky, but keeping this open as a placeholder for the requested feature set isn't prejudicial to making a clean start in another bug if we want to get serious about exploring our UX and implementation options for this feature set. Also in terms of bug management, this bug is helpful to avoid more duplicates and collect incoming duplicates as well as occasional pings from users who are still hoping and waiting for this powerful feature.