I see that <Bug 796978 - Deleting a split of same account as register cancels the transaction without warning> appears to be similar but I think it is different, at least as described therein. In releases prior to release 3.4, anyway, if an existing transaction has only one split line associated to the 'home' account or current register view account, and that account name is deleted, all pending edits to that transaction are committed, including deleting that split line and,thus causing the transaction to disappear from the current account register view. There is no warning, no option to cancel. If this was done prematurely, or in error, it would be necessary to navigate to some other account register that still shows that transaction to continue editing that transaction. I think this action should require a warning similar to (but not the same as) other delete actions.
Created attachment 373286 [details] Dialog preventing deletion of the "home" split. Not quite. As the screen shot shows, GnuCash won't let you do that with the Delete button. The problem you described on IRC is a bit different, it's that the Transaction>Cut Split menu item and associated accelerator don't trip that check.
I could have described the bug better. Any action that results in the 'home' split disappearing and the entire transaction disappearing from the register view should trigger that warning. So if that account name is edited within the transaction and some action such as tabbing off the line would trigger the commit and disappear action, it should instead trigger that warning. Actually, I have been afraid to try the various edit split menu items, when they are documented we will know if they properly trigger that dialog. I am still using release 2.6.19 so I cannot test anyway.
You don't really want that, do you? That means that if you're looking at an account and see a transaction that belongs somewhere else you have to switch to one of the other accounts in that transaction to fix it. The obvious use-case where that would be an unwelcome pain is an imbalance account. Even if you do want it it's a major behavior change that needs to be discussed on the user list. Also, remember that if you delete the account from a split and then commit the transaction the balancing code will just put the split in the appropriate imbalance account. If you delete the whole split it will create a new one there. Annoying to be sure but not catastrophic.
Yes, I do want that, because there is a way to assert that I am done editing by using the Enter key instead of the tab key. If I have not hit the Enter key, Gnucash should assume that I am not done editing and it should not commit.
Created attachment 373287 [details] Save the Changed Transaction Dialog You're asking for two major behvior changes: Blocking changes to the "home" split's account and automatically committing only on <enter>, not by tabbing out of the last split (do what instead?) or clicking in a different transaction (currently raises the "Save the Changed Transaction" dialog, see this screenshot; again, do what instead?). Those fundamental changes to GnuCash's behavior need to be discussed in the user list and after getting consensus each converted to a separate enhancement request. Let's focus this bug deleting the home split with the delete button raises the blocking dialog and that deleting with the cut action doesn't.
OK I agree that this is a complicated issue so if we limit this bug to fixing the cut action then I need a path to address my core problem. I will create a new bug report for that.
No, you'll bring it up on the user list as a proposed user interface change and make a case for it. Nowhere near enough users use the bug tracker to get a good sample of opinion. Ideally you'd also recruit others to discuss it on the various not-English lists. Once you've gotten some sort of consensus there *then* you can write enhancement requests.
Note that I think it is absolutely important to be able to change the account of the anchoring split. This means, of course, that Cut needs to continue to work, but I do agree that "delete" should probably be blocked, or at least otherwise "warned".
I got distracted so I have not completed my user interface comprehensive proposal which would roll up this and several other awkward UI artifacts into one streamlined update. They mostly revolve around how Gnucash handles pending edits when they have not been properly closed, including when the user leaves the register containing a pending transaction edit. I wanted to present my case in the user forum as John suggested. I don't want to propose something that prevents changing account assignments.
I have had a look at this and pushed some changes that will be in 3.6 as follows... First disable the menu options that do not apply to read only transactions and voided ones. The second part is to add the warning to the cut option for anchor splits and reconciled ones. Prevent pasting on an anchor split with message really for the same reasons as cutting/deleting. Changed split paste so it can be cancelled. The down side is that if the transaction is already being edited you can not paste but I thought that was better than not being able to cancel it. The last fix is one I have been looking for ages, making the blank split read only when the transaction is read only. You can still manually change the anchor split from the register without a warning but as the change still needs confirmation it gives you a chance to recognise a mistake. I think this covers the original request, please confirm and close if correct.
In the user mail discussion I did not yet bring up a new thought that occurred to me as I re-read this bug. If there were a permanent menu link in the register view to open the current transaction in the Journal view where there is no anchor split line, then there would be an easy path to a place where anchor split edits are much less troublesome. I know that is not what this bug is about, so I will bring it up there. However, that may be a way to accept an imperfect fix for this bug. Since I currently cannot test releases in the 3.x family I will not be able to test Bob's changes. I leave that to others.
Are we perhaps getting muddled about double entry accounting ? A debit and a credit is what it is about, the other stuff is extra :)
As noted in comment 10 Bob fixed the underlying bug.
