Configuration Management

Currently we have a complicated system of config files. Some data is kept twice. Updating the configuration is slightly hard and requires special know how.
Most configuration values can be put into the database in the futuree, and be merged transparently into the used Zend_Config Object.

Features and advantages of using config stored in the DB

• Updating and inserting new config values is simple: We put the new / changed config values into an own “new config table”
• The default config-value is always present in an extra table field for clarity.
• The table structure should allow a set of chooseable values (select box instead text field in frontend).
• The config table should contain a “module” field, to filter the config values by used zend module. Task or User specific config values are theoretically also possible.
• In the update process we loop over the “new config table”, and show all new values to the user
  • the user will see the config title / description
  • the user will see the old value if the config had already been customized by him and the default value had been changed. The user then should be able to choose between the new default or the old specific value
  • the user should be able to change the values
• all runtime options are centralized to the DB and an own configuration panel
• for sorting / grouping features we should introduce a "setting group" and a "importance" column. The latter one can be used for sorting / highlighting the configuration field in the frontend
  • We should implement a own ExtJs-based professional GUI for the settings. That means access the config by REST. A property grid in the Frontend should do the job.
• For the updater also a frontend is needed. The contents can be produced automatically out of the contents in the “new config table”. That means in the update process, that we can provide config changes as an SQL script. After applying the SQL scripts, the updater checks if there are config changes in new config table. If yes, show them to the user as described earlier.
• If needed, conditional, automatic value changes can be performed directly in SQL
• If needed, we can determine configuration values automatically on installation time. For example: we are check for java, if no java runtime is found, the termtagger feature can then be disabled by configuration.

Remaining as INI file

Some settings have to remain in INI files. These are system near settings like DB credentials, phpSettings, includePaths, autoloaderNamespaces, resource plugins, ACL Definitions. These settings must only be changed by developers for implementation and integration of new features.
So no complex update mechanism is needed for most of this files, since we can overwrite them directly with updated files out of the release.
One exception would be the ini file containing the DB credentials, created on installation time. This file should not be updated or overwritten, so we don't expect problems here either.

An own INI Parser and Writer, (keeping comments and user changes, which Zend-ini-parser does not) is no alternative to putting config-files in DB, because it is much more complex and error prone.

Overview over current INI Files:

In the following list all config files of the beo application are listed. Under the filename is described what should happen with the file.
Below is described which contents go to where. This is not complete though and must be reviewed when it is implemented

• ./application/extVersionMapping.ini
  → should be removed, contents go to /application/config/application.ini
• ./application/application.ini
  → should be removed, contents go to DB and /application/config/application.ini
• ./application/languages.ini
  → should be removed, contents go into database. Evaluate current usage.
• ./application/iniOverwrites/CLIENTID/defaultApplication.ini
  → should be removed, contents go to DB and /application/config/installation.ini
• ./application/iniOverwrites/CLIENTID/factoryOverwrites.ini
  → should be removed, contents go to /application/config/application.ini
• ./application/iniOverwrites/CLIENTID/application.ini
  → should be removed, contents go to /application/config/installation.ini ./application/iniOverwrites/CLIENTID/defaultAclConfig.ini
  → should be removed, contents are in module aclConfig and DB
  Caution: Currently both files differ. The overwrites values should go to the statndard aclConfig, as you wrote, but the old values should be kept for information purposes as comments
• ./application/iniOverwrites/CLIENTID/languages.ini
  → should be removed, contents go into database. Evaluate current usage.
• ./application/iniOverwrites/CLIENTID/helpDeactivated.ini
  → this can go to ./application/modules/default/configs/module.ini
• ./application/iniOverwrites/CLIENTID/editorApplication.ini
  → should be removed, contents go to DB and /application/config/application.ini
• ./application/iniOverwrites/CLIENTID/editorAclConfig.ini
  → should be removed, contents are in module aclConfig and DB
• ./application/iniOverwrites/CLIENTID/editorconnectAclConfig.ini.sample
  → should be removed, contents are in module aclConfig and DB
• ./application/iniOverwrites/CLIENTID/editorconnectApplication.ini.sample
  → should be removed, contents go to DB and /application/config/installation.ini
• ./application/modules/editor/configs/aclConfig.ini
  → remains for all expect section rules, rules goes into DB
• ./application/modules/editor/configs/application.ini
  → split into module.ini and application.ini
• ./application/modules/default/configs/aclConfig.ini
  → remains for all expect section rules, rules goes into DB
• ./application/modules/default/configs/application.ini
  → split into module.ini and application.ini
• ./application/modules/editorconnect/configs/aclConfig.ini
  → remains for all expect section rules, rules goes into DB
• ./application/modules/editorconnect/configs/application.ini
  → split into module.ini and application.ini

New INI Files

• ./application/config/application.ini → contains application specific settings, also factory overwrites can come out of this file.
• ./application/config/installation.ini → contains installation specific settings, like DB credentials. In general this file should not be in git, since its installation specific. For tracking our local dev inis, we can link it into mittagqi_meta git.
  The contents of installation.ini should overwrite application.ini entries.
• ./application/modules/MODULE/config/application.ini → contains application wide, MODULE specific system settings (resource and path things), in most modules this file wont exist, since the settings are either in DB, or they are module specific and must not be shared across all modules. FIXME Evaluate if this application wide is needed, one example would be shared editorconnect settings, I dont if this would be done with the DB thing.
• ./application/modules/MODULE/config/module.ini → contains module specific system settings
• ./application/modules/MODULE/config/acl.ini → contains module specific ACL Definitions (all out of old inis, expect rules)
• ./application/iniOverwrites/CLIENTID/helpDeactivated.ini
  → this can go to ./application/modules/default/configs/module.ini

One thing we had forgotten is the APPLICATION_RUNDIR, this should also come from installation.ini.

INI Overwrite Extension Rules

see attached image

ACL INIs

The content of the acl.ini file can be broken apart:

1. A Definition Part with the roles, frontendRights and resources definitions
2. A Rules Part with all the rules, which should be client specific.
   Since the definitions are normally not changed by the client, we can update them easily. There should be no need to extend this acl definition file.
   The acl rules instead are client specific, they should also come from DB. One table contains the default rules, with a version identifier, and description.
   The custom table contains the customized rules.

Languages INI

Currently we have a languages table and a languages.ini file. The latter one should be abolished.

ExtVersionMapping.ini

Content of ExtVersion Mapping goes into application.ini. Client has nothing to change in there.