You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2007/12/13 17:22:49 UTC
OfBiz System Configuration Wizard
Marco's recent work in Jira brought this issue to my attention:
https://issues.apache.org/jira/browse/OFBIZ-636.
I would like to start working on that feature. Since that issue was created, comments have been made
in other discussions on the mailing list that may have an impact on the implementation.
The idea is to have a system configuration screen. David mentioned recently in an unrelated topic
that having a UI for system-level configuration would be undesirable:
"If you have a config UI it makes it even more difficult to manage because if someone changes
something in the UI and someone else writing code makes a corresponding configuration in the file
system, when the data is reloaded you might end up with a change loss problem... and that's only one
scenario."
At the same time, we do get requests for a configuration UI.
So I'd like to work on this, but there is already a disagreement over whether it should be done.
Any ideas on how I should proceed? Does anyone see a need for such a feature?
-Adrian
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
>
> On Dec 13, 2007, at 9:22 AM, Adrian Crum wrote:
>
>> Marco's recent work in Jira brought this issue to my attention:
>>
>> https://issues.apache.org/jira/browse/OFBIZ-636.
>>
>> I would like to start working on that feature. Since that issue was
>> created, comments have been made in other discussions on the mailing
>> list that may have an impact on the implementation.
>>
>> The idea is to have a system configuration screen. David mentioned
>> recently in an unrelated topic that having a UI for system-level
>> configuration would be undesirable:
>>
>> "If you have a config UI it makes it even more difficult to manage
>> because if someone changes something in the UI and someone else
>> writing code makes a corresponding configuration in the file system,
>> when the data is reloaded you might end up with a change loss
>> problem... and that's only one scenario."
>>
>> At the same time, we do get requests for a configuration UI.
>>
>> So I'd like to work on this, but there is already a disagreement over
>> whether it should be done.
>>
>> Any ideas on how I should proceed? Does anyone see a need for such a
>> feature?
>
>
> You have taken my comments out of context. Some things should be
> configurable through the UI, others should not. My point is that things
> which are creating along with code or that are managed as part of a
> coordinated deployment (like server settings and such that vary in
> different deployment environments, like dev, test, qa, staging,
> production, etc, including app server and database and such settings)
> should NOT be in a UI, partly for the reasons in my comment above.
>
> Business level things most certainly SHOULD be configurable in the UI
> and make sense to put in the database. That was the other part of what
> I wrote that isn't quoted above, including examples of what constitutes
> business versus system level settings. Above are some things about
> system level settings, and a strong example of business level settings
> is the payment.properties file, and things in other places like
> shipping configuration and such.
>
> It's not a question of if, and I never said it was, in fact I tried to
> make it very clear that it's a question of what and where.
>
> -David
I'm sorry you feel you were misquoted. I thought I made it clear (notice my qualifiers "system
configuration" and "system-level") that the configuration screen being proposed was for the very
things you said should not be configured through the UI. Business level configuration is another
subject - and many of those screens already exist.
My thinking is more along the lines of someone downloading and installing a binary release version -
who might not be sophisticated enough to dig through multiple *.properties and *.xml files to
configure the installation. A configuration UI would be helpful in that scenario. (Not everyone
wants to download and install Eclipse just to get OFBiz set up. ;-) )
I agree with your view - having two paths to file modification can lead to problems. The question
is, how can we maintain configuration file integrity and still make it easier for a newcomer to
configure their system? And, in a small shop/single administrator setting, is it even an issue?
-Adrian
Re: OfBiz System Configuration Wizard
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Dec 13, 2007, at 9:22 AM, Adrian Crum wrote:
> Marco's recent work in Jira brought this issue to my attention:
>
> https://issues.apache.org/jira/browse/OFBIZ-636.
>
> I would like to start working on that feature. Since that issue was
> created, comments have been made in other discussions on the mailing
> list that may have an impact on the implementation.
>
> The idea is to have a system configuration screen. David mentioned
> recently in an unrelated topic that having a UI for system-level
> configuration would be undesirable:
>
> "If you have a config UI it makes it even more difficult to manage
> because if someone changes something in the UI and someone else
> writing code makes a corresponding configuration in the file system,
> when the data is reloaded you might end up with a change loss
> problem... and that's only one scenario."
>
> At the same time, we do get requests for a configuration UI.
>
> So I'd like to work on this, but there is already a disagreement
> over whether it should be done.
>
> Any ideas on how I should proceed? Does anyone see a need for such a
> feature?
You have taken my comments out of context. Some things should be
configurable through the UI, others should not. My point is that
things which are creating along with code or that are managed as part
of a coordinated deployment (like server settings and such that vary
in different deployment environments, like dev, test, qa, staging,
production, etc, including app server and database and such settings)
should NOT be in a UI, partly for the reasons in my comment above.
Business level things most certainly SHOULD be configurable in the UI
and make sense to put in the database. That was the other part of what
I wrote that isn't quoted above, including examples of what
constitutes business versus system level settings. Above are some
things about system level settings, and a strong example of business
level settings is the payment.properties file, and things in other
places like shipping configuration and such.
It's not a question of if, and I never said it was, in fact I tried to
make it very clear that it's a question of what and where.
-David
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@hlmksw.com>.
Jim Barrows wrote:
> I for one would like an easier way to setup the Chart of Accounts at
> the very least. And map an organization to accounts in the chart of
> accounts.
That would be handled in the accounting component. The screen I had in mind is for system-level
things, like the ones mentioned in the Production Setup Guide.
Re: OfBiz System Configuration Wizard
Posted by Jim Barrows <ji...@gmail.com>.
If such a thing were created, and to avoid the stated problem, all
configuration would have to go into the configuration UI.
on the other hand, the counter to the conflicting configuration
changes is simple... if you provide a UI, those who like the UI, will
tend to use it exclusively, while those who don't won't. You could
also just allow it to generate the XML, and then let someone manually
merge them into the config files....
I for one would like an easier way to setup the Chart of Accounts at
the very least. And map an organization to accounts in the chart of
accounts.
On 12/13/07, Adrian Crum <ad...@hlmksw.com> wrote:
> Marco's recent work in Jira brought this issue to my attention:
>
> https://issues.apache.org/jira/browse/OFBIZ-636.
>
> I would like to start working on that feature. Since that issue was created, comments have been made
> in other discussions on the mailing list that may have an impact on the implementation.
>
> The idea is to have a system configuration screen. David mentioned recently in an unrelated topic
> that having a UI for system-level configuration would be undesirable:
>
> "If you have a config UI it makes it even more difficult to manage because if someone changes
> something in the UI and someone else writing code makes a corresponding configuration in the file
> system, when the data is reloaded you might end up with a change loss problem... and that's only one
> scenario."
>
> At the same time, we do get requests for a configuration UI.
>
> So I'd like to work on this, but there is already a disagreement over whether it should be done.
>
> Any ideas on how I should proceed? Does anyone see a need for such a feature?
>
> -Adrian
>
>
>
--
James A Barrows
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@hlmksw.com>.
Again, we use the Asset Maintenance component OOTB here. Even though I'm an in-house IT guy and I
was the one who installed OFBiz here, it didn't have to be me doing it. Our facilities manager
(person, not program) could have downloaded a binary release, unzipped it and started using the
Asset Maintenance component on his own. No consultant or systems guru is needed. Seriously.
Many of our users are at that skill level where they could download and install software themselves.
The problem comes when someone like that tries to follow the Production Setup guidelines and is told
to modify properties files and XML files. They won't know what to do at that point.
I believe this to be a very real scenario, especially once the Accounting component is finished.
A binary release doesn't have to come from the OFBiz site. It could come from another source, like
Opentaps. I suppose someone providing a binary release of their own could develop their own system
configuration screen as well.
-Adrian
Walter Vaughan wrote:
> Jacques Le Roux wrote:
>
>> I'm not sure to see the frontier here...
>>
>>
> Except in the edge case, I don't see how many people who are at the
> level of being able to install and operate SugarCRM could do the same
> thing with OFBiz. And moving it up a level, compare installing a demo
> version of OFBiz with downloading and installing the Microsoft Dynamics
> GP 10 demo. Or staying closer to open source, installing postBooks
> (http://www.xtuple.com/postbooks).
>
> My point is that if it's an OOTB solution as the goal or even a forked
> goal of the community, then last March when the 4.0 release was created,
> some effort should have gone into consistent user interfaces,
> installation wizards, documentation, manuals. The communty voted with
> its keyboards to instead add hundreds of new features to the trunk
> instead. Given that the number of bug fixes that have gone into the 4.0
> release can be measured by a human hand testifies that the community is
> addicted to features. NOT THAT IT'S A BAD THING :)
>
> Me, I've always thought it should be as easy to install OFBiz as any top
> line .php application that asks a few (or as many as is needed)
> questions, confirms and configures itself, and is ready to operate
> within minutes, and the configurator be re-entrant to allow
> configuration changes in the future and also suggest settings for
> certain conditions.
>
> --
> Walter "rambling post" Vaughan
>
Re: OfBiz System Configuration Wizard
Posted by Jacques Le Roux <ja...@les7arts.com>.
Walter,
OK, thanks this is more clear :o)
De : "Walter Vaughan" <wv...@steelerubber.com>
> Jacques Le Roux wrote:
>
> >I'm not sure to see the frontier here...
> >
> >
> Except in the edge case, I don't see how many people who are at the
> level of being able to install and operate SugarCRM could do the same
> thing with OFBiz. And moving it up a level, compare installing a demo
> version of OFBiz with downloading and installing the Microsoft Dynamics
> GP 10 demo. Or staying closer to open source, installing postBooks
> (http://www.xtuple.com/postbooks).
Sorry, I have not time to MS or even postBooks. I installed SugarCRM last year though (never found time to seriously use it) and I
agree that this was pretty easy. I don't remember if I had to install easyPHP before.
But is installing and then using OFBiz OOTB so different and difficult ? Of course you have to install Java 1.5+ before, but even on
a Linux system it's easy (I'm mostly a Windows User ;p)
Then you run ant-install, then startofbiz and then ... you discover that OFBiz is not as simple as SugarCRM :o) As Jacopo (and
others) explained the point is not installing but using it in real business conditions. At this point you have to have a deeper
knwoledge on business ans tech. aspects and I'm not sure the average SUgarCRM user (or such package) have such a knowledge. Do we
really want to support this level of knwoledge and help this kind of people (nothing pejorative here) grabs OFBiz and for which
goals ? This is the real question !
> My point is that if it's an OOTB solution as the goal or even a forked
> goal of the community, then last March when the 4.0 release was created,
> some effort should have gone into consistent user interfaces,
> installation wizards, documentation, manuals.
We could all benefit from such efforts. I completly agree and moreover I'm already working on it, day by day, hour by hour, minute
by minute, and by chance I'm not alone :o)...
> The communty voted with
> its keyboards to instead add hundreds of new features to the trunk
> instead. Given that the number of bug fixes that have gone into the 4.0
> release can be measured by a human hand testifies that the community is
> addicted to features. NOT THAT IT'S A BAD THING :)
I must admit that I even have difficulties to follow all what is happening this last weeks in OFBiz. But don't we need a better
accouting and project manager components ?
> Me, I've always thought it should be as easy to install OFBiz as any top
> line .php application that asks a few (or as many as is needed)
> questions, confirms and configures itself, and is ready to operate
> within minutes,
I reckon OFBIz is already able to propose that using Derby OOTB. Though you may prefer to install Postgres to quickerly (more
quickly?) run ant-install.
>and the configurator be re-entrant to allow
> configuration changes in the future and also suggest settings for
> certain conditions.
This is the discussion Adrian launched, where a back at it, lot of words for nothing ;o) ? Don't get me wrong, I would love to have
a Wizard configurator, but we can't ignore the issues David pointed out (overidding parameters, with concurrent accesses) !
Jacques
> --
> Walter "rambling post" Vaughan
>
Re: OfBiz System Configuration Wizard
Posted by Scott Gray <le...@gmail.com>.
Not sure how fingers you have but I must have committed at least 100 bug
fixes into 4.0, not to mention all the work done by Jacques and Si.
Regards
Scott
On 15/12/2007, Walter Vaughan <wv...@steelerubber.com> wrote:
>
> Given that the number of bug fixes that have gone into the 4.0
> release can be measured by a human hand testifies that the community is
> addicted to features. NOT THAT IT'S A BAD THING :)
>
>
Re: OfBiz System Configuration Wizard
Posted by Walter Vaughan <wv...@steelerubber.com>.
Jacques Le Roux wrote:
>I'm not sure to see the frontier here...
>
>
Except in the edge case, I don't see how many people who are at the
level of being able to install and operate SugarCRM could do the same
thing with OFBiz. And moving it up a level, compare installing a demo
version of OFBiz with downloading and installing the Microsoft Dynamics
GP 10 demo. Or staying closer to open source, installing postBooks
(http://www.xtuple.com/postbooks).
My point is that if it's an OOTB solution as the goal or even a forked
goal of the community, then last March when the 4.0 release was created,
some effort should have gone into consistent user interfaces,
installation wizards, documentation, manuals. The communty voted with
its keyboards to instead add hundreds of new features to the trunk
instead. Given that the number of bug fixes that have gone into the 4.0
release can be measured by a human hand testifies that the community is
addicted to features. NOT THAT IT'S A BAD THING :)
Me, I've always thought it should be as easy to install OFBiz as any top
line .php application that asks a few (or as many as is needed)
questions, confirms and configures itself, and is ready to operate
within minutes, and the configurator be re-entrant to allow
configuration changes in the future and also suggest settings for
certain conditions.
--
Walter "rambling post" Vaughan
Re: OfBiz System Configuration Wizard
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Walter Vaughan" <wv...@steelerubber.com>
> Adrian Crum wrote:
>
> > At the same time, we do get requests for a configuration UI.
> > Any ideas on how I should proceed? Does anyone see a need for such a
> > feature?
>
>
> Methinks the discussion should first be"the direction of OFBiz":
> is it to be a OOTB solution with a small basic need for customization
> (but the ability to be highly customized)
> or a ERP framework designed for consultants to customize for specific
> client needs?
>
> Let the debate begin... I've set followups to the user-list...
>
> At the end of the day it can't be both... or at least really good at both.
> --
> Walter
>
I'm not sure to see the frontier here...
Jacques
Re: OfBiz System Configuration Wizard
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Dec 13, 2007, at 10:04 AM, Walter Vaughan wrote:
> Adrian Crum wrote:
>
>> At the same time, we do get requests for a configuration UI.
>> Any ideas on how I should proceed? Does anyone see a need for such
>> a feature?
>
>
> Methinks the discussion should first be"the direction of OFBiz":
> is it to be a OOTB solution with a small basic need for
> customization (but the ability to be highly customized)
> or a ERP framework designed for consultants to customize for
> specific client needs?
>
> Let the debate begin... I've set followups to the user-list...
>
> At the end of the day it can't be both... or at least really good at
> both.
Why not?
It doesn't seem too impossible to have a base set of applications
(currently the components in the applications directory), and
extension components that include business level configuration data
and that are specialized for specific purposes (currently in the
specialpurpose directory).
All a user need do is configure system level settings like the
database and such, if they don't want the default settings that come
from SVN.
-David
Re: OfBiz System Configuration Wizard
Posted by BJ Freeman <bj...@free-man.net>.
no real debate, me thinks.
there are two levels of configuration.
1) the level a non technical person can do, like configuring emails for
a store.
2) the consultant that may have to add more seed data, or reconfigure
the GL before it is loaded for a specific industry.
I see this as addressing the first.
Walter Vaughan sent the following on 12/13/2007 9:04 AM:
> Adrian Crum wrote:
>
>> At the same time, we do get requests for a configuration UI.
>> Any ideas on how I should proceed? Does anyone see a need for such a
>> feature?
>
>
> Methinks the discussion should first be"the direction of OFBiz":
> is it to be a OOTB solution with a small basic need for customization
> (but the ability to be highly customized)
> or a ERP framework designed for consultants to customize for specific
> client needs?
>
> Let the debate begin... I've set followups to the user-list...
>
> At the end of the day it can't be both... or at least really good at both.
> --
> Walter
>
>
>
Re: OfBiz System Configuration Wizard
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Walter Vaughan" <wv...@steelerubber.com>
> Adrian Crum wrote:
>
> > At the same time, we do get requests for a configuration UI.
> > Any ideas on how I should proceed? Does anyone see a need for such a
> > feature?
>
>
> Methinks the discussion should first be"the direction of OFBiz":
> is it to be a OOTB solution with a small basic need for customization
> (but the ability to be highly customized)
> or a ERP framework designed for consultants to customize for specific
> client needs?
>
> Let the debate begin... I've set followups to the user-list...
>
> At the end of the day it can't be both... or at least really good at both.
> --
> Walter
>
I'm not sure to see the frontier here...
Jacques
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@hlmksw.com>.
Actually, this has been discussed in the past several times.
Some people in the community view OFBiz as an application framework that consultants or integrators
deploy for their clients.
Others see the possibility of OFBiz becoming an off-the-shelf software program. The specialpurpose
folder is there to help facilitate that kind of development. (By the way, our company uses the Asset
Maintenance component OOTB.)
In addition, there have been requests to make OFBiz less "geeky" - hence the release effort.
So, it all depends on who you ask.
-Adrian
Walter Vaughan wrote:
> Adrian Crum wrote:
>
>> At the same time, we do get requests for a configuration UI.
>> Any ideas on how I should proceed? Does anyone see a need for such a
>> feature?
>
>
>
> Methinks the discussion should first be"the direction of OFBiz":
> is it to be a OOTB solution with a small basic need for customization
> (but the ability to be highly customized)
> or a ERP framework designed for consultants to customize for specific
> client needs?
>
> Let the debate begin... I've set followups to the user-list...
>
> At the end of the day it can't be both... or at least really good at both.
> --
> Walter
>
Re: OfBiz System Configuration Wizard
Posted by Walter Vaughan <wv...@steelerubber.com>.
Adrian Crum wrote:
> At the same time, we do get requests for a configuration UI.
> Any ideas on how I should proceed? Does anyone see a need for such a
> feature?
Methinks the discussion should first be"the direction of OFBiz":
is it to be a OOTB solution with a small basic need for customization
(but the ability to be highly customized)
or a ERP framework designed for consultants to customize for specific
client needs?
Let the debate begin... I've set followups to the user-list...
At the end of the day it can't be both... or at least really good at both.
--
Walter
Re: OfBiz System Configuration Wizard
Posted by BJ Freeman <bj...@free-man.net>.
this is something I implemented
https://issues.apache.org/jira/browse/OFBIZ-1382
it does not created new setup but simplly consolidates those in each
applications.
it does require a new entity, unless someone comes up with a way to
sequence the setups. It is used to enable the menus as setups are done
to keep them in sequence.
Adrian Crum sent the following on 12/13/2007 8:22 AM:
> Marco's recent work in Jira brought this issue to my attention:
>
> https://issues.apache.org/jira/browse/OFBIZ-636.
>
> I would like to start working on that feature. Since that issue was
> created, comments have been made in other discussions on the mailing
> list that may have an impact on the implementation.
>
> The idea is to have a system configuration screen. David mentioned
> recently in an unrelated topic that having a UI for system-level
> configuration would be undesirable:
>
> "If you have a config UI it makes it even more difficult to manage
> because if someone changes something in the UI and someone else writing
> code makes a corresponding configuration in the file system, when the
> data is reloaded you might end up with a change loss problem... and
> that's only one scenario."
>
> At the same time, we do get requests for a configuration UI.
>
> So I'd like to work on this, but there is already a disagreement over
> whether it should be done.
>
> Any ideas on how I should proceed? Does anyone see a need for such a
> feature?
>
> -Adrian
>
>
>
>
>
Re: OfBiz System Configuration Wizard
Posted by BJ Freeman <bj...@free-man.net>.
maybe start having the data files be the entities names.
Let the reader callout be used to sequence the data instead of compound
files.
that way the webtools export can be used to write the new file with new
data thru a service.
David E Jones sent the following on 12/14/2007 4:09 PM:
>
> On Dec 14, 2007, at 6:06 AM, Jacques Le Roux wrote:
>
>> De : "Jonathon -- Improov" <jo...@improov.com>
>>> Like BJ, I had also created my own configurator.
>>>
>>> As for David's point about deployment management and version control
>>> (of config files), I would
>>> agree with Jim Barrows. Those who use the UI configurator would use
>>> it exclusively, and have
>>> someone in charge of documenting all the switches required for a
>>> particular deployment. Those who
>>> use SVN to version control the switches will have similar documents
>>> for the switches, but the
>>> documentation would exist in non-UI form.
>>>
>>> How I use my configurator is like this. I first use it to configure
>>> all switches (written to file,
>>> no storage of settings or configuration flow in database). I then
>>> version control all the config
>>> files. Each time I use the configurator to change something, I commit
>>> the changes switches into SVN.
>>
>> If I understand well, as Adrian outlined, David's concern is with
>> concurrent accesses (Chris Howe seems to look for a possible
>> solution using Xindice ?)
>
> It doesn't really have anything to do with concurrency, my concerns is
> with redundancy and inconsistency. If we put configuration (system or
> business level) in the database, which is what this discussion was
> originally about, then the initial data will come from XML data files.
> If that data is changed in the database but not in the XML files then
> they are out of sync, and if anyone changes one without the other and
> the XML files are used for a new system or to update an existing system
> then strange things may happen (which generally needs to be done
> periodically since we are not omniscient are rarely create or deploy
> systems that don't change).
>
> Right now system level settings such as http, database, cache, debug,
> etc settings are in files and are read from those files; if any of these
> are changed through a UI then the changes are in memory only. Would we
> really want a setup wizard for these things? We certainly could, but
> what is the target audience and intended use process?
>
> Business level settings are done a little differently, and this is where
> the biggest inconsistency lies. Some of these are in properties files
> and others are in the database. In order to have different
> industry-specific or business type specific data sets these that can be
> loaded initially when setting up a system these really should be all in
> the database and configurable through UIs rather than sitting in
> properties files.
>
> I really think the more important things to allow users to configure are
> the business level things. The system level things might be nice, but
> most of those settings should stay the same for really small
> installations where they are using it OOTB. If we did make a config UI
> for system level settings in order to make it easier for non-technical
> users to change things they just might use it... and that could be bad!
> Most of the system level settings require an understanding that
> non-technical users wouldn't have, and we shouldn't make it easy for
> them to hork their entire system and require someone more technical to
> come in and try to figure out what they did, undo any damage (if
> possible!) and then tell them NOT to use the fancy UI we built anyway...
>
> -David
>
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> On Dec 14, 2007, at 9:42 PM, Adrian Crum wrote:
>
>> Thank you for the clarification!
>
>
> Glad it helped... though I'm still left wondering why you're trying so
> hard to argue with every point I make... is my thinking fundamentally
> flawed somewhere? The idea of "making things easier for the user" is
> one I totally agree with, but I don't see how this does that, ie
> looking at the details seems to make the whole thing fall apart...
I'm not really trying to argue with every point you make. As you can tell from the response to this
thread (and previous threads on the same subject), there is a desire in the developer community to
implement some type of UI for system configuration. Other developers have responded with suggestions
on how to make it work. You have expressed your doubts. I'm trying to find a way to address your
concerns while still considering the possibility of having a system configuration UI.
Please don't take my efforts to effect a compromise as some kind of attack on your comments. I'm
agreeing with your concerns, but at the same time I'm trying to come up with ideas for making this work.
>> The system level settings could operate just like any other seed
>> data. It gets loaded during ant run-install and from that point on it
>> is managed from the UI.
>
>
> Oh yeah, how? Nearly ALL of the system level settings are used before
> it can even talk to the database... including the cache, debug,
> database connection, entity AND service engine settings, etc. One of
> the few exceptions is the app server (HTTP, etc) setup, but those are
> still needed for startup and don't really do anything without
> restarting some or all of OFBiz, and for those and other reasons I just
> don't see how the settings being in the database actually HELP us.
You're right - I hadn't thought of that! Then the settings should remain in properties files.
>> Maybe we could identify particular areas as "do not touch" and make
>> it clear in the UI that a user shouldn't change those settings.
>> That's one of the advantages I see in the UI configuration wizard (or
>> screen) - instead of a simplistic "key=value" setting in a property
>> file, the UI could explain the setting and the pros and cons of
>> changing it.
>>
>> If a consultant or systems integrator wanted to prevent a user from
>> altering consultant-supplied settings, then they could disable the
>> configuration screen.
>
>
> I'm seeing more arguments for disabling it than for having it... I
> still haven't seen a target audience or end-user scenario that points
> to this being useful...
There have been scenarios presented already. It seems you have overlooked them.
-Adrian
Re: OfBiz System Configuration Wizard
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Dec 14, 2007, at 9:42 PM, Adrian Crum wrote:
> Thank you for the clarification!
Glad it helped... though I'm still left wondering why you're trying so
hard to argue with every point I make... is my thinking fundamentally
flawed somewhere? The idea of "making things easier for the user" is
one I totally agree with, but I don't see how this does that, ie
looking at the details seems to make the whole thing fall apart...
> I understand your point of view, but the idea that a user could muck
> up existing data is true for all of OFBiz. How many emails do we see
> about product catalog configuration problems? In addition, a user
> could delete admin permissions using the Party Manager component and
> end up locking themselves out of the system. The scenario you
> described could be applied equally to many areas of OFBiz.
Logical fallacy: false analogy.
These are different knowledge domains. One way or another a user must
understand the domain they work with. If someone does understand the
technical domain they shouldn't have a problem following the
instructions in the technical production setup guide. On the other
hand if someone does not understand, and shouldn't be expected to
understand, the system level settings they might still trying to play
with things there and would complain of lack of documentation for
things like JDBC URI strings that I don't think we want to get into
documenting for end-users. We certainly could, but do we really want
to make that a priority?
> The system level settings could operate just like any other seed
> data. It gets loaded during ant run-install and from that point on
> it is managed from the UI.
Oh yeah, how? Nearly ALL of the system level settings are used before
it can even talk to the database... including the cache, debug,
database connection, entity AND service engine settings, etc. One of
the few exceptions is the app server (HTTP, etc) setup, but those are
still needed for startup and don't really do anything without
restarting some or all of OFBiz, and for those and other reasons I
just don't see how the settings being in the database actually HELP us.
> Maybe we could identify particular areas as "do not touch" and make
> it clear in the UI that a user shouldn't change those settings.
> That's one of the advantages I see in the UI configuration wizard
> (or screen) - instead of a simplistic "key=value" setting in a
> property file, the UI could explain the setting and the pros and
> cons of changing it.
>
> If a consultant or systems integrator wanted to prevent a user from
> altering consultant-supplied settings, then they could disable the
> configuration screen.
I'm seeing more arguments for disabling it than for having it... I
still haven't seen a target audience or end-user scenario that points
to this being useful...
-David
> David E Jones <jo...@hotwaxmedia.com> wrote:It doesn't really have
> anything to do with concurrency, my concerns is
> with redundancy and inconsistency. If we put configuration (system or
> business level) in the database, which is what this discussion was
> originally about, then the initial data will come from XML data files.
> If that data is changed in the database but not in the XML files then
> they are out of sync, and if anyone changes one without the other and
> the XML files are used for a new system or to update an existing
> system then strange things may happen (which generally needs to be
> done periodically since we are not omniscient are rarely create or
> deploy systems that don't change).
>
> Right now system level settings such as http, database, cache, debug,
> etc settings are in files and are read from those files; if any of
> these are changed through a UI then the changes are in memory only.
> Would we really want a setup wizard for these things? We certainly
> could, but what is the target audience and intended use process?
>
> Business level settings are done a little differently, and this is
> where the biggest inconsistency lies. Some of these are in properties
> files and others are in the database. In order to have different
> industry-specific or business type specific data sets these that can
> be loaded initially when setting up a system these really should be
> all in the database and configurable through UIs rather than sitting
> in properties files.
>
> I really think the more important things to allow users to configure
> are the business level things. The system level things might be nice,
> but most of those settings should stay the same for really small
> installations where they are using it OOTB. If we did make a config UI
> for system level settings in order to make it easier for non-technical
> users to change things they just might use it... and that could be
> bad! Most of the system level settings require an understanding that
> non-technical users wouldn't have, and we shouldn't make it easy for
> them to hork their entire system and require someone more technical to
> come in and try to figure out what they did, undo any damage (if
> possible!) and then tell them NOT to use the fancy UI we built
> anyway...
>
> -David
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals? Find them fast with Yahoo!
> Search.
Re: OfBiz System Configuration Wizard
Posted by Jacopo Cappellato <ti...@sastau.it>.
I think that system settings should stay in config files, not in the
database; if the goal is to simplify the configuration steps described
in the production setup guide, then there are probably different ways of
addressing this:
a) deliver a separate set of config files already configured for a
"standard" production (cache enabled, verbose logs disabled etc...); we
may also consider to deliver these settings in the release branch, and
maintain the dev settings in the trunk
b) implement an ant-based wizard (to be run during the installation of
OFBiz) that prompts the user for some common settings (http port, https
port, mail server address, db used, db user/password, db url etc...) and
then modify the OFBiz's files (or, we could prapare *one* simple file
where the user can enter all these values, then run the ant script that
places then in all the relevant OFBiz files)
c) clean up the existing config files; for example, the entityengine,xml
contains the settings for a lot of different databases; we could keep
the settings for just one of them and move the others into a separate
file, or create one file per database etc...
Of course, for more complex (real World) setups, you'll have to follow
the steps of the production setup guide... but for simpler ones it could
work.
just my 2 cents
Jacopo
Adrian Crum wrote:
> David,
>
> Thank you for the clarification!
>
> I understand your point of view, but the idea that a user could muck up existing data is true for all of OFBiz. How many emails do we see about product catalog configuration problems? In addition, a user could delete admin permissions using the Party Manager component and end up locking themselves out of the system. The scenario you described could be applied equally to many areas of OFBiz.
>
> The system level settings could operate just like any other seed data. It gets loaded during ant run-install and from that point on it is managed from the UI.
>
> Maybe we could identify particular areas as "do not touch" and make it clear in the UI that a user shouldn't change those settings. That's one of the advantages I see in the UI configuration wizard (or screen) - instead of a simplistic "key=value" setting in a property file, the UI could explain the setting and the pros and cons of changing it.
>
> If a consultant or systems integrator wanted to prevent a user from altering consultant-supplied settings, then they could disable the configuration screen.
>
> -Adrian
>
> David E Jones <jo...@hotwaxmedia.com> wrote:It doesn't really have anything to do with concurrency, my concerns is
> with redundancy and inconsistency. If we put configuration (system or
> business level) in the database, which is what this discussion was
> originally about, then the initial data will come from XML data files.
> If that data is changed in the database but not in the XML files then
> they are out of sync, and if anyone changes one without the other and
> the XML files are used for a new system or to update an existing
> system then strange things may happen (which generally needs to be
> done periodically since we are not omniscient are rarely create or
> deploy systems that don't change).
>
> Right now system level settings such as http, database, cache, debug,
> etc settings are in files and are read from those files; if any of
> these are changed through a UI then the changes are in memory only.
> Would we really want a setup wizard for these things? We certainly
> could, but what is the target audience and intended use process?
>
> Business level settings are done a little differently, and this is
> where the biggest inconsistency lies. Some of these are in properties
> files and others are in the database. In order to have different
> industry-specific or business type specific data sets these that can
> be loaded initially when setting up a system these really should be
> all in the database and configurable through UIs rather than sitting
> in properties files.
>
> I really think the more important things to allow users to configure
> are the business level things. The system level things might be nice,
> but most of those settings should stay the same for really small
> installations where they are using it OOTB. If we did make a config UI
> for system level settings in order to make it easier for non-technical
> users to change things they just might use it... and that could be
> bad! Most of the system level settings require an understanding that
> non-technical users wouldn't have, and we shouldn't make it easy for
> them to hork their entire system and require someone more technical to
> come in and try to figure out what they did, undo any damage (if
> possible!) and then tell them NOT to use the fancy UI we built anyway...
>
> -David
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Re: OfBiz System Configuration Wizard
Posted by Adrian Crum <ad...@yahoo.com>.
David,
Thank you for the clarification!
I understand your point of view, but the idea that a user could muck up existing data is true for all of OFBiz. How many emails do we see about product catalog configuration problems? In addition, a user could delete admin permissions using the Party Manager component and end up locking themselves out of the system. The scenario you described could be applied equally to many areas of OFBiz.
The system level settings could operate just like any other seed data. It gets loaded during ant run-install and from that point on it is managed from the UI.
Maybe we could identify particular areas as "do not touch" and make it clear in the UI that a user shouldn't change those settings. That's one of the advantages I see in the UI configuration wizard (or screen) - instead of a simplistic "key=value" setting in a property file, the UI could explain the setting and the pros and cons of changing it.
If a consultant or systems integrator wanted to prevent a user from altering consultant-supplied settings, then they could disable the configuration screen.
-Adrian
David E Jones <jo...@hotwaxmedia.com> wrote:It doesn't really have anything to do with concurrency, my concerns is
with redundancy and inconsistency. If we put configuration (system or
business level) in the database, which is what this discussion was
originally about, then the initial data will come from XML data files.
If that data is changed in the database but not in the XML files then
they are out of sync, and if anyone changes one without the other and
the XML files are used for a new system or to update an existing
system then strange things may happen (which generally needs to be
done periodically since we are not omniscient are rarely create or
deploy systems that don't change).
Right now system level settings such as http, database, cache, debug,
etc settings are in files and are read from those files; if any of
these are changed through a UI then the changes are in memory only.
Would we really want a setup wizard for these things? We certainly
could, but what is the target audience and intended use process?
Business level settings are done a little differently, and this is
where the biggest inconsistency lies. Some of these are in properties
files and others are in the database. In order to have different
industry-specific or business type specific data sets these that can
be loaded initially when setting up a system these really should be
all in the database and configurable through UIs rather than sitting
in properties files.
I really think the more important things to allow users to configure
are the business level things. The system level things might be nice,
but most of those settings should stay the same for really small
installations where they are using it OOTB. If we did make a config UI
for system level settings in order to make it easier for non-technical
users to change things they just might use it... and that could be
bad! Most of the system level settings require an understanding that
non-technical users wouldn't have, and we shouldn't make it easy for
them to hork their entire system and require someone more technical to
come in and try to figure out what they did, undo any damage (if
possible!) and then tell them NOT to use the fancy UI we built anyway...
-David
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Re: OfBiz System Configuration Wizard
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Dec 14, 2007, at 6:06 AM, Jacques Le Roux wrote:
> De : "Jonathon -- Improov" <jo...@improov.com>
>> Like BJ, I had also created my own configurator.
>>
>> As for David's point about deployment management and version
>> control (of config files), I would
>> agree with Jim Barrows. Those who use the UI configurator would use
>> it exclusively, and have
>> someone in charge of documenting all the switches required for a
>> particular deployment. Those who
>> use SVN to version control the switches will have similar documents
>> for the switches, but the
>> documentation would exist in non-UI form.
>>
>> How I use my configurator is like this. I first use it to configure
>> all switches (written to file,
>> no storage of settings or configuration flow in database). I then
>> version control all the config
>> files. Each time I use the configurator to change something, I
>> commit the changes switches into SVN.
>
> If I understand well, as Adrian outlined, David's concern is with
> concurrent accesses (Chris Howe seems to look for a possible
> solution using Xindice ?)
It doesn't really have anything to do with concurrency, my concerns is
with redundancy and inconsistency. If we put configuration (system or
business level) in the database, which is what this discussion was
originally about, then the initial data will come from XML data files.
If that data is changed in the database but not in the XML files then
they are out of sync, and if anyone changes one without the other and
the XML files are used for a new system or to update an existing
system then strange things may happen (which generally needs to be
done periodically since we are not omniscient are rarely create or
deploy systems that don't change).
Right now system level settings such as http, database, cache, debug,
etc settings are in files and are read from those files; if any of
these are changed through a UI then the changes are in memory only.
Would we really want a setup wizard for these things? We certainly
could, but what is the target audience and intended use process?
Business level settings are done a little differently, and this is
where the biggest inconsistency lies. Some of these are in properties
files and others are in the database. In order to have different
industry-specific or business type specific data sets these that can
be loaded initially when setting up a system these really should be
all in the database and configurable through UIs rather than sitting
in properties files.
I really think the more important things to allow users to configure
are the business level things. The system level things might be nice,
but most of those settings should stay the same for really small
installations where they are using it OOTB. If we did make a config UI
for system level settings in order to make it easier for non-technical
users to change things they just might use it... and that could be
bad! Most of the system level settings require an understanding that
non-technical users wouldn't have, and we shouldn't make it easy for
them to hork their entire system and require someone more technical to
come in and try to figure out what they did, undo any damage (if
possible!) and then tell them NOT to use the fancy UI we built anyway...
-David
Re: OfBiz System Configuration Wizard
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Jonathon -- Improov" <jo...@improov.com>
> Like BJ, I had also created my own configurator.
>
> As for David's point about deployment management and version control (of config files), I would
> agree with Jim Barrows. Those who use the UI configurator would use it exclusively, and have
> someone in charge of documenting all the switches required for a particular deployment. Those who
> use SVN to version control the switches will have similar documents for the switches, but the
> documentation would exist in non-UI form.
>
> How I use my configurator is like this. I first use it to configure all switches (written to file,
> no storage of settings or configuration flow in database). I then version control all the config
> files. Each time I use the configurator to change something, I commit the changes switches into SVN.
If I understand well, as Adrian outlined, David's concern is with concurrent accesses (Chris Howe seems to look for a possible
solution using Xindice ?)
Jacques
> Jonathon
>
> Adrian Crum wrote:
> > Marco's recent work in Jira brought this issue to my attention:
> >
> > https://issues.apache.org/jira/browse/OFBIZ-636.
> >
> > I would like to start working on that feature. Since that issue was
> > created, comments have been made in other discussions on the mailing
> > list that may have an impact on the implementation.
> >
> > The idea is to have a system configuration screen. David mentioned
> > recently in an unrelated topic that having a UI for system-level
> > configuration would be undesirable:
> >
> > "If you have a config UI it makes it even more difficult to manage
> > because if someone changes something in the UI and someone else writing
> > code makes a corresponding configuration in the file system, when the
> > data is reloaded you might end up with a change loss problem... and
> > that's only one scenario."
> >
> > At the same time, we do get requests for a configuration UI.
> >
> > So I'd like to work on this, but there is already a disagreement over
> > whether it should be done.
> >
> > Any ideas on how I should proceed? Does anyone see a need for such a
> > feature?
> >
> > -Adrian
> >
> >
> >
>
Re: OfBiz System Configuration Wizard
Posted by Jonathon -- Improov <jo...@improov.com>.
Like BJ, I had also created my own configurator.
As for David's point about deployment management and version control (of config files), I would
agree with Jim Barrows. Those who use the UI configurator would use it exclusively, and have
someone in charge of documenting all the switches required for a particular deployment. Those who
use SVN to version control the switches will have similar documents for the switches, but the
documentation would exist in non-UI form.
How I use my configurator is like this. I first use it to configure all switches (written to file,
no storage of settings or configuration flow in database). I then version control all the config
files. Each time I use the configurator to change something, I commit the changes switches into SVN.
Jonathon
Adrian Crum wrote:
> Marco's recent work in Jira brought this issue to my attention:
>
> https://issues.apache.org/jira/browse/OFBIZ-636.
>
> I would like to start working on that feature. Since that issue was
> created, comments have been made in other discussions on the mailing
> list that may have an impact on the implementation.
>
> The idea is to have a system configuration screen. David mentioned
> recently in an unrelated topic that having a UI for system-level
> configuration would be undesirable:
>
> "If you have a config UI it makes it even more difficult to manage
> because if someone changes something in the UI and someone else writing
> code makes a corresponding configuration in the file system, when the
> data is reloaded you might end up with a change loss problem... and
> that's only one scenario."
>
> At the same time, we do get requests for a configuration UI.
>
> So I'd like to work on this, but there is already a disagreement over
> whether it should be done.
>
> Any ideas on how I should proceed? Does anyone see a need for such a
> feature?
>
> -Adrian
>
>
>