GNOME Bugzilla – Bug 166101
Register: Topmost split's accounts are rewritten confusingly
Last modified: 2018-06-29 20:49:39 UTC
Please see http://bugs.debian.org/293360 which has a concise and correct recipe to see the bug. I have verified this in Debian gnucash 1.8.10 and unmodified 1.8.10. I cannot build the current gnucash 1.8 branch CVS (if you want to help me get it building, let me know; ./autogen.sh crashes impressively), but no post-1.8.10 changes look like they could be relevant.
Copying the description from the debian bug: Package: gnucash Version: 1.8.10-4 Summary: when I'm entering a split transaction, gnucash will sometimes change the accounts of individual split items that I've already entered. Here's a reproducible example of what I mean. Say that I'm depositing one check from Bob and another from Joe. I open up the register of the account into which the deposit is taking place, say "Assets:Checking". Then I hit the "split" button to open a split transaction, make a note in the memo, and tab to the first split entry. I enter "Check from Bob", an income account (say, "Income:Gifts from Bob"), and the amount of the check, $20 (in the "withdrawl" column, of course). When I tab off that item, the "Deposit" column of the next item is filled in with $20. I enter "Check from Joe", an income account, zero out the "Deposit" column, and enter $20 again in the deposit column. Here's the bug: when I tab off of the "Check from Joe" item, the "Check from Bob" item (the first one I entered) suddenly changes to be a withdrawl from "Assets:Checking" rather than from "Income:Gifts from Bob"; that is, its account is changed to the account whose register is being edited. All is OK if I enter the deposit first, perhaps because the deposit is a deposit into the "current" account, so when the alteration takes place it's a no-op.
I can confirm this bug happens for me as well. I'm using version 1.8.9 on gentoo.
I just realized that I filed a dup of this bug a few days ago. So, I'm confirming this is still present in 1.9.2
*** Bug 334926 has been marked as a duplicate of this bug. ***
*** Bug 166610 has been marked as a duplicate of this bug. ***
*** Bug 301264 has been marked as a duplicate of this bug. ***
*** Bug 309765 has been marked as a duplicate of this bug. ***
I'm bumping the priority and severity a) because this has been filed many times, b) to increase the awareness of this bug so as to discourage dups.
just confirming still here in 2.2.4
Hi, please check out the attached patch and test it thoroughly. I guess I will use it productively to see whether it breaks anything, but it is rather late today already. After a lot of staring at code and cursing about the total lack of *any* sensible documentation of the register, I finally realized that the blank_split is not per se a blank split, but just the split normally associated with the current register account in the blank transaction, i.e. the one bottom-most. This split is hidden in basic ledger mode and the top-most in auto-split ledger or transaction journal mode. If you edit this blank transaction, the account of the first split is very often replaced by the register account in gnc_split_register_save(). There seem to be two exceptions: (1) You changed the account of the blank_split when leaving it (2) You did not change anything at all You will notice that even if you selected a different account for blank_split it will be reset once you change anything in another split and move the focus to a third one. Fortunately, there is a flag for changes to this split and the attached patch makes use of it to avoid resetting the user's modifications.
Created attachment 108154 [details] [review] First try
Applied as r17077 and marked for backport to branches/2.2. This is still open for comments and needs regression tests :-)
Anyway, applied to branches/2.2 as r17136 for GnuCash 2.2.5. Thanks for the patience.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=166101. Please update any external references or bookmarks.