When deleting an attachment, a confirmation dialog is shown warning that "Deleting an attachment might invalidate any digital signature on this message." This is inappropriate and confusing on mails that aren't digitally signed at all. So the annoyed user will tend to switch the irrelevant warning off (checking 'Do not ask again'). This however means that there won't be a confirmation dialog at all, when deleting attachments, even though this is an irreversible action. Ideally, a digital signature should be discovered and the confirmation dialog should emit an appropriate warning. So if the message is digitally signed, the wording could be as follows: "Do you really want to delete the %n selected attachment/s? Once deleted, it/they cannot be restored. Also, this might invalidate the digital signature of this message." However, if the message is not digitally signed, the wording should be just: "Do you really want to delete the %n selected attachment/s? Once deleted, it/they cannot be restored." Reproducible: Always
I confirm it
Might be better to keep the two warnings separate, so they can be separately switched off. So on deletion the wording generally would be: "Do you really want to delete the %n selected attachment/s? Once deleted, it/they cannot be restored." If confirmed, it is checked if the message is digitally signed, and only if it is, a second warning would say: "Do you really want to delete the %n selected attachment/s? This might irreversibly invalidate the digital signature of this message." Even better if we wouldn't say "might be invalidated", but detect a bit more and show the second warning only, if it really will be invalidated. You might better know, in which cases this is true. Better case differentiation seems necessary, as fuzzy warnings tend to be annoying, even more if they cascade. But then again, they are mutable, and cascading seems to be the only correct way to do this.
I consider this a usability defect of normal category.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
@Denis, if this is a defect for current 4.14, will you still close it?
Now that's a good question. I hoped that everyone would respect my comment and not confirm any of the 2600 bugs I changed on Saturday for 4.14, but I should have known better. I'm afraid there's only one thing I can tell you 4.14 people: We simply lack the manpower to look into 4.14 bugs. I don't think that any KDE PIM developer will ever again find time and motivation to look into bugs that have never been confirmed for a Qt5/Frameworks based version. Sorry for the bad news.
@Denis, of course I appreciate your work in KDE and the issue tracker in particular, cleaning up is very important! I did ask, because your short comment did not explain the situation for me. My suggestion would be that you should link a more official statement. Your last statement reads like "4.14 KDEPIM" would be unmaintained. If this would be really the case I think we should notify all distributions about it. Getting 4.14 from Ubuntu, Debian or OpenSuse or any other GNU/Linux distribution is then just a security risk. So my hope is that the policy is different.
I asked about an official statement for this on IRC, and noone knew about one. On the other hand, I couldn't find a statement that there would ever be support by KDE (PIM) devs for PIM versions other than the most recent. But maybe this topic should be discussed in the forums or on some mailinglist.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.