After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760107 - When entering a new transaction, if the end of year is upcoming, entries for January should default to the next year
When entering a new transaction, if the end of year is upcoming, entries for ...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Register
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
Depends on:
Blocks:
 
 
Reported: 2016-01-03 23:46 UTC by manekineko
Modified: 2018-06-29 23:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description manekineko 2016-01-03 23:46:55 UTC 
I just saw this come up when entering this entry: https://bugzilla.gnome.org/show_bug.cgi?id=566175

However, while it's nice that I managed to reconfigure Gnucash to behave in the correct manner, defaulting to the unintuitive result and then burying the sensible option in the preferences is a bad user experience.

When it's 12/31/15 and someone enters a transaction to pay their credit card on 1/5, they don't mean 1/5/15, they mean 1/5/16.

Little sore points like this really make me pine for MS Money I used to use. I shouldn't have to dive into an issue tracker and then program obscure settings to just make Gnucash behave sanely. I believe the correct approach is something like the alternative setting, set to 11.
Comment 1 Geert Janssens 2016-03-19 17:30:47 UTC 
That certainly is a reasonable idea I didn't consider when accepting the patch.

While I agree the default behaviour of completing dates in the current year is not optimal and confusing to users coming from MS Money, this has always been the default behaviour in gnucash and is by no means a gold standard. I have used many professional accounting applications that don't do this either. In addition it would be an equally bad user experience for existing users if we would change the way gnucash behaves without the user explicitly changed a setting.

Hence the choice of the current situation.

Having said all that I agree we can do better. I intend to be conservative for minor stable releases (from for example 2.6.x to 2.6.y), but IMO it's ok to change default behaviour in major upgrades (like 2.6.x to 2.8.x) provided the change in default behaviour is clearly documented in at least the release notes.

So for 2.8 I will change the default to a sliding window.

I have also added some notes to our documentation about the partial date completion behaviour on gnucash the make it easier for people to figure out how to customize it.
Comment 2 John Ralls 2018-06-29 23:45:48 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=760107. Please update any external references or bookmarks.