OfBiz System Configuration Wizard

[Adrian Crum]

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

[BJ Freeman]

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
>
>
>
>
>

[Jim Barrows]

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 <[hidden email]> 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

[Adrian Crum]

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.

[Walter Vaughan]

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

[Adrian Crum]

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
>

[BJ Freeman]

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
>
>
>

[Jacques Le Roux]

De : "Walter Vaughan" <[hidden email]>

> 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

[David E Jones]

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

[David E Jones]

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

[Adrian Crum]

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

[cjhowe]

I don't understand why there would be two paths to file modification.  Why wouldn't the UI Wizard write directly to the same file that holds the current configuration information?
Adrian wrote:---------------------------------------
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

[Adrian Crum]

I think the point David is making (and I hope I'm not misquoting ;-) ) is that you could potentially
have two people trying to change the same system settings - a consultant/system integrator, and an
admin or super user.


Chris Howe wrote:

> I don't understand why there would be two paths to file modification.  Why wouldn't the UI Wizard write directly to the same file that holds the current configuration information?
> Adrian wrote:---------------------------------------
> 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
>
>
>
>
>
>

[cjhowe]

This is an area that I have some interest in.  The Xindice stuff done earlier this year may be of some help.  Let me know when you guys sort out how many angels can dance on the tip of a pin.  This eventuality may be over thinking design a bit much.  

----- Original Message ----
From: Adrian Crum <[hidden email]>
To: [hidden email]
Sent: Thursday, December 13, 2007 7:08:53 PM
Subject: Re: OfBiz System Configuration Wizard


I think the point David is making (and I hope I'm not misquoting ;-) )
 is that you could potentially
have two people trying to change the same system settings - a
 consultant/system integrator, and an
admin or super user.


Chris Howe wrote:

> I don't understand why there would be two paths to file modification.
  Why wouldn't the UI Wizard write directly to the same file that holds
 the current configuration information?
> Adrian wrote:---------------------------------------
> 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
>
>
>
>
>
>

[jonwimp]

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
>
>
>

[cjhowe]

The answer appears to be one, considering only one angel ever learned how to dance.  In any event, you can check the last modified file attributes:
http://www.w3.org/Jigsaw/Doc/Programmer/samples/FileResource.html
if last modified is greater than initial read...throw error

----- Original Message ----
From: Chris Howe <[hidden email]>
To: [hidden email]
Sent: Thursday, December 13, 2007 7:20:30 PM
Subject: Re: OfBiz System Configuration Wizard


This is an area that I have some interest in.  The Xindice stuff done
 earlier this year may be of some help.  Let me know when you guys sort
 out how many angels can dance on the tip of a pin.  This eventuality may
 be over thinking design a bit much.  

----- Original Message ----
From: Adrian Crum <[hidden email]>
To: [hidden email]
Sent: Thursday, December 13, 2007 7:08:53 PM
Subject: Re: OfBiz System Configuration Wizard


I think the point David is making (and I hope I'm not misquoting ;-) )
 is that you could potentially
have two people trying to change the same system settings - a
 consultant/system integrator, and an
admin or super user.


Chris Howe wrote:

> I don't understand why there would be two paths to file modification.
  Why wouldn't the UI Wizard write directly to the same file that holds
 the current configuration information?
> Adrian wrote:---------------------------------------
> 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
>
>
>
>
>
>

[Jacques Le Roux]

De : "Jonathon -- Improov" <[hidden email]>

> 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
> >
> >
> >
>

[David E Jones]

On Dec 14, 2007, at 6:06 AM, Jacques Le Roux wrote:

> De : "Jonathon -- Improov" <[hidden email]>
>> 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

[BJ Freeman]

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" <[hidden email]>
>>> 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
>

[Adrian Crum-2]

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 <[hidden email]> 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.