After I've added a new account, the "Delete" item in the context menu is disabled and the account can never be removed. Workaround: delete the whole file, and rebuilt from scratch without the account. Obviously not a useful way. Reproducible: Always Steps to Reproduce: 1. Add a new account. 2. In the accounts' list click right button on the newly created account 3. See the "Delete Account" item available 4. Click "Delete Account" Actual Results: On step 3 the item is grayed and unavailable. Expected Results: See the account removed from the list after step 4 Tried when running on Ubuntu 10.4 machine, same result. Not a Windows issue.
Works OK here. Can you describe the exact steps you did to add the account. Is it a subaccount of an existing account? What exactly did you enter in the wizard? What version did you try on Ubuntu?
Looking at your other bug entry, might this be an investment account too? If so, does it have stocks and/or prices? If so, they will need to be deleted before the account can be deleted.
(In reply to comment #2) > Looking at your other bug entry, might this be an investment account too? > > If so, does it have stocks and/or prices? If so, they will need to be > deleted before the account can be deleted. All kinds of accounts, checking, savings, investments. Could it be because I've created them with starting balance? If so its completely counter-intuitive. I'd suggest instead of bluntly disabling, enable it and pop up a message if it cannot be done, explaining why. Better, allow deleting and orphaning the transactions (or deleting the transactions automatically). At least document the limitations...
(In reply to comment #3) > (In reply to comment #2) > > Looking at your other bug entry, might this be an investment account too? > > > > If so, does it have stocks and/or prices? If so, they will need to be > > deleted before the account can be deleted. > > All kinds of accounts, checking, savings, investments. Could it be because > I've created them with starting balance? Yes, that creates a transaction. > If so its completely > counter-intuitive. I'd suggest instead of bluntly disabling, enable it and > pop up a message if it cannot be done, explaining why. Better, allow > deleting and orphaning the transactions (or deleting the transactions > automatically). What about all the other disabled menu entries? Would you have them all enabled? Or have a pop-up for every one of them? > > At least document the limitations... From the KMyMoney handbook - "Deleting accounts To delete an account, first remove all the transactions from that account in the ledger. Next, find the account in the accounts view and after right clicking on the entry to show the popup menu select Delete account... from the popup menu."
Hmm.... You have a point there, but here's the thing: I opened an account, and downloaded 2012 transactions instead of 2013 by mistake. In 2013 I have 3 transactions, in 2012 I have 3000. Expecting the user to remove 3000 transactions is absurd if you can do it automatically. I understand its a design decision, but as I said - its a counter-intuitive one. There's nowhere I can see why the menu is disabled, and because I created all the accounts with opening balances - it is disabled on all of them. Taking opening balance as a transaction is a logical thing to do for a programmer, but counter-intuitive to a user, Having doing it both way (as a programmer, and ex-QA in banking system), this is a usability bug to say the least. But thanks for the explanation, it does help me to overcome the issue for me. I'm with you closing this if you don't want to change the behavior, but I'd wish it was more clear to the end user (maybe a floating tip text for the menu item or something like that?)
I'll think about adding an item to the FAQ if it isn't already there. As for deleting many transactions, you should be able to select all transactions in the ledger, then delete them all with one click. It might take a while for the program to delete al of them, but I wouldn't call it absurd. Also - you can open a bug for this as a wishlist (can this bug be changed to wishlist?) so it doesn't get forgotten as a request, even if there is no available developer time to get to it in the near future. One more suggestion - if you do frequent enough backups of your kmy file, then it would probably be easier to just revert to the file from before you did the wrong import.
Agreed, changed to wishlist.
(In reply to comment #5) > Hmm.... You have a point there, but here's the thing: I opened an account, > and downloaded 2012 transactions instead of 2013 by mistake. In 2013 I have > 3 transactions, in 2012 I have 3000. Expecting the user to remove 3000 > transactions is absurd if you can do it automatically. I understand its a > design decision, but as I said - its a counter-intuitive one. There's > nowhere I can see why the menu is disabled, and because I created all the > accounts with opening balances - it is disabled on all of them. Taking > opening balance as a transaction is a logical thing to do for a programmer, > but counter-intuitive to a user, Having doing it both way (as a programmer, > and ex-QA in banking system), this is a usability bug to say the least. > I'm not an accounting expert, or any other kind either, but with the double-entry principal, I don't think money can appear or disappear without a transaction. > But thanks for the explanation, it does help me to overcome the issue for > me. I'm with you closing this if you don't want to change the behavior, but > I'd wish it was more clear to the end user (maybe a floating tip text for > the menu item or something like that?) It's not a question of me not wanting to change the behavior. If you had deleted the account with 3000 entries, and had made a mistake with that account selection, then .... I think it's more 'Health and Safety'. I agree with you, though, that some indication of the reason for the disabling would be beneficial, but where would one draw the line? There must be many thousands of checks and decisions in any non-trivial program. I can understand the frustration, but I think to an extent it comes down to 'Once bitten, twice shy'. Having it as a wishlist item - and in the FAQ, I think is a good idea. Sadly, though, with developer time at a premium, don't hold your breath.
(In reply to comment #8) > I'm not an accounting expert, or any other kind either, but with the > double-entry principal, I don't think money can appear or disappear without > a transaction. Well, one solution would be reverting them to "unassigned" as they are when first created/imported. Another one would be assigning them to a default "imbalance" account as GnuCash does. > Having it as a wishlist item - and in the FAQ, I think is a good idea. > Sadly, though, with developer time at a premium, don't hold your breath. I'll play with it at my spare time, if I come up with something useful I'll shoot a message to you guys to look at it.
(In reply to comment #4) I attached a sample to the other bug I opened (https://bugs.kde.org/show_bug.cgi?id=312650#c11) with an account that has imported transactions that don't show on the ledger. It affects this bug as well, as such an account cannot be removed: the user cannot delete transactions he has no access to.
Investment accounts are particularly tricky, since the investment account itself holds transactions that increase or decrease the number of shares, while the associated brokerage account holds transactions that involve money. Those transactions (buy/sell/dividend) can only be created in the investment account, but create an appropriate entry in the brokerage account.
(In reply to comment #10) > (In reply to comment #4) > I attached a sample to the other bug I opened > (https://bugs.kde.org/show_bug.cgi?id=312650#c11) with an account that has > imported transactions that don't show on the ledger. It affects this bug as > well, as such an account cannot be removed: the user cannot delete > transactions he has no access to. You might need to check Settings/KMM/General/Filter and look at the 'Do not show transactions prior to.." box.
Jack and I have been in contact off-line as he noticed that the severity had been changed back from wish-list back to major, and wondered if I had done it, accidentally or otherwise. I hadn't, but I have now reversed it to wish-list again. However, might Vin have done it when raising comment 9 or 10?
On 2013.01.06 16:36, allan wrote: > https://bugs.kde.org/show_bug.cgi?id=312649 > > --- Comment #13 from allan <agander93@gmail.com> --- > Jack and I have been in contact off-line as he noticed that the > severity had > been changed back from wish-list back to major, and wondered if I had > done it, > accidentally or otherwise. > > I hadn't, but I have now reversed it to wish-list again. > > However, might Vin have done it when raising comment 9 or 10? Allan, I've already deleted the bugzilla message which included both comment 8 and the status change. Also, lok at the bug history. It's pretty clear to me it happened as part of comment 8 (same timestamp) which is why I think it is either a bug in bugzilla, or the UI isn't obvious enough about showing you that's what's going to happen as part of committing your comment. Jack
(In reply to comment #14) > On 2013.01.06 16:36, allan wrote: > > https://bugs.kde.org/show_bug.cgi?id=312649 > > > > --- Comment #13 from allan <agander93@gmail.com> --- > > Jack and I have been in contact off-line as he noticed that the > > severity had > > been changed back from wish-list back to major, and wondered if I had > > done it, > > accidentally or otherwise. > > > > I hadn't, but I have now reversed it to wish-list again. > > > > However, might Vin have done it when raising comment 9 or 10? > > > Allan, > > I've already deleted the bugzilla message which included both comment 8 > and the status change. Also, lok at the bug history. It's pretty > clear to me it happened as part of comment 8 (same timestamp) which is > why I think it is either a bug in bugzilla, or the UI isn't obvious > enough about showing you that's what's going to happen as part of > committing your comment. > > Jack Thanks Jack, yes, I have to hold my hand up - I hadn't noticed there was a history. And, I still have that list message showing the change. I did actually look for the change notification but obviously missed it. As I refer there to wish-list, I quite possibly checked for it and left the wrong setting behind. I'm happy to accept it was me rather than Bugzilla, or anything else.
If I did then its by mistake, bugzilla does that occasionally.
I'm a new user and also was unable to delete a new account that I'd added. I had no transactions and the option was still greyed out. It turned out that the problem was that I'd entered a monthly reminder (Scheduled Transaction) and that was preventing me from deleting the account. It would help if this was documented on the help pages. Maybe others will at least find this comment if they search. It would also be useful if, instead of having the Delete option greyed out, at least have it list the reasons why the account can't be deleted yet. I don't really understand why it couldn't automatically delete the constraints, but I suppose that was a design decision? Is there a different place I would go for feature requests?
On importing a .qif file from quicken4 into kmymoney4.6.4, credit cards were allocated as Assets. I managed to delete most of them but two refuse to delete. I have deleted all the entries in the credit card ("Asset") account, set the filter to 1/1/1899, ensured no scheduled transactions, but the delete function remains greyed-out.
On 25/07/14 02:05, OLFarCnArt@DSLExtreme.com wrote: > https://bugs.kde.org/show_bug.cgi?id=312649 > > OLFarCnArt@DSLExtreme.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |OLFarCnArt@DSLExtreme.com > > --- Comment #18 from OLFarCnArt@DSLExtreme.com --- > On importing a .qif file from quicken4 into kmymoney4.6.4, credit > cards were allocated as Assets. I managed to delete most of them > but two refuse to delete. > > I have deleted all the entries in the credit card ("Asset") account, > set the filter to 1/1/1899, ensured no scheduled transactions, but > the delete function remains greyed-out. > Might it be referenced in a Report? If so, you'll need to remove any references there. Allan
Is there anything actually left in this wishlist other than for the program to provide more complete and explicit information about why some account cannot be closed or deleted? If so, unless we want separate bugs for deleting/closing different types of accounts (since resolving them may require separate programming) do we want to change the subject to be more descriptive?
Almost another year and no additional comments, so I've changed the subject to reflect what is actually wished for, and adjusted the version and platform.
I will also add that there are other cases where KMM does not allow for some action, where it is often not obvious why. I'll just mention that now, but if only one gets solved at some time, a separate bug can be opened for each particular case. The current issue is not being able to edit a transaction - often because it has a split which references a closed account.