Easier custom reporting (maybe Lua)?

John Mitchell john at lillianservices.com
Tue Oct 25 07:19:19 EDT 2016

Sorry for the previous email response. I thought that it was for a different issue.

John W. Mitchell
Lillian Services LLC
(251) 597-9257
-----Original Message-----
From: John Mitchell [mailto:john at lillianservices.com] 
Sent: Tuesday, October 25, 2016 6:16 AM
To: 'Sébastien de Menten' <sdementen at gmail.com>; 'Geert Janssens' <geert.gnucash at kobaltwit.be>
Cc: 'gnucash-user at gnucash.org' <gnucash-user at gnucash.org>
Subject: RE: Easier custom reporting (maybe Lua)?

Thank you all for your assistance. I have located a file on my backup drive that is recent enough that I have been able to restore my files. My problem is solved.

John W. Mitchell
Lillian Services LLC
(251) 597-9257
-----Original Message-----
From: gnucash-user [mailto:gnucash-user-bounces+john=lillianservices.com at gnucash.org] On Behalf Of Sébastien de Menten
Sent: Tuesday, October 25, 2016 12:17 AM
To: Geert Janssens <geert.gnucash at kobaltwit.be>
Cc: gnucash-user at gnucash.org
Subject: Re: Easier custom reporting (maybe Lua)?

On Sun, Oct 23, 2016 at 8:08 PM, Geert Janssens <geert.gnucash at kobaltwit.be>

> On Sunday 23 October 2016 09:24:19 John Ralls wrote:
> > > On Oct 23, 2016, at 8:53 AM, Sébastien de Menten 
> > > <sdementen at gmail.com> wrote:
> > >
> > > Would it be feasible in gnucash to use the guile/scheme report 
> > > system to call an external process (a command line program) that 
> > > would return the proper html to display in the report ? The 
> > > external program could take arguments generated by the options 
> > > system of the report (the GUI that is used to customize a report).
> > > If so, we could have a more open system for report generation.
> > > Piecash could be used by pythoneers but others could use a mix of 
> > > sql + any external program to build reports.
> > >
> > > Does this make sense ? Or are there blocking issues I am not aware 
> > > of ?
> > Yes, it's possible: The quote retrieval code works by calling a perl 
> > program, gnc-fq-helper, from Scheme. We'd need someone fluent in 
> > Scheme to write the external interface code. Such a report wouldn't 
> > have access to the in-memory state of the database, though, so it 
> > would be current only with the SQL backend or a freshly-saved XML 
> > file.
> >
> Possible maybe. Desired I'm not sure.
> There is an important difference between gnucash calling gnc-fq-helper 
> or adding an api to call whatever program on the system. The 
> difference being gnc-fq-helper is a script that comes installed with 
> gnucash and can't normally be altered by any user except someone with 
> administrator rights on the system. It's been verified by the 
> developers to not do any nasty things on your system.
> Adding an option to call whatever program on the system opens a 
> potential security hole. You are suddenly asking gnucash to run 
> totally unverified code. I'm not looking forward to this for various reasons.
The idea is more about a better integration between gnucash and 3rd party reporting extension. The unverified program gnucash woud call could anyway be called externally by the user, via the command line (i.e. it does not change a bit the security or I am missing something...). But thank to this better integration with gnucash, the user experience would be dramatically improved !
Seen the complexity of today's legacy  reporting system in gnucash, that is not expected to be reworked in the coming months/years due to understandably higher priorities  (engine and backend), this integration via guile/scheme looks like a promising venue doable in a couple of hours/days.

Any scheme gnucash guru willing to scratch this itch ? My own scheme practice is under 15y of dust...
gnucash-user mailing list
gnucash-user at gnucash.org
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

More information about the gnucash-user mailing list