On Tue, 31 May 2011, Chris Travers wrote:
> OTRS is a great example of a tool that comes with a greatinstallation 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 itsDo 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 specificdistributions.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