https://bugs.kde.org/show_bug.cgi?id=416990
Bug ID: 416990
Summary: kwallet fails to save edits in individual notes under
certain circumstances
Product: frameworks-kwallet
Version: 5.66.0
Platform: openSUSE RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: va...@kde.org
Reporter: h...@urpla.net
CC: kdelibs-b...@kde.org
Target Milestone: ---
Created attachment 125574
--> https://bugs.kde.org/attachment.cgi?id=125574&action=edit
xml export before the fact
SUMMARY
When editing individual notes, and the time between editing and pushing the
Save button is big enough, the changes are not saved currectly, although
kwallet doesn't show any error.
STEPS TO REPRODUCE
1. add a new account
2. run kwalletmanager
3. create a new blowfish based wallet: kdewallet
4. supply password
5. launch wallet manager
6. open passwords tree item
7. right click on item Passwords -> Passwords -> New
8. provide a name: Secret
9. click: Show Contents
10. add: first entry
11. save
12. add: second entry
13. start kontact, add (some dummy) account, important is, that mailtransports
is filled
14. wait (restart akonadi, let screenlocker chime in..)
15. save the edited value
OBSERVED RESULT
A one point, probably after akonadi updates the mailbox, Secret is created as a
new mailtransports item, which explains why kwalleteditor is not complaining.
Needless to say, in a much more crowded kwallet, things get ugly, as it appears
as missing such edits.
EXPECTED RESULT
Saving edited items should work reliably, no matter, what happens between
editing and saving.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Leap 15.1
KDE Plasma Version: 5.12.8
KDE Frameworks Version: 5.55.0
Qt Version: 5.9.7
Linux/KDE Plasma: openSUSE Tumbleweed 20200128
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0
ADDITIONAL INFORMATION
I've observed this behavior since the dawn of kwallets. I use openSUSE
Tumbleweed as my primary workspace, but for this record, I used 15.1.
Since I've lost some pretty important notes over time, I developed the habit of
selecting the edited part, save it, switch items, and check back for success.
Usually, opening an item, editing it, and saving it immediately will be
successful, and it feels like the more time between editing and saving lapsed,
the higher the probability of failure.
The re-appearance of the item under a new parent item is a new observation for
me, while I tried to reproduce the issue in order to create this record.
I'm attaching two xml exports (with user/passwords edited), that demonstrate
the result of the problem.
--
You are receiving this mail because:
You are watching all bug changes.
