In at least versions 3.4+, attempting to change the description of a transaction with reconciled split(s) gives a warning, and the intended behaviour is to unreconcile all splits upon change. See 797084 and https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081797.html for discussion. This behaviour is itself inconsistent. To reproduce the bug: 1. have a transaction with a reconciled split (additional splits can be reconciled) 2. open the account where a reconciled split is 3. attempt to edit the description (warning for changing a transaction with a reconciled split expected) 4. show all transaction splits 5. move the cursor to any field in one of the split lines (i.e. away from the main transaction date/num/description fields 6a. close the account window (it will ask to save and you can say yes) 7a. the transaction description is changed and no splits will be unreconciled 6b. if you click on a different transaction while the cursor is on a split line, the editing of the original transaction is still open (going back and further changing the description triggers no warning) 7b. additionally, if the cursor was moved from a split line of the original to a different transaction (with no changes to the second transaction), closing the account window from this state saves the changed description, no unreconciliation, without prompting to save Given that I hate the intended behaviour and heavily use this bug to workaround unreconciliation, I'm merely documenting and explicitly requesting it not be fixed. PS: 1. this process also allows changes to *the reconciled split amount* to bypass unreconciliation, which is a bit more serious 2. directly attempting to change the reconciled split amount generates a different warning (changing protected field of reconciled split), and on clicking yes it immediately unreconciles the split 3. to bypass, attempt to edit a transaction-level field, accept warning, move cursor to the reconciled split amount, edit, exit window 4. if the edit causes a new split to exist (say imbalance), that *will* unreconcile the split 5. with an edit that causes a reconciled split amount to change, on a further reconcile action the opening balance is appropriately changed, so at least this doesn't break the world
(linkify bug 797084)
Bug 797084 is fixed in the about-to-be-released GnuCash 3.9. Does that resolve your concern?
To answer myself, it doesn't. This problem was reported on gnucash-user recently and is easily reproduced: In split mode, change a reconciled split so that it becomes unreconciled. The reconcile column will change from y to n. Tab out of the split (don't use enter/return) and the column will change back to y.
I've fixed the easy part, making sure that the split information gets updated before the transaction is committed in gnc_split_register_save. There's another piece, though: The *display* of the reconcile column changes from n back to y if one moves to another split in the same transaction, even though the recncell value remains n. @Bob-IT, any ideas?
