GNOME Bugzilla – Bug 723216
Cannot change the accounting period using the pop-up calendar (date picker) tool.
Last modified: 2018-06-29 23:25:37 UTC
In GNU Cash 2.6.1 (first seen when I upgraded to 2.6.0) running on Windows Vista Home Premium and service pack 2, I go edit -> preferences -> end date -> absolute change the end date and then close the dialogue box. When I go edit -> preferences the end date has not changed.
I can confirm this in Linux too but, It onlt seems to occure if I use the date-picker to set the date. If I manually type the date then it works as it should. Changing the start data shows the same behaviour. Stephen: Can you try changing the date manually, not using the calendar tool, and see if it works for you? Also confirm with the start date.
I can change the start and end date manually, not using the calendar tool.
Then it appears to be an issue with the calendar tool.
*** Bug 723710 has been marked as a duplicate of this bug. ***
I've come across something similar in the transaction scheduler. A scheduled transaction suddenly stopped last month so I checked the scheduler and found the date had expired. I clicked on the the "forever" button for last occurrence and thought no more about it until I found the transaction missing again this month. I tried the same button, saved it, went back and found it still set to "until" instead of "forever". I've now got round it by setting "until" to sometime in 2059 which, as I'm 69 years old, should see me out. I'm running version 2.6.1 on openSUSE 13.1, KDE 4.12.2.
(In reply to comment #5) > I've come across something similar in the transaction scheduler. A scheduled > transaction suddenly stopped last month so I checked the scheduler and found > the date had expired. I clicked on the the "forever" button for last occurrence > and thought no more about it until I found the transaction missing again this > month. I tried the same button, saved it, went back and found it still set to > "until" instead of "forever". I've now got round it by setting "until" to > sometime in 2059 which, as I'm 69 years old, should see me out. > > I'm running version 2.6.1 on openSUSE 13.1, KDE 4.12.2. I can replicate this on OSX as well, but it's really a separate bug.
(In reply to comment #6) > (In reply to comment #5) > > I've come across something similar in the transaction scheduler. A scheduled > > transaction suddenly stopped last month so I checked the scheduler and found > > the date had expired. I clicked on the the "forever" button for last occurrence > > and thought no more about it until I found the transaction missing again this > > month. I tried the same button, saved it, went back and found it still set to > > "until" instead of "forever". I've now got round it by setting "until" to > > sometime in 2059 which, as I'm 69 years old, should see me out. > > > > I'm running version 2.6.1 on openSUSE 13.1, KDE 4.12.2. > > I can replicate this on OSX as well, but it's really a separate bug. Sorry, I assumed the two problems I had in setting dates must be related in that something was failing to be stored correctly. Anyway, my fix triggered the scheduler to insert a dozen monthly events of the transaction dating from almost a year ago; just glad I spotted it and was able to delete them before more damage was done. I'm now wondering whether I should raise this as a single new bug or two, I suspect the latter as it seems I now have three unrelated date-related problems.
Well, the failure to save the "forever" or "fixed number" selections once the SX has been set to a fixed date clearly has nothing to do with failing to set a change in the accounting period from the calendar. That's a new bug. The appearance of extra new transactions needs a little more explanation, and you might not remember enough detail: What was the old expiration date and what were the "last occurred" date and "start date" (the last is on the second tab) when you re-saved the SX? It's possible that the scheduler was working correctly when it created those "extra" transactions.
Well, I found the problem with the SX editor "Forever" problem, and that's fixed in master (9f5d62d47f), so it will be in 2.6.2. The original problem is a bit harder and I'll probably need Geert's help.
Found this problem, too: The GncPreference is bound to the "time" property of GncDateEdit. If the property isn't set in a way that emits the "notify" signal the binding doesn't know that it should change its value. It wasn't getting set. 511a556 ensures that it is.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=723216. Please update any external references or bookmarks.