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 689092 - Make general ledger show transactions in timeperiod longer than 1 month
Make general ledger show transactions in timeperiod longer than 1 month
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: General
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Christian Stimming
Geert Janssens
Depends on:
Blocks:
 
 
Reported: 2012-11-26 16:25 UTC by Wang Xiaozhe
Modified: 2018-06-29 23:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
This patch make general ledger show transactions in the current whole year instead of just the last month (798 bytes, patch)
2012-11-26 16:25 UTC, Wang Xiaozhe
needs-work Details | Review

Description Wang Xiaozhe 2012-11-26 16:25:28 UTC
Created attachment 229914 [details] [review]
This patch make general ledger show transactions in the current whole year instead of just the last month

General ledger is frequently used handy tool. Current GNUCash only show transactions happened in the last month, which is inconvenient when users want to review older transactions.

Could the default timeperiod be changed to the current whole year instead of just one month? I just made a patch to do this in attachment.
Comment 1 Geert Janssens 2013-02-28 11:49:11 UTC
Comment on attachment 229914 [details] [review]
This patch make general ledger show transactions in the current whole year instead of just the last month

Thank you for your patch and my apologies that no one responded to it earlier.

I don't know what to do with this patch to be honest. I understand that one month of transactions in the ledger doesn't work for your use case. But I fear that your alternative will equally not work for other use cases.

I think a more elegant solution would be to improve the filter dialog. It currently has no support for relative time periods, like "last month" or "this year". Adding it in there would certainly make it more usable for many.

Especially if you  combine this with the new option in the development series to save your preference, everyone can configure the date range that suits him/her best.

For now I have set the status to needs-work. Can you see if you can improve this ? Thank you.
Comment 2 Wang Xiaozhe 2013-03-01 04:17:28 UTC
(In reply to comment #1)
> (From update of attachment 229914 [details] [review])
> Thank you for your patch and my apologies that no one responded to it earlier.
> 
> I don't know what to do with this patch to be honest. I understand that one
> month of transactions in the ledger doesn't work for your use case. But I fear
> that your alternative will equally not work for other use cases.
> 
> I think a more elegant solution would be to improve the filter dialog. It
> currently has no support for relative time periods, like "last month" or "this
> year". Adding it in there would certainly make it more usable for many.
> 
> Especially if you  combine this with the new option in the development series
> to save your preference, everyone can configure the date range that suits
> him/her best.

Yes, that will be much better.

> 
> For now I have set the status to needs-work. Can you see if you can improve
> this ? Thank you.

I'll see how to implement it recently.
Comment 3 David Carlson 2013-05-30 20:40:22 UTC
In release 2.5.2 Windows build the new GL can only be coaxed into showing transactions starting a month ago.  However, in the old view GL of release 2.5.2 the filter can be changed to whatever range I want, including back to the oldest transaction in the file.  I would prefer the previous behavior, as it better fits the generic definition of general ledger.  The following discussion sets a scenario where it can work.


IMHO* I think that if any register view filter is retentive, then the
filter active status should appear somewhere in the window of every
affected register view.  I would prefer it to appear in or near the
column titles, but the bottom bar near the activity indicator would also
work for me.  It also should be flagged visually somehow in the register
tab, without adding more clutter to the tab.  Perhaps a symbol (choose
one, tilde, perhaps, also with contrasting background/foreground colors)
next to the 'plus' that appears in tabs for accounts with sub-accounts
views.

Further, then each filtered view should have it's own tab in the tab
bar, and multiple views of the same account should be so identified and
allowed.  This would, however, complicate the decision of which view to
go to when a jump to account is requested.  Maybe only one filtered view
should be allowed, and/or a jump would default to an unfiltered view, if
no filtered view is available.  Currently, jumps never go to views with
sub-accounts.
Comment 4 Geert Janssens 2013-05-31 11:51:22 UTC
David, thank you for your suggestion.

Let me split it up:
- Allow to change time period to list in general ledger: this is what your bug 701211 is all about. I agree with you this is a regression and should be fixed in the new code. Bug 701211 will track this.

- Add a visual indicator if a filter is active on a register. This is a  good suggestion, however not in the scope of this bug (which is about adding a new type of filter, namely relative dates). So I have opened a new enhancement request for this: bug 701347. Any discussion about this new request can be added there.

Finally, this enhancement request itself (bug 689092), still is about adding relative dates to the filter window (current month, previous quarter,...)
Comment 5 Bob 2013-06-06 13:32:20 UTC
I think the simplest solution would be to add a spin button to the preference dialogue indicating the number of months to display limited to say 1 to 24 with a default of 1 month and then subtract this month value from the current date. This would not involve the filter dialogue at all and I would of thought this value would not change much once the user has decided on a suitable value.
Comment 6 lmat 2014-09-09 14:28:47 UTC
I've noticed this a number of times as I ordinarily enter everything into the GL, and "manually" type all splits. I don't mind if the default is 1 month or 12 months, but what I would like is for it to remember my settings. Personally, I want it to "Show All" (although I don't have more than 10 months recorded), and I have to set that every time I reopen the GL. If the filter preference of the GL could be remembered, would anyone have any outstanding complaints?

The visual indicator on a register that has a filter applied, I think, is also an excellent idea, but, as it was mentioned earlier, that's another Bug.
Comment 7 lmat 2014-09-09 14:34:47 UTC
Oops, I just found 714708, sorry.
Comment 8 John Ralls 2018-06-29 23:12:06 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=689092. Please continue processing the bug there and please update any external references or bookmarks.