Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens: > Adrien, > > You beat me to it. I was about to also suggest making it a user preference > to be able to store the report configurations either with the book or as a > user location. Then the user could choose what suits their circumstances and > configuration. > > David Cousens
Well, for me each reference to "a new user preference" triggers the question "can't we solve it in another way". For starters the user preference is an all or nothing thing, either all reports are in a book or in a common location. That's not very fine-grained. Perhaps you consider some reports common and some reports book-specific. This could be solved by making it a per report option of course. It also doesn't solve the issue of sharing those common reports with other users (like your accountant). And yet another issue: reports are only suitable for multiple books if these books have the exact same base as required per report. An example to clarify what I mean: take the transaction report. The user selects a set of transactions to display. Now suppose you select some accounts that are exclusively to this particular book. If you save this preset, and use it in another book that doesn't have these accounts there will be an issue. I haven't tested, though at best the account is ignored, at worst the report throws errors. That's the best scenario. The other way around is worse: suppose you saved the report configuration with all asset accounts selected in one book. You then try to use this report on a book that has an additional asset account. As this account is not part of the initial selection it won't appear in the transaction report in the second book. Of course for a transaction report it's fairly easy to spot. There are other reports where this is much more subtle though. And this is not limited to account selections though I suspect that's the most important one. So my conclusion is that report configurations are essentially book specific and should be treated as such to avoid unexpected accounting mistakes. On the other hand I understand it takes time to carefully configure reports to your preference and there's a wish to reuse this effort across books. I have done this thought exercise in the past. At that time the best I could come up with was to provide gui functions to manage report presets. In particular some form of import/export functionality. The configurations would remain per book. But one could explicitly export a configuration from one book and import it in another. It's not ideal as it doesn't solve the subtle errors issue. The user will still have to verify the imported configuration works for the book it's imported in. Improving on that will require smarter report options (like ways to specify "select all asset accounts" or "select all children from account xyz" instead of a dumb list of account ids). I'm pretty sure that would increase internal option complexity a lot and I'm not convinced the benefit in this case is worth the trouble. All brainstorming of course. No implementation in sight... Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel