Adrien,
Using configuration files as a mechanism for working around the significant 
shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To 
be clear, I understand the challenges facing the team-- as well as accept that 
I am unable to effect change in these areas.  Nevertheless, I am disinclined to 
paper over these shortcomings by accepting such workarounds.

Furthermore, as I understand it, saved reports use the GUID of an account to 
refer to them, so any attempts at using a saved report from one file in another 
is likely doomed to fail. 


Or perhaps you're talking about settings associated with the standard reports? 
I profess I do not know how settings for these are stored-- although the fact 
that they are not stored with the actual saved reports (like the saved reports 
themselves) simply underscores the piecemeal mechanisms used for the reports. 

Your points about multiple user access are a red herring.  Since Gnucash 
doesn't support multiple users, there's no point in speculating on how we might 
circumvent this limitation.  

Gnucash does, however, support one user having multiple data files, and in this 
case, a user opening file B will see all the (useless) saved reports for file A.

Finally, the points originally raised regarding the scattershot storage of data 
that are integral to a set of books (whether reports, settings, or other data) 
remain.  

David T. 

 
 
  On Sun, Feb 24, 2019 at 9:14, Adrien 
Monteleone<adrien.montele...@lusfiber.net> wrote:   One might want the same 
configuration in many respects and the same options on various reports to be 
’saved’ (since there is no other way to accomplish this task) as user 
configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)

Regards,
Adrien

> On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel 
> <gnucash-devel@gnucash.org> wrote:
> 
> Storing configuration data separately from the financial data and on a user 
> (as opposed to a book) basis is questionable.
> 
> Storing saved reports separately from the financial data and on a user basis 
> makes no sense at all. A saved report for one file will be meaningless in 
> another. This issue has come up many times on the lists. 
> 
> The fact that we even need a wiki page dedicated to file and configuration 
> locations-- let alone one as long and convoluted as the one we have (and 
> which needs additional diagramming)-- only underscores this problem. 
> 
> I want to be clear that I am truly grateful that Chris has decided to work on 
> reports, and I have great respect for his ability to work with Scheme. I've 
> yet to succeed in either editing an existing report or getting a third party 
> report installed on my Mac. 13 years of futility on that front!
> 
> David T. 
> 

_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to