Easier custom reporting (maybe Lua)?

Sébastien de Menten sdementen at gmail.com
Wed Oct 26 03:41:11 EDT 2016


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.
>
-------------- next part --------------
(load (gnc-build-dotgnucash-path "piecash-simple.scm"))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simple_report.py
Type: application/octet-stream
Size: 135 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20161026/1e9dbee8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: piecash-simple.scm
Type: application/octet-stream
Size: 5662 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20161026/1e9dbee8/attachment-0001.obj>


More information about the gnucash-user mailing list