Re: Where we are going with 1.3

["Chris Travers" <..hidden..>]

On 4/6/07, Jeff Kowalczyk <..hidden..> wrote:

> If there's a REST API for getting and setting templates like every other ledger
> data item or system preference, then it is probably best to store templates in
> the database.
>
> It would be a nice to say that ledgersmb backups/migrations/restores can be
> handled solely with pg_dump, psql and a single file copy of
> /etc/ledgersmb/ledgersmb.conf
>
> Re: testing, this is probably the right place for a template syntax checker or
> validator. Don't let the template get saved to the database without checking
> for variable names, latex/html lint, whatever other checks can be devised.
>
> I'd like to hear about plans for unit/functional/integration testing soon
> anyway, so adding template persistence to the database mix doesn't see like
> much more complexity at this point.
It may actually be less complex.  The basic issue is that accounting
systems are probably the fourth most mission-critical system in terms
of availability in any business (after telephones, email, and network
control), but they are the most in terms of data integrity and
security.  If just one malicious user can pull off an SQL injection,
XSS, authentication bypass, or other attack, then the accounting data
is suspect and that is a major regulatory and financial nightmare.

If setting this up so that the web server needs only a small set of
permissions to run is simplified by throwing these into the db, then I
am all for it (*the* most important goal in our project is
industry-leading security, IMO).  If people have simpler solutions, I
would like to hear them (I suppose we could just get rid of template
editing and make people use sftp, but we may in the process prevent
the product from being a real Quickbooks replacement  if we make too
many of these that inconvenient).

Best Wishes,
Chris Travers