Customer specific config files

pokorra

Hello all,
we have had questions in the bug tracker about OM specific partner types, eg. OMER.
Other things more sensitive might also need a customisation.

I guess we agreed that the cleanest way of resolving things like this is to provide the custom values as parameters in the server or in the config file.
For the public generic version of OpenPetra, the default value would be used.

For example:

   ATypeList = TAppSettingsManager.GetValue("DEFAULTWORKERTYPES", "WORKER;EX-WORKER;ASSOC", false);

In an OM specific config file, we would have this row:

  <add key="DEFAULTWORKERTYPES" value="OM;EX-OMER;ASSOC"/>

The question is now:
Where do we recommend an organisation to store such a specific config file? Does that config file contain sensitive data? Can we store the file in the public?
If public was ok, we could recommend to create a public branch on Launchpad, and keep the modified config file there.
Otherwise, we could recommend to customers or their service providers, to use the commercial offer at Launchpad (launchpad.net/+tour/join-launchpad), or have their own bazaar server, or just maintain the config file locally.

We can probably have the discussion, how OM goes about their own specific config file (and specific base database), somewhere off the forum. But the general questions might be interesting to others as well.

christiankatict

I think the options that you listed are sufficient for achieving the example that you provided - customisation of some display strings and hard-coded application features that might depend on such display strings.
Depending on whether the features in the application that require such customisation functionality need such customisations on client side or server side, or both, the lines in the config file will need to be put in the client config file, the server config file, or both.

However, for more advanced customisations that can not be realised just by strings in a config file, different organisations would need to create plug-in DLL's that contain customised functionality that they can call. The C# code for those C# files would need to be hosted 'somewhere' as well. DLL's for functionality that would be needed both on client and server side would need to be in the Ict.Petra.Shared.* Namespace so the functionality can be accessed on both sides.

Kind regards,

ChristianK