[KDE/Mac] Review Request 121159: add recovery from KWallet errors in mailtransport

[René J.V. Bertin]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121159/
-----------------------------------------------------------

(Updated Nov. 18, 2014, 9:32 a.m.)


Review request for KDE Software on Mac OS X and KDEPIM-Libraries.


Repository: kdepimlibs


Description
-------

The akonadi mail transport service cannot currently recover from KWallet errors because it treats them as persistent. A common case of error is a timeout during an (asynchronous?) unlock of the NetworkWallet in order to obtain the authentication credentials for an smtp server.
When this happens, the mail transport service will consider the KWallet to be unavailable and force the user to enter the credentials manually, even storing it in an unsecure manner in its configuration file if the user elects to store the password.

This patch adds recovery from KWallet errors by not using the stored error state, instead repeating the attempt to access the wallet the next time credentials have to be fetched. Instead of checking for the error flag, the check for KWallet::isEnabled() is done, before attempting to use other wallet functionality.

I don't think there is any reason to treat KWallet errors as persistent because they probably aren't most of the time and thus the user ought not be obliged to restart the mail transport agent to clear the error state.
I realise it's possible the error persistency was introduced to allow certain users to "disable" the wallet feature *only* for email sending; if so a less hackish solution with less side-effects ought to be possible.


Diffs (updated)
-----

  mailtransport/transportmanager.cpp d13f879 

Diff: https://git.reviewboard.kde.org/r/121159/diff/


Testing
-------

On Linux with KDE PIM 4.13.3 and git/4.14 . On OS X 10.6.8 with KDE PIM 4.13.3 .

The patch works as expected: when a wallet unlock times out, the mail transport's own authentication dialog is posted as usual. When cancelled, the dispatch attempt fails as expected, but a second attempt is made almost immediately; if the wallet dialog was used to unlock the wallet this attempt will succeed normally.


Thanks,

René J.V. Bertin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20141118/a8aa7852/attachment.html>