r19325 - gnucash/trunk/src/report/standard-reports - Bug #556713 - inconsistency in report options, partial fix

Geert Janssens janssens-geert at telenet.be
Thu Jul 8 15:50:57 EDT 2010

On Thursday 8 July 2010, Derek Atkins wrote:
> Yeah, the report options are hard-coded to their English names.  There's
> not a mapping of Option to Display Name (except through the translation
> mechanism).  In other words, an option is defined by the tuple
> <pagename,optionname> and those two strings are then translated directly
> for display...  So if you change the pagename or optionname then you
> effectively change the option.
Ok, I understand.

> > How badly will the reports be broken ? Is it in the range of
> > "You'll have to reset the dates on your saved reports and resave the
> > reports" or rather the report will error out ?
> I'm not 100% sure.  Certainly the report will need to be reset.  It's
> possible that the report will crash.  If there's a SAVED report then it
> may be worse, but I don't know for sure -- I don't use saved reports.
> The way to test:
> Run a gnucash before this change, open one of the affected reports, keep
> it open and exit gnucash, upgrade to the changed code and then restart
> gnucash.  See what happens.
> Then perhaps re-run the test with a saved report?
I ran these tests. The reports fail fairly gracefully. Every option for which 
I changed the name is reset to it's default value after the change. For now 
the options I changed are:
* From/To -> Start date/End date
* Accounts to include/Report Accounts -> Accounts
* Filter Accounts -> Filter by...

None of these introduced new strings, but this means a number of options will 
be reset on reports that are still open and saved reports.

So two things have to be decided on here:
1. Are these report option resets acceptable ? Personally, I think now is 
better than in a future maintenance release.
2. I had attached a patch with some more option consistency fixes to 
http://svn.gnucash.org/trac/ticket/556713, which I was keeping for after the 
string freeze because they were changing strings. This now becomes a very 
debatable patch: I don't think these changes should be introduced in a 
maintenance release. I don't think our users would like to see their carefully 
customized reports being reset in a stable series. Introducing the changes now 
would break string freeze. A third option would be to wait for 2.6 with these 

Lastly, suppose we keep the changes I did now, where should the report options 
reset effect be documented ? In the release notes ? The FAQ ? Somewhere else ?


More information about the gnucash-devel mailing list