GNOME Bugzilla – Bug 152101
problem with modifying accounts when there is a open register
Last modified: 2018-06-29 20:46:57 UTC
I find that if I open a register and then I modify the account tree, the changes aren't known by the open register. Reproduce it this way: gnucash --nofile create accounts 1 and 2 open account 2's register enter a txn between 2 and 1 without closing 2's register, go and add a "21" child accounto to 2 go to 2's register enter a new txn, and in the account field type 2: the drop-down account list doesn't show account 2.21 !!!! However, if now you hit ".", account autocompletion shows 2.21 in the account field (correct!). Unfortunatly, hitting tab, the account name disappear from the account field. After closing 2's register and reopening it, the account tree is known entirely
Yes, Linas introduced this behavior when he "fixed" your speed issue....
Yep, and keeping the menu in sync in this way would have been quite hard, requiring a lot of extra complexity for what seemed like a small gain. I agonized about it, if that counts :)
Ideally we just need more events so we can differentiate between an account having actually changed meta data (name, etc.) versus an account having its contents changed (new transactions). Then we can refresh the menu when we receive the former event but ignore the latter events.
I think that the stuff could be treated in a very simple way: simply introduce a flag that is set by those operations that modify the account tree. Then, register operations could check the flag: - if the flag is unset, work as is now in 1-8-branch - if the flag is set, work as before Linas' fixing, i.e. reading the entire accounts tree. The problem would be: who resets the flag? - it could be reset by the same register, if this register is the only opened register - when a register is closed, it resets the flag only if there aren't other registers opened. Other approach: every opened register defines its flag. When you change the tree, every open register flag is set. When a register performs an operation, it performs it the new way if its flag is unset. On the contrary, if its flag is set, ti performs the operation the old way and then resets its flag.
You've pretty much just re-designed the existing event system, except not as well. This is effectively exactly what I proposed above, extending the existing event system and adding more events to differentiate between metadata changes and content changes. This distinction is definitely appropriate for Accounts and Invoices. It may be appropriate for Transactions (add/remove Split) but I'm not completely convinced. A simple flag just doesn't scale, and to make it scale you effectively rebuild the event handler system.
Is there someone willing to work on this?
I dont have the time myself.. At least not in the short term.
There will be no future releases of the 1.8 series of gnucash. This has been fixed for the upcoming 2.0 version and the fix will first appear in the 1.9.3 release.
*** Bug 302682 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=152101. Please update any external references or bookmarks.