Just a quick caveat: Save all attachments works really bad with complex message structures. If we now offer the option to delete all attachments after saving them this could have desastrous effects, i.e. the user could end up with unusable MIME-parts on their disk. I don't remember when I noticed this. Maybe with attached email messages, maybe with signed/encrypted messages, maybe with a combination of both.

Maybe save all and delete all should ignore attached email messages because I think it's highly unlikely anybody wants to save those to disk. (It's still possible via the message structure view for MIME experts.) Alternatively, it should only save/delete attachments that are actually displayed as attachments in the reader (which attached email messages are not).

Saving an attached messaged (in mbox format) is something that I sometimes want. It should be okay to implement.

Anyway I think you are right Ingo (@ikloecker), to create a good interface on how to save or delete some parts of an email is a hard task. The original defect came to be because the old KMail (e35) had more options. To address this in a better way would be more effort, like first collecting the different use cases.

A quick solution could be to offer something like "delete all _file_ attachments" which would mean throughout all MIME structures that are there
and then keep the ability to right click on parts of a message to delete or save that in addition.

There's also https://bugs.kde.org/show_bug.cgi?id=351426 that argues for a full GUI to allow the user to individually select attachments to delete. I can think of such a GUI but I think the amount of work needed to implement it would not be justified by the rather niche use-case.

The code to save all attachments uses KMime::Message::attachments() to get all attachments recursively. The code is clever enough to skip multipart/related parts, crypto-related parts and doesn't recurse into attached message/rfc822 parts and treats them as a single attachment instead. The plan is to make sure that "Delete All Attachments" uses exactly the function to get list of attachments to delete and behaves identically to "Save All Attachments". Thus, if you do "Save All" and then "Delete All", you should not lose any data.

Obviously we will be unable to touch encrypted messages, but the way "Save All Attachments" is implemented in KMail right now doesn't work for encrypted messages anyway since the code looks at the original encrypted message, so the symmetry between "Save All" and "Delete All" will be preserved on this level as well.

I agree that "Delete All" should use the same list of attachments as "Save All". Additionally, we should make sure that in both cases the list of attachments that are saved/deleted is identical to the list of attachments that is displayed as attachments in the viewer. Hopefully, KMime::Message::attachments() is also used for this.

Note that there is already a UI for selecting multiple attachments: the message structure view. But that's really a tool for experts. And it doesn't allow deleting multiple attachments (mostly, because this hasn't been implemented).

PRs with initial implementation - for now only in message list and message viewer context menu:

https://invent.kde.org/pim/messagelib/-/merge_requests/139
https://invent.kde.org/pim/kmail/-/merge_requests/92

@dvratil cool, I'm looking forward to it!

BTW: I am using the Message Structure view a lot, e.g. to delete HTML attachments.