Easier custom reporting (maybe Lua)?

Wed Oct 26 03:50:20 EDT 2016

To run the report, copy the 3 files in your "settings directory" as seen in
https://wiki.gnucash.org/wiki/Custom_Reports#Load_the_report_from_a_user_account
And to run the report from the menu Reports/Sample and custom
reports/Piecash simple report

On Oct 26, 2016 09:41, "Sébastien de Menten" <sdementen at gmail.com> wrote:

> Hello Geert and the list,
>
> I know it can be done today because I got the idea from following some
> recent discussions on the list on custom reports.
> So I went to reanimate my scheme skills, which were indeed almost dead.
> You can find in attachement a simple setup to run a report through a
> python script (that just print to stdout a static html report) that I wrote
> based on the information read on https://wiki.gnucash.org/
> wiki/Custom_Reports.
>
> What is currently missing:
> 1. a way to transfer all options defined in the report to the python
> script. I was thinking about piping the options in a standard format like
> xml/json/yaml. Any idea on how to do this in a generic way (like doing a
> scm->json of the report-obj) ?
> 2. a way to send to the python script the URI of the gnucash book (so that
> piecash can read the book).
>
> Any ideas/suggestions ?
>
> sebastien
>
>
>
> On Tue, Oct 25, 2016 at 12:55 PM, Geert Janssens <
> geert.gnucash at kobaltwit.be> wrote:
>
>> On Tuesday 25 October 2016 07:17:28 Sébastien de Menten wrote:
>> > On Sun, Oct 23, 2016 at 8:08 PM, Geert Janssens
>> > <geert.gnucash at kobaltwit.be>
>> > wrote:
>> > > 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...
>>
>> I understand the idea is better integration of gnucash with 3rd party
>> reporting extensions. I don't think the solution is the right one here
>> or at least not in the simplistic form as proposed.
>>
>> But let me start with this: what you ask for is already possible now
>> IMO. Gnucash has a feature to load custom scheme code at startup. This
>> is used for example to add extra self-written reports. This same
>> mechanism can probably be (ab-)used to let you call any external program
>> you like.
>>
>> With that in mind I will continue to argue against is promoting this to
>> a standard feature of gnucash. I'm fine with people tinkering and
>> extending gnucash locally. Those people however generally know more or
>> less what they are doing. Ordinary users may not be aware of this.
>>
>> I see this extensibility as a gap that should be closed by default and
>> only open when someone explicitly wants to make use of it. So rather
>> than adding an additional "call whatever you want" mechanism I'd add an
>> option to *disable* loading custom scheme code by default and only allow
>> someone with admin rights to enable it by setting a system level
>> preference.
>>
>> While this is not exactly what you asked for I'm afraid, it's something
>> that has been on the back of my mind for quite some time. And since the
>> topic got touched I want to clearly express my point of view on this
>> matter.
>>
>> As to your argument "the unverified program gnucash would call could
>> anyway be called from the command line", this only considers the
>> technical aspect of security. Allowing gnucash to run aribitrary code
>> opens an extra vector of attack for social engineering. It could be used
>> to entice people that would never use the command line to execute
>> malicious code without them realizing it. The risk is small, but real
>> and can be avoided by not allowing gnucash to run arbitrary code.
>>
>>
>> Regards,
>>
>> Geert
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>
>