> On Aug 9, 2020, at 3:59 PM, Stan Brown <the_stan_br...@fastmail.fm> wrote: > > > On 2020-08-09 11:58, John Ralls wrote: > >>> On Aug 9, 2020, at 11:04 AM, Stan Brown <the_stan_br...@fastmail.fm> wrote: >>> You probably know this, but just on the off chance that you don't: >>> >>> In the File ยป Properties dialog, there is a setting "Day threshold for >>> read-only transactions." If change the default 0 in that box to a >>> number, then transactions more than that many days before today can't be >>> edited. >>> >>> It would be a lot more useful if we could set a date, in my opinion, but >>> it's better than nothing. > >> Really? ISTM that would be painful to use because you'd have to frequently >> change the date. I could understand if you wanted to be able to set a period >> selector, e.g. all transactions before the beginning of the current month >> are read-only. > > This may be a matter of different users having different use cases. > > Mine is straightforward (to me): Following Adrien's recommendation, I > don't actually close each month. But I want to make sure that I don't > inadvertently fumble the date of a new transaction and put it into last > month, or accidentally change a transaction of last month because of an > errant mouse click. > > As GC is set up now, to achieve that I would have to change the number > of days every day, which is, as you say, painful. If I could just setO > "no alterations of anything dated 2020-07-31 or earlier", that would be > quite simple, and I'd only have to change it once a month. > > What's your use case for setting number of days, if you're willing to say? > > (I'm not suggesting removing the number-of-days setting, if there's any > reasonable chance someone actually wants it. But surely it would not be > hard to add a "freeze transactions before specified date" setting, and > unless I miss my guess it would prove to be more popular.)
I don't personally have a use-case for the number of days, but I think that it's pretty obvious: Once a transaction is N days old it's considered committed and shouldn't be changed, and transactions should be entered within those same N days of happening in the real world. It's pretty much the topic of this thread. I think my proposal--using relative dates like beginning of the current month--fits your use case perfectly and would save you the annoyance of having to update the specified date every month and the risk of possibly forgetting. Regards, John Ralls _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
