Why IPS block other settings in conf_global in 4.2.4 ?

[Numbered]

Hi IPS!

We have a lot of applications and plugins in our IPS instances. Much of them using a lot of connections to other services, passwords, keys, some other values. Our DevOps team use fabric for operation thousands of different services and their connections between. So, our IPS config file is generated by them. With one command we can change keys, mysql hosts, other services adressess (if something happened and we need to switch it to something else).

In 4.2.3 => 4.2.4 update in file system/Settings/Settings.php on line 54 you added new array of allowed fields in conf_global and in line 76 your unset any others values, which are not allowed by you! Why? Now we need to create something very special for manage our settings? We can't manage it in GUI (because we have a very huge count of services), we can't write some additional script, which will change our values in SQL (or other datastore). Our actual config settings, placed in conf_global was very good. In < 4.2.4 we can set default values in app/plugin settings, we can set this setting in conf_global, we can store second level in sql settings table, and we can level 3 which level is more important and rewrite other levels - in conf_global. It was very good.

I am very angry and don't know why you do this and angry about current needs for create something new, which will restore our devops server managements..

How now we need to do this?

[Numbered]

I can't understand what problem you fixed with that 'improvement'. What positive this update bring for you and us.. Now i see only 'why not' idea of that 

[Matt]

Hi,

I understand your concerns. The issue we had is that a lot of people who have upgraded from previous versions such as 3 have a lot of data in their conf_global.php from a time where settings were partially stored in that file. This had an impact where we'd see that conf_global data was being written back to datastore, overwriting what was in the database.

However, you raise a valid point. What I'll do is create a method to populate the whitelist of keys, and you can then override that in a hook with your software allowing you to state any other fields you wish to allow from conf_global.

[Matt]

Just a note to say I've just committed this change for 4.2.5.

[Numbered]

6 minutes ago, Matt said:

The issue we had is that a lot of people who have upgraded from previous versions such as 3 have a lot of data in their conf_global.php from a time where settings were partially stored in that file. This had an impact where we'd see that conf_global data was being written back to datastore, overwriting what was in the database.

But this is not resolve the problem of old settings in conf_global. May be better in some upgrade script add questions about settings in this file and add to users ability to choose what he want to do (clean up all - by default or manage that) + add special checks in internal health checks for collisions?

9 minutes ago, Matt said:

However, you raise a valid point. What I'll do is create a method to populate the whitelist of keys, and you can then override that in a hook with your software allowing you to state any other fields you wish to allow from conf_global.

If I understand you well - you'll create ability to create a hook-file, which can extend list of allowed settings in conf_global? If yes - good. It will be perfect! All plugins and apps can extend this list specially for themself needed keys  

Thanks

[Matt]

31 minutes ago, Upgradeovec said:

If I understand you well - you'll create ability to create a hook-file, which can extend list of allowed settings in conf_global? If yes - good. It will be perfect! All plugins and apps can extend this list specially for themself needed keys  

 

Yes, that's exactly it.