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?
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.
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.
The closer we can get to GUI or full web baseing here, the easier it will
be for new users to assimilate.
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.
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.
* 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.
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.
Luke
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
