GNOME Bugzilla – Bug 327780
Growing number of 0 valued transactions in Orphan-NNN account.
Last modified: 2018-06-29 20:55:58 UTC
Please describe the problem: When an account is opened it creates a 0 valued orphan transaction (probably the the last transaction in the register used as a temple for new entries) When you quit gnucash while this Steps to reproduce: 0. save a copy of you file. 1. Start gnucash 2. Open some accounts An orphaned transaction is created for each open. 3. Quit gnucash You will be asked if you want to save even though no changes have been made. The orphaned transaction will be saved. compare file with save file. transaction count has gone up by number of open accounts and as many empty tranasction have been added. 4. start gnucash New orphaned transaction will be created for each open account 5. Open Orphan-NNN were NNN is currency of the open accounts You will find the saved entries plus one for each open account Actual results: Expected results: These template transactions should not be saved or require a save. Does this happen every time? Yes Other information: This has been present in all SVN versions I have built. Current test on r12903
Yes, I've noticed that, too, and it's quite annoying. Should be fixed until 2.0.0 release, but since this is neither a crash nor data loss it's okay if the first 1.9.x releases still have that.
I can confirm this problem on gnucash-1.9.0.
I know why this is happening, but I don't know the best way to fix it. When a register is opened gnc_split_register_load creates a dummy transaction with a single zero-value split as a place holder for a new transaction that might be entered in the register. It (incorrectly, probably) does not assign this split to the account. When it calls xaccTransCommitEdit on this new transaction this split gets added to the Orphan-XXX account since it has no account. The key thing that has changed in this since 1.8 is that xaccTransCommitEdit has been changed to call xaccTransScrubImbalance on the transaction. In the past it did some scrubbing itself, but didn't call xaccTransScrubImbalance. I suspect these bogus transactions weren't getting saved before since the split wasn't in any account, but I haven't verified that. Making gnc_split_register_load assign the split to the account avoids creating the Orphan-XXX accounts, but the dummy transactions get saved in the target account instead which is not an improvement. There is a back door way to avoid the scrub in xaccTransCommitEdit. If you wrap the call to xaccTransCommitEdit in calls to xaccDisableDataScrubbing and xaccEnableDataScrubbing, then the dummy transaction isn't scrubbed (which is more like the 1.8 behavior). This definitely is not a solution, but it partly avoids the problem. The file is still considered dirty (so you get prompted when you quit), but the dummy transactions and orphan accounts are not written to the file. A better solution might be to change the register code to not create the new transaction until the user actually starts to edit it, but this would be a significant change in the architecture of the code and probably would create as many problems as it solved.
Upping severity.
This is still a problem in r13640. I thought it had been fixed for a while, but it's certainly still an issue. A good way to reproduce this problem: Start gnucash Open a register Quit Gnucash it will ask if you want to save. restart gnucash and exit immediately. again, it will ask if you want to save.
*** Bug 337194 has been marked as a duplicate of this bug. ***
*** Bug 337185 has been marked as a duplicate of this bug. ***
Marking this as a blocker for the release of 2.0.
Quite possibly fixed in r13834. Please test and report.
I'll try to test it, but a simple test you can try: 1) Start gnucash 2) Open a register 3) Exit gnucash Does it ask if you want to save your changes? If yes, then no, you haven't fixed it.
If you follow the steps in comment 10, it does ask you to save changes. I tried this with a file that did not have any orphaned currency accounts or any of the bogus transactions created by this bug and when I saved the file none were created (the new file was identical to the old one). The bug seems half fixed: the transactions aren't created but the file is considered dirty anyway, or perhaps it's dirty for an unrelated reason. This is with r13835.
The instructions in comment #10 aren't for testing this bug. There are many reasons why the book may incorrectly be marked dirty, some of which don't even involve the register at all, (and some of which do). I don't plan on addressing the fact that opening a register dirties the book any time soon. It would require even more intrusive modifications. This bug is only about the fact that orphaned splits are commited when you open a register, (and at other times when they shouldn't be). Now, it's not hard to avoid creating the orphaned splits - any of the suggestions in comment #3 would work. However, it's quite a bit more difficult to avoid creating the orphaned splits without horribly breaking something else (as I did in r13834, it turns out). So, what I really need help with testing is not so much are the orphan splits gone, as much as did I break anything else. Oh, and FTR, I pretty much think the register code is an abomination. I've got another attempt I'm testing now, and should be able to commit tonight. Stay tuned...
Ok. I've tried again in r13844. Please let me know if this breaks anything new.
If comment #12 indicates that this isn't going to fix the book dirty problem, then we should reopen bug #337185. I have done so. But I'll note that I mentioned this same problem in comment #5 and people agreed that it was a related problem. I still think it is, but if you want to separate them out I'm glad to re-open #337185 and make IT a blocker, too. It really is a usability problem when gnucash thinks data needs to be saved when the user hasn't DONE anything but read their data.
I think something is still broken. When I tested it in my simple test file it seemed to work ok, but when I tried to enter a transaction in a more complex file it had the problems described before where I had trouble getting it to record the transaction and when it did record it the balance on the transaction was set to zero. I can't seem to reliably reproduce this problem, but it was definitely happening a few minutes ago in r13845. It seemed to have more problems if the view mode is set to Basic Ledger.
Yes, basic-ledger mode wasn't working too well. This has hopefully been fixed in r13863. Please re-test.
It seems to be working better in r13865. I haven't done a lot of testing, but things that didn't work before seem to work now and I'm not getting the zero-value orphaned transactions. The file is still dirty immediately after it is opened, but this is probably unrelated to this bug.
I'm not convinced that the dirtying of the file is unrelated to this bug. It may be related. It may not be related. But I don't want to write it off as unrelated to this bug quite yet.
Well, this bug _is_ related to dirtying the book in the sense that, if opening a register creates orphan Splits, then the book is certainly dirtied. However, there are other ways the book can be dirtied. It looks like bug #337185 was caused by the creation of the PriceDB, but is now fixed. I don't think it's helpful to turn this bug, or #337185, or even a new bug into an over-arching "book incorrectly marked dirty" bug. Different actions can incorrectly dirty the book and be unrelated bugs that happen to have the same effect. So, please open a new bug that describes a specific sequence of actions that incorrectly dirties the open book. I'm optimistically closing this bug, because I haven't seen an orphan split for days, and I'm hoping I've fixed-up all the fall-out from the original bug-fix. Let's reopen this if either a) orphan splits show up when they're not supposed to; or b) the current fix in r13863 has some other effect that makes it unacceptable.
Okay, I opened a new report, bug #339943, for the fact that opening a register still dirties the book in r13866.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=327780. Please update any external references or bookmarks.