CRM-11027 Move various settings from Config Object to settings table

The Miscelleaneous Settings form is currently broken - fatal error below. Surprised you didn't try it Commenting out the formRule allows the form to load. I think you'll need to pass formRule metadata for these elements to the parent class (Admin_Form_Setting) if you want the parent class to define the quickform fields.

---------
2 /Users/dgg/svn/crm_v4.3/packages/PEAR.php(931): call_user_func((Array:2), Object(HTML_QuickForm_Error))
#3 /Users/dgg/svn/crm_v4.3/packages/HTML/QuickForm.php(2156): PEAR_Error->PEAR_Error("nonexistent html element", -3, 16, (Array:2), "Element 'max_attachments' does not exist in HTML_QuickForm::addRule()")
#4 /Users/dgg/svn/crm_v4.3/packages/PEAR.php(564): HTML_QuickForm_Error->HTML_QuickForm_Error(-3, 16, (Array:2), "Element 'max_attachments' does not exist in HTML_QuickForm::addRule()")
#5 /Users/dgg/svn/crm_v4.3/packages/HTML/QuickForm.php(1082): PEAR->raiseError(NULL, -3, NULL, 512, "Element 'max_attachments' does not exist in HTML_QuickForm::addRule()", "HTML_QuickForm_Error", TRUE)
#6 /Users/dgg/svn/crm_v4.3/CRM/Admin/Form/Setting/Miscellaneous.php(96): HTML_QuickForm->addRule("max_attachments", "Value should be a positive number", "positiveInteger")
#7 /Users/dgg/svn/crm_v4.3/CRM/Core/Form.php(350): CRM_Admin_Form_Setting_Miscellaneous->buildQuickForm()

I'm a bit stymied on this because I can't get my site up & working due to the current upgrade bugs & I can't run unit tests due to bugs introduced into the test setup.

When I last had access the converted settings were loading (max_attachments, undelete) when calling civicrm_api('system', 'flush', array('version' => 3)) or the underlying CRM_Core_BAO_SETTING::updateSettingsFromMetaData(); function. The unit tests I had running (now failing along with all domain related tests) were showing this to be working. Running the system flush from the api explorer works on the server sandbox.

However, I am told that the setup.sh (which I don't use because I think it's better to put the effort into finding the bugs that occur when real data is in use) doesn't load the default settings correctly (and I don't know why not). So, not sure whether to add to the install script as I don't know how that will pan out. I think it might be worth adding the call to the rebuildMenu call (e.g. patch below) but I can't test @ the moment.

I have attached a patch of how converting one setting (thousand separator) should look. I haven't tested this (I did a while back but I reverted the work I'd done on this & another setting in order to clean up my svn because the changes had been uncommitted for a while.

Index: CRM/Admin/Form/Setting.php
===================================================================
— CRM/Admin/Form/Setting.php (revision 43808)
+++ CRM/Admin/Form/Setting.php (working copy)
@@ -268,6 +268,9 @@
// also delete the IDS file so we can write a new correct one on next load
$configFile = $config->uploadDir . 'Config.IDS.ini';
@unlink($configFile);
+
+ CRM_Core_BAO_SETTING::updateSettingsFromMetaData();
+
}
}

nb - don't suppose there will be any capacity / interest in this @ Toronto sprint?

Hey Coleman - you said you'd have a go @ debugging why the settings don't fill out of setup.sh - would be great if you could try because setup.sh has never worked on my setup & I've always been resistant to pumping time into it when spending the time on trying to get it to work with real data seems so much more useful

I've added the 2 test settings to civicrm.generated.mysql - so that will be picked up by setup.sh.

I'm no longer planning on moving any more settings across so I think we can call this done now.

BTW Coleman, I did look at the tidy up you did on my code & it all makes sense - I had to look a couple of things up but I learnt from it ( note to self if-space-parenthesis )