Page MenuHome GnuPG

KMail: delete all attachments option
Closed, ResolvedPublic


Add "Delete all attachments" option

Event Timeline

dvratil triaged this task as Normal priority.Jul 4 2023, 4:37 PM

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

dvratil moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
dvratil moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

I thought about adding support for deleting multiple attachments via the Message Structure view, but as Ingo said, it's marked as an "Expert" tool and it is not enabled by default so most users are not even aware of it, and it would actually be difficult to do it with a proper UX so I decided against it, unless it's explicitly requested by someone again.

On top of that. the current "Delete Attachment" action in the Message Structure view is actually mislabeled as it allows you to delete any part of the email without checking whether it is an actual attachment. So achieving a consistent UX would be hard :)

So I'm marking this as done, the PRs have been merged and the feature will be released in 23.12 (unfortunately I missed the window for 23.08 by a few days)

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

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