[kmymoney] [Bug 384051] No reset of hcbi account pin possible
https://bugs.kde.org/show_bug.cgi?id=384051 Moritz Bunkus changed: What|Removed |Added CC||kde@bunkus.online --- Comment #7 from Moritz Bunkus --- I just came over here to finally report this myself after being annoyed by it for many, many years. I'm using a rather long passphrase for aqbanking's certificate, and mistyping it is common occurrence. kmymoney not recognizing this and me having to restart kmymoney is incentivizing using shorter, easier to type and hence less secure passwords. Instead, a program dealing with such an important topic should make it easy to do the right (the secure) thing. Ideally kmymoney should figure out that updating accounts through aqbanking failed due to a wrong password and un-cache the password. I can imagine, though, that the API doesn't expose this kind of detail, only whether or not the update succeeded. If this is indeed the case, I'd very much appreciate if kmymoney always un-cached the passphrase when aqbanking fails to update. If that seems too hostile to the user[1], making this behavior optional via the settings would be totally fine. [1] Of course aqbanking might fail for reasons other than wrong passphrases — network outages, DNS not working, the bank's servers not being reachable etc. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 440710] Aqbanking: kmm should not cache/remember the password if it was incorrect
https://bugs.kde.org/show_bug.cgi?id=440710 Moritz Bunkus changed: What|Removed |Added CC||kde@bunkus.online --- Comment #1 from Moritz Bunkus --- Doesn't this look like a duplicate of bug 384051? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 384051] No reset of hcbi account pin possible
https://bugs.kde.org/show_bug.cgi?id=384051
--- Comment #9 from Moritz Bunkus ---
Thanks for the insight. Like I said, I totally understand if this particular
failure type isn't observable to kmymoney.
If I understand you & comment #3 correctly, kmymoney does have enough control
to tell the rest of the stack to forget any cached passphrase. So it would be
in kmymoney's power to give the user some control over this situation. I
suggest to add one of the following:
1. An option in the settings to always clear cached passphrases if fetching the
account failed, off by default.
2. A menu entry in the "Tools" menu called something like "Forget cached
passphrases", which the user could use.
3. If updating an account fails, show a message box asking explaining the
problem ("This might be due to a wrong passphrase or PIN.") & offering to clear
the cached passphrase/PIN & try again; ideally with a checkbox to never show
this type of question again.
4. Make passphrase/PIN caching completely optional via the settings.
I agree that this is fundamentally a thing inside aqbanking/its libraries, but
from the PoV of a user, I'm not interacting with aqbanking at that moment. I'm
using kmymoney. To the user it is totally unclear that
1. password caching is happening in the background,
2. restarting the application causes cached passwords to be forgotten,
3. waiting 60 seconds causes cached passwords to be forgotten (I found this out
by reading this bug),
4. it isn't actually kmymoney that's caching the passphrase.
All of that (save for 1., I guess) will cause the user to spend a lot of time
going through all options, all menus, dialogs etc., in order to find a way to
recover. They'll most likely end up with the "restart application" way, 'cause
"have you tried turning it off & on again" is so ingrained in general user
troubleshooting. Doesn't make it good design, though.
Of course the ideal solution is to being able to auto-detect when clearing is
necessary. My proposals above are only useful if that isn't possible due to API
limitations.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney] [Bug 384051] No reset of hcbi account pin possible
https://bugs.kde.org/show_bug.cgi?id=384051 --- Comment #14 from Moritz Bunkus --- Thanks again for your work & following up on this, Thomas. Much appreciated. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494865] ledger view: Ctrl+A selects all transactions but does not update balance
https://bugs.kde.org/show_bug.cgi?id=494865 Moritz Bunkus changed: What|Removed |Added Resolution|LATER |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #2 from Moritz Bunkus --- I see your point, but respectfully, you're wrong. Even if no transactions are hidden, the thing that's shown should be the sum sign & the balance of the selected transactions instead of the word "Balance:" followed by the sum. This isn't the case. Here's what actually happens: • no transactions selected at all; you'll see: "Balance: 12345" (example values, obviously) • select some transactions via Ctrl + mouse-clicking; you'll see: "Σ: 78" • select all transactions via Ctrl+A; you'll still see: "Σ: 78" ( obviously wrong!) On top of that you can also try the following sequence & see how things change: • same starting point as before: no transactions selected at all; you'll see: "Balance: 12345" • select all transactions via Ctrl+A; you'll still see: "Balance: 12345" • deselect a single of the selected transactions via Ctrl + mouse-clicking; you might now see: "Σ: 989" All of this is without any filter active, nor with "hide reconciled transactions". Now for a third test: I have prepared an leder & inserted three transactions into it, values are +10, +5 & +2. The +10 is reconciled. Then I turn on "hide reconciled transactions". Now: • initially with no transactions selected I see "Balance: 17" • selecting all via Ctrl+A doesn't change that value at all, even though only the two transactions with +5 & +2 are selected; I would expect to see "Σ: 7", instead I still see "Balance: 17" • now I deselect one transaction with Ctrl + mouse-clicking; it instantly changes to "Σ: 2" (if I deselect the +5). • I re-select the deselected one via Ctrl + mouse-clicking so that all visible (not reconciled) transactions are selected; I now see the expected "Σ: 7" It's quite obvious that changing the selection of transactions via Ctrl+A doesn't actually trigger the signal to update the value shown there, making it temporarily invalid. Please just give it a try & you'll see that this is indeed a bug. The instructions are easy to follow, the first two examples don't even require changes to be made. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494865] New: ledger view: Ctrl+A selects all transactions but does not update balance
https://bugs.kde.org/show_bug.cgi?id=494865 Bug ID: 494865 Summary: ledger view: Ctrl+A selects all transactions but does not update balance Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: ux-ui Assignee: kmymoney-devel@kde.org Reporter: kde@bunkus.online Target Milestone: --- SUMMARY In the ledger view you can select multiple transactions the usual ways, e.g. by holding Ctrl while mouse-clicking on them, or holding Shift & mouse-clicking for selecting a whole region. When multiple transactions are selected that way, the balance shown below the transaction list on the right will be updated with the balance over all selected transactions. Pressing Ctrl+A is another well-known way to select multiple entries at once in general, and it works in the ledger view, too: it selects all transactions, just as I would expect it to. However, whenever I use Ctrl+A the balance is not updated at all, no matter of I had no transactions selected before, one or any other number. STEPS TO REPRODUCE 1. Open ledger view 2. Select multiple transactions with e.g. the Ctrl & mouse-click or the shift & mouse-click method. 3. Observe the balance updating. 4. Deselect all transactions. 5. Select all transactions by pressing Ctrl+A 6. Observe that the balance is not updated OBSERVED RESULT The balance is not updated when I use Ctrl+A to select all transactions. EXPECTED RESULT The balance should be updated no matter which method I use for selecting multiple transactions, including Ctrl+A. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494865] ledger view: Ctrl+A selects all transactions but does not update balance
https://bugs.kde.org/show_bug.cgi?id=494865 Moritz Bunkus changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #4 from Moritz Bunkus --- Ooooh you're right, I had totally overlooked the "version fixed in change" for some reason. Seems I was confused by the resolution of "reported" + "later". Sorry for that. Yes, I am talking about release 5.1.3; I've tried building the current git master, but that won't work due to library requirements, and I didn't want to invest too much time into it. Therefore I had only tested with 5.1.3. Now let me give me a quick try with the development AppImage… yep, it's indeed fixed there. Thanks! -- You are receiving this mail because: You are the assignee for the bug.
