Bug 120392

Summary: GUI for enabling/disabling of signature and encryption is confusing
Product: [Applications] kmail2 Reporter: Hauke Laging <hauke>
Component: composerAssignee: kdepim bugs <kdepim-bugs>
Status: CONFIRMED ---    
Severity: wishlist CC: korossy, luigi.toscano, sknauss
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Hauke Laging 2006-01-18 16:55:21 UTC 
Version:            (using KDE KDE 3.4.2)
Installed from:    SuSE RPMs

You cannot see in the GUI which priority the settings for encryption and signing in the symbol bar have. My e-mails are signed by default. When I open a window for a new message the signature button is pressed. When I manually deactivate it I expect the message not to be signed. If the recipient is configured to have all his messages signed then the message is signed nonetheless without the user being warned or asked.

Technically one could argue that "always sign" does mean "don't ask me" bit I think that a manual change of the default behaviour overrides this - at least in the expectation of the average user.

A similar problem exists with encryption. In that case a dialog pops up but you have to change the default setting for the address then. But even if you do so and change it to "always ask" then the message is sent with encryption, without the user being asked and not even the default setting is changed though the dialog should do just that. But I was asked for the name in the address book which I cancelled because there is already an entry in the address book for this address (if that was not the case the dialog would not have popped up at all).

I suggest to associate four states instead of the usual two to the buttons for signing and encryption:

1) disabled
2) enabled
3) disabled (use default)
4) enabled (use default)

The first to would override the address book setting and would never be set when a new message window is opened. These stated could only be reached manually. States 3 and 4 could be combined to one "use default". The seperation makes sense if kmail determines what the default is (whenever the recipient address is changed...) in oder to show this to the user.
Comment 1 Myriam Schweingruber 2012-08-18 08:39:59 UTC 
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 2 Luigi Toscano 2012-08-19 00:37:01 UTC 
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
Comment 3 Hauke Laging 2012-08-19 02:21:06 UTC 
(In reply to comment #2)
> Instead of creating a new feature request, please confirm here if the
> wishlist is still valid for kmail2.

Still valid.
Comment 4 Sandro Knauß 2014-12-12 23:53:49 UTC 
Still valid.
Comment 5 Hauke Laging 2014-12-13 01:16:44 UTC 
It's worth noting that Enigmail does that meanwhile. At least partly. They do not show correctly what is going to happen with an email but they show that the default setting has been changed. And if it is changed back to its original value then this value overrides the (non-shown) settings for the recipient.