Under Edit Scheduled Transaction, click Template Transaction, attempt to edit a value in any field of the transaction then move focus to another line throws an error: "This transaction is already being edited in another register. Please finish editing it there first." Since it's a scheduled transaction, it seems illogical for the transaction to be open in another register. The workaround is to delete the transaction from the SX editor window and re-add it, but this is not ideal because many of my SXs have multiple transactions in a particular order.
*** Bug 796249 has been marked as a duplicate of this bug. ***
Additional steps to recreate: Create new SX; close GnuCash; re-open GnuCash. Edit SX template transaction. I tried: *Create SX; edit template. Editing allowed *Create SX; Run SX; edit template. Editing allowed *Create SX; Run SX; Close/re-open Gnucash. Editing NOT allowed *Create SX; Close/re-open Gnucash. Editing NOT allowed
I'm getting the same error, on Windows 10. Version 3.1, build 3.0-118-gd2ef5fd0f+ (2018-04-28)
*** Bug 796568 has been marked as a duplicate of this bug. ***
I can't replicate this at all, there must be something about the transaction. Can someone post and example SX that exhibits the problem?
Created attachment 372664 [details] sample database for demonstrating the bug
The attached database was created from scratch. I created a transaction in the Cash in Wallet account, scheduled it, closed and reopened to create one transaction at startup. I've closed and re-opened since then. In the database as is, go into Actions, Scheduled Transactions, Scheduled Transaction Editor. Double-click the single transaction in the list. Click on the Template Transaction tab. Change the Debit Formula amount to 5, and hit enter.
Aha! A SQLite3 database. Withholding evidence...
You should know from bug 796369 that I'm using sqlite. :-) Sorry - in hindsight it's obvious that I should have included it in comment 3.
And with that one little bit of extra information, the fix is in. It will be in tomorrow's nightly and in 3.2.
That's great news! I can confirm that it works fine now.
Created attachment 372752 [details] Sqlite based book containing business data which results in an abrt. Unfortunately this commit now causes gnucash to abort when loading business data from an sqlite based book. I can consistently make it crash with the attached sample book on Fedora 27. A git bisect reveals https://github.com/Gnucash/gnucash/commit/ffe6044cd66edf39ae22875ef475d8e655b93526 (the fix for this bug) as the source of the abort.
Created attachment 372754 [details] Stacktrace from crash I did a clean rebuild of gnucash on the bad commit and ran it through gdb to create this stacktrace. It aborts in gnc_split_set_property. This particular call to gnc_split_set_property attempts to (re)set the parent of the split. But there's a guard that if the split parent exists it should be marked for editing. This assumption if clearly false in this case. It used to be true before this commit due to the extra xaccTransBeginEdit that got removed in this commit. I'm not sure how this should be handled. I hoped that skipping the assert in case the property to set is PROP_TX would fix this. It does fix this particular assert but it will crash on the next property for the same split as the parent is still not in the correct edit level. Instead of asserting on the correct edit level, shouldn't we just increase and decrease the edit level ourselves here ? But that may create a performance bottleneck...
As it's a crasher now I'm raising severity. If we don't find the proper solution before 3.2, we probably should revert this commit and pick up the issue again for 3.3 because a crash is worse than not being able to change an SX in an sql based book.
I agree and I've reverted that commit. I suspect that the problem here is that there aren't any splits in a template transaction; the split information lives in slots attached to the transaction. Either the BeginEdit needs to be conditional on the transaction not being a template transaction or there needs to be a corresponding CommitEdit for template transactions somewhere.
I've redone removing the extra xaccTransBeginEdit and avoided the problem of the assert while re-adding the splits by checking the splits to see if they're loaded already so that they're loaded only once.
Ah, that's a clever analysis and solution. Works fine now here as well.
I built 3.2 from source and installed this morning, but I still am experiencing the same issue. Version: 3.2 Build ID: 3.2+ (2018-06-24)
Yes, unfortunately I had to revert the first fix to prevent Geert's crash. I didn't get the fixed fix committed until after releasing 3.2, so you won't see the fix until 3.3 unless you want to build GnuCash from git.
Oh, sorry, I didn't catch that your latest fix was after the 3.2 release. Thanks for the update!
*** Bug 796834 has been marked as a duplicate of this bug. ***
*** Bug 796866 has been marked as a duplicate of this bug. ***
