GNOME Bugzilla – Bug 764245
multi-column reports include incorrect sub-reports
Last modified: 2018-06-29 23:48:12 UTC
Created attachment 324807 [details] multi-col rpt with incorrect sub-rpts and options multi-column reports include incorrect sub-reports reproducible: yes on both Win and Linux for some combination of reports a multi-col rpt will include sub-reports other than those set in the options bear with me as I update this description and attachments
Created attachment 324808 [details] multi-col rpt with correct sub-rpts and options
the attachment with two tabs (Accounts and .Home) is correct. the attachment with extra tabs is incorrect. .Home is a saved report. if I open gnc with just the Accounts tab and and choose Reports / Saved Reports / .Home it will always work (i.e. the saved report is actually correct). if I load some other reports and *then* load .Home it will display incorrect reports for some of the sub-reports. the problem is not specific to .Home, it happens with other multi-col reports too. the reports that get picked up vary, I'm guessing something to do with the seq the reports are loaded or viewed in once a multi-col report has gone wrong the incorrect options survive opening and closing gnc meaning that if it isn't noticed the incorrect details can be written to saved-reports and is a bugger to sort out later it is only very recently that this has become something I am able to reproduce and I'm not finding it easy to explain so questions are welomed
I have experienced this problem as well. Multicolumn report with sub-reports A, B, C, & D opens at another time with reports F, P, O, and X. I have seen this with different multicolumn reports in a single installation. I have no idea what triggers the problem. OS X, GC 2.6.14
I think, if we include Carsten Rinke's report in gnucash-devel around 2016-12-07 we can say that this is now a general fault, i.e. it occurs regardless of OS and across multiple gnc versions. I think Carsten noticed it before I did but didn't report it because when it first happens it is hard to work out what is going wrong. You know *something* is wrong but then you have to report it and then you have to say *what* is wrong ... it took me some time to pin it down. I'll write my thoughts in the next message
I've struggled through the code (I find gnc code opaque even when I am looking at very detailed stuff like saving reports which should be plain, ugh) and think I understand the idea of the multicolumn report. From an observation basis I think one, simple, multi-column (i.e. two) report should always work ... most of the time. Guess what? I have shell scripts that I have written to record and compare one version of "saved-reports-2.4" with another. I keep over a years worth of "saved-reports-2.4" The problem, in plain terms, is that the report saved to "saved-reports-2.4" isn't the one a person was looking at when they pressed save. I don't know how to explain this better to a developer. It is as obvious as this two reports in a multicolumn save it open it different reports shown it REALLY IS WHAT HAPPENS 3 senior reporters concur
Wm, Perhaps you'd care to share with us the changes that you made and the resulting incorrect changes to your saved-reports-2.4.
the changes can be anything or nothing, I think the problem is in the saving for example, changing a date could result in a bad save or changing an account could result in a bad save the thing is the multi-col report being saved is sometimes saved correctly and other times not so there is something else going on *other* saved multi-col reports (i.e. those other than the ones being saved by the user in a deliberate way) also get their sub-reports changed in a way that I haven't been able to get my head around someone that knows more about the content of saved-reports-2.4 (I have a fairly detailed local history of them) might be able to tell me what to look for. === what I see, in practise, is one of the reports I have in a multi-col being replaced by another. I have 53 folders / directories of saved-reports-2.4 the earliest being saved-reports-2.4_2016-03-04_safe at which point I probably thought I had a safe base to work from and deleted the earlier saves. === JohnR within this small group there isn't a lot of private stuff that I can see in the saved-reports-2.4 files themselves, they're using (re-using?) UIDs so I doubt privacy is the reason people are holding back. I think the problem is that without data the reports won't work in the first place and you'll think "grrr, bum data" which is not what is intended. However, it is the fact that these reports don't contain anything personal and do impact on each other that makes me think this is a saving or similar error. If anyone wants a lot of saved-reports they are welcome to it ... thing is I am approaching expert level in splitting and rejoining saved-reports-2.4 and I doubt the files themselves will help. More thoughts, please
Thanks for bringing this up Wm. I got here indirectly because I observed a totally unrelated issue jqplot issue today which I *thought* to be related. It isn't so I filed bug 779411 for the that. However re-reading your description I believe this time I understand where it goes wrong. Although each report definition has a UUID, instantiated report are just numbered sequentially internally. This numbering is assigned in the order reports are loaded. The save-reports file lists report instances, not report definitions. So when this file is read, each report instance found in there gets a number. If the order of the instances in that file changes, so will the numbers they receive when loaded. And now it gets ugly: the multi-column report saves report instance numbers for its subreports. However when a that file is resaved because an unrelated reports has changed the multicolumn instance is not updated. So in a sense you are right this is a saving bug. I'd rather call it a very poor design decision to depend on a moving number. Anyway we know the cause. Unfortunately I don't have time currently to pursue a fix. Hopefully I can still squeeze this in before the 2.8 development cycle ends, because fixing this entails a data format change.
Created attachment 359927 [details] [review] solution proposal for report.scm without data format change Here comes a solution proposal that avoids a data format change. The internal handling of report IDs (running numbers) is untouched, but the report IDs are not stored anymore in saved-reports files for multi-column view reports. Instead: The newly allocated report IDs at sub-report (or embedded report) restoration are forwarded to the multi-column view report. This forwarding action is now part of the text in the saved-reports file (marked with "Update Section: __general"). Advantages: - only one file to be changed (report.scm) - the changes should be backward compatible It also includes some minor changes in the formating of the saved-reports file for better readability.
On the data format change, the change in saved-reports format was actually exactly the required format change I had in mind :) Having said that I also apologize for the long review delay. For some reason I missed this patch. Maybe I'm getting too used to github PR's :( And having said that I can end with: thanks! I have applied your change to unstable so this problem will be fixed for the 3.0 release. I'm happy you provided it as it fixes a pretty nasty bug.
Thank you very much for fixing this. -- Wm
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=764245. Please update any external references or bookmarks.