[GNC] Auto commit with auto save?

[David G. Pickett]

I use auto save, and if the app is running, the cron kills it and removes the lock before running the quote fetch.

One can imagine the app having a listening socket to let you ask it to get quotes from a cron script.  Or having it maintain a schedule where it gets all quotes, like an internal crontab.


-----Original Message-----
From: David T. <sunfish62 at yahoo.com>
To: David G. Pickett <dgpickett at aol.com>
Cc: David G. Pickett via gnucash-user <gnucash-user at gnucash.org>
Sent: Sun, May 7, 2023 11:34 pm
Subject: Re: [GNC] Auto commit with auto save?

Nope and nope. Sorry. 

It seems to me that leaving GnuCash open and running a con job against the open app is a recipe for troubles just like the ones you have encountered. You could tell the script to abort if it found the lock file, but that would require you to close the app every night, which you're not doing now. 

David T. On May 7, 2023, at 9:25 PM, "David G. Pickett" <dgpickett at aol.com> wrote:
 Any suggestions on a) how a shell script tells that the auto save is incomplete, b) even if it knew, what it could do about it? 
 
 
  -----Original Message-----
 From: David T. <sunfish62 at yahoo.com>
 To: David G. Pickett <dgpickett at aol.com>
 Cc: gnucash-user at gnucash.org
 Sent: Sun, May 7, 2023 1:28 am
 Subject: Re: [GNC] Auto commit with auto save?
 
    I agree that it would be nice to have some visual cue that a transaction has been edited but not saved; that would be useful. I'm honestly not sure why that hasn't been implemented. 
 
  The app does throw a dialog onscreen when a user tries to save with an open transaction. Unfortunately, the message is generic, and a user is forced to look through the open tabs and try to figure out which register holds this transaction. Others have commented on this in the past. 
 
  If I recall correctly, you were having trouble because you have a cron job set up to retrieve quotes at a specified time each day, and this job causes the file to close dirty if there is an open transaction. The problem in this case, is that this cron job doesn't have necessary fault testing and tolerance. I'd suggest working on ensuring that this cron job was properly set up to handle your specific situation. 
 
  David T.  On May 6, 2023, at 9:02 PM, "David G. Pickett via gnucash-user" < gnucash-user at gnucash.org> wrote: 
 "Don't do that!" does not prevent data loss from human error, which for this app behavior is too easy to create and not realize.

         
 
If the commit was automatic every time you modified a transaction when the new state was valid, then I would not leave the tab in an uncommitted state, but that is not how it was devised.  I leave because it looks fine.  There is no indication of an uncommitted transaction I can see.  In terms of human factors, one might go to another tab for information to complete a transaction, so we do not want to prevent the user leaving a tab with an uncommitted, possibly invalid transaction.  Maybe we should color the tab red while in this state?  Or pop up a dialog if it persists a bit too long, or if auto save fires on its timer?  But the user may have left, trusting in auto save, so I suggest an auto commit if valid on auto save. 
 
gnucash-user mailing list 
gnucash-user at gnucash.org 
To update your subscription preferences or to unsubscribe: 
 https://lists.gnucash.org/mailman/listinfo/gnucash-user 
----- 
Please remember to CC this list on all your replies. 
You can do this by using Reply-To-List or Reply-All.