Re: State of Perl-based database setup utilities for LedgerSMB 1.3

[Chris Travers <..hidden..>]

On Tue, May 31, 2011 at 5:04 PM, Luke <..hidden..> wrote:
> On Tue, 31 May 2011, Chris Travers wrote:
>
>>>  > OTRS is a great example of a tool that comes with a great
>>>>
>>>> installation
>>>> script in Debian: you run the command 'apt-get install otrs2' and the
>>>> database, cron jobs and webserver all are configured when it
>>>> succesfully completes. That's what I envision for lsmb too, for its
>>>
>>> Do you only get one single issue queue [or analogous concept] from that
>>> action, or can you create more without running the package manager again?
>>> If
>>> you can, how is it done?
>>>
>>>  > first company database - created by packagers for specific
>>>>
>>>> distributions.
>>>
>>> Is the COA part of that first database, and do we still lock users into a
>>> COA template at company creation time?
>>
>> Ah... I see your point.  Maybe we should allow chart of accounts to be
>> loaded from the UI.
>
> I'm glad you do.:)  Because, that's really one of my only two dogs in this
> fight.  I object to extra-application creation of the initial database,
> because, unlike an issue tracker or a webserver, chances are *good* that the
> COA in that first dataset will be wrong for the user who installed it, and
> he will have to blow it away (thus learning how to blow it away), and create
> a new one (therefore learning how to create a new one), with his proper COA.
> To my way of thinking, that is an inconvenience which outweighs the
> convenience of having the initial company automatically created.
>
> If you can create shell databases, maybe with an initial user, and then let
> the application handle the bootstrap phase for the dataset (I.E., COA), you
> will go along way to making me shut up about this.
>
> Perhaps a function which runs after session creation, which checks for the
> profile of an existing COA, and if not, requires that one be created,
> assuming the user given has sufficient permissions?

What about an ability to "add" a COA to an existing database?  Qould that
>
>> I am not convinced those risks are analogous.  The basic issue is that
>> to crack a database user at that level, or finding/exploiting some
>> sort of permissions elevation vulnerability in Pg (which is a much
>> larger project with much more review than we have), strikes me as very
>> different from attacking our application (the product of a smaller
>> project with less review).
>>
>> But beyond that, I don't believe there is any other way to retrofit
>> permissions enforcement onto the legacy code, since SQL-Ledger lacks
>> any real permissions management.
>
> Agreed.
>
> Here is the primary thrust of most of my usability style concerns.
>
> I'm trying to think about lowish-skill users, people who just want it to
> work and don't want to employ a consultant to make it work, and how they
> will react to the install and initial setup.

Right.  Agreed that this is a major concern.
>
> Obviously, the harder and more foreign the process, the more of them we will
> lose along the way.
> If their coming from windows, they may be used to QB and its ilk.  If their
> moving across in open source, they'll possibly be coming from Postbooks or
> Gnucash.
> In neither case, are they likely to have to open a terminal in order to
> create databases and users.  Those are basic internals, that at least the
> users I support would expect to be able to do from within the application,
> or from within something that is an administrative adjunct to the
> application, but works the same way.
> Even in SQL-Ledger, as problematic as it was/is, these things are internal,
> all be it in a badly implemented way.

For the simple, non-knowledgeable users, I think the simplest approach
will be to assume a single database installation.
>
> The closer we can get to GUI or full web baseing here, the easier it will be
> for new users to assimilate.

I would agree.  I guess what I am thinking are distributions like:

1)  Core distribution (consultants, etc are target audience)
2)  Small business owners (include web app for setting up db, etc)
3)  Special vertical distributions
4)  Any other distributions people feel are helpful.
>
> Don't get me wrong, I want that fully functional CLI backing to it as much
> as the next person, but for user attractivity, moving as much of this as
> possible into a web interface is going to be preferable to most I should
> think.
>
> You wanted the reason for my preferences, and that is it.  I support users
> who will only move to open source, if they don't have to notice their doing
> it more than the normal learning of a new app in the same old environment.
>  So, I have learned to anticipate their worries, and the things they just
> won't do.

Ok.  So what we need to do is go through the ledgersmb.conf  in 1.3
again and see if there is anything that needs to be moved into the
defaults.

>
> Now, I don't actually expect us to get there in 1.3.  However where we do
> seem able to get in 1.3, is:
> * Package manager install
> * Maybe a config step as a part of that, to set user parameters for the
> initial user, if necessary.  Also the initial database creation could be
> done with a package manager config step, although I don't know if anything
> other than apt is that advanced.

RPM can do that.

> * Go to the web interface after that to add subordinate users, choose a COA,
> etc.
> Preferably, though, even the initial user and company creation would be done
> in the web interface, at least by those who don't want to know any better.
>
> I haven't seen your addon for some of this, and don't know how blackboxie it
> is nor how easy it would be to turn it on by default, but it seems
> promising.

Thanks :-)
>
> I don't disagree with your security concerns, I just think that we should be
> striving for best of both worlds, with near equal priority.
>
> That said, if addons can get it done, and can be integrated into the install
> process, I'm all for getting it working only at the PERL and CLI level in
> 1.3 release, and fixing these things concurrently.
>
The main reason to put that in addons is so it can have its own
release schedule.  we can have a bundle release with it too (maybe
with fixed asset handling too).

Best Wishes,
Chris Travers