[GNC] Pending Edit Behavior in GnuCash

[John Ralls]

> On Jun 7, 2019, at 2:40 AM, David Carlson <david.carlson.417 at gmail.com> wrote:
> 
> 
> 
> On Thu, Jun 6, 2019 at 6:25 PM John Ralls <jralls at ceridwen.us> wrote:
> 
> 
> > On Jun 6, 2019, at 1:21 PM, Colin Law <clanlaw at gmail.com> wrote:
> > 
> > On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone
> > <adrien.monteleone at lusfiber.net> wrote:
> >> 
> >> 
> >>> On Jun 6, 2019, at 12:40 PM, David Carlson <david.carlson.417 at gmail.com> wrote:
> >>> 
> >>> Adrien,
> >>> 
> >>> Looking at your comments, I have two questions.
> >>> 
> >>> 1. Does SQLite not allow pending edits at all? or is it after every keystroke?  How do you avoid accidental deletions?
> >> 
> >> Not sure specifically what you mean by ‘pending edits'. I think writes are supposed to be instant, but I haven’t tested exactly how ‘instant’ —as by keystroke, Tab, or Enter as a commit. I don’t know that I’ve accidentally deleted something critical, certainly not an entire transaction. I might have inadvertently changed an account assignment to something I didn’t want, or selected an entire memo and deleted it when I only wanted to delete a portion of it, but that is an easy fix, especially as I’ll notice it immediately. (I wish CMD-Z ‘undo’ worked though - since it doesn’t, perhaps writes are by keystroke?) As long as the app is still open, I just make any changes I need. I’m not prevented from doing so. (I also keep the app open 24/7 and only close to do an update of GC itself, or the OS)
> > 
> > I believe the transaction is not saved until you hit that last Enter
> > key to do it.  There is, after all, a Cancel button at the top that
> > allows one to revert the transaction being edited back to what it was
> > originally.
> 
> Mostly right: Committing the edit immediately generates a database update. If it's editing an object with a dialog box (including transactions with the Transfer Dialog) then clicking the OK button commits. For transactions in the register, it's hitting Enter, tabbing off the end, or clicking on a different transaction and then confirming the edit in the message box.
> 
> Does this mean that it is still possible in a SQLite database to start a transaction edit, then, without committing it, navigate to another account register and edit another transaction?  If so, when does the first transaction edit finally get committed?  The difficulty with finding those un-committed edits in the XML data version is the reason for my 'blinking' proposal.  
> 
> The method that I currently use is to start a manual File  > Save, then, if there is a pop-up indicating a need to save or cancel an edit, try to guess which tab I need to look under for the offending edit,  When I think I have the right tab, press the Tab key to see if I am in the un-committed transaction.  If the warning re-appears, I am there.  If not, maybe it is in another tab, perhaps a search tab.  This is hardly efficient. 
> 
> It would also be helpful if any transaction edit action somehow changed the appearance of that transaction so that the need to commit is more obvious.

Yes, it's possible to do that, regardless of backend. Perhaps not a good idea if you typically keep a lot of tabs open and can't keep track of working on more than one transaction at a time.

In the SQL backend case you can't force a save so the only way to get the warning is to quit GnuCash or change books (e.g. File>Open). Since at this point you've already forgotten what register you were working in you can also visit each open register in turn and click a transaction other than the one with focus. If the one with focus was being edited you'll get a dialog box.

Regards,
John Ralls