CiviCRM Community Forums (archive)

I have committed the setting api into trunk (sponsored by JMA consulting). This allows the following actions

- get
- create
- getvalue (intended for runtime use, more required params)
- getfields
- getdefaults
- revert
- fill

With the exception of getvalue these actions leverage xml definitions of the various settings. As the settings are stored as a serialised string the create action needs to know the variable type and this is defined in the xml - along with other metadata such as a validation callback & the default value.

It is possible for a module to add it's own path to the metadata to be loaded and for it to alter the metadata from the core xml. A likely scenario is that a module wishes to change / set various defaults to reflect localisation of currency, address format etc. The module may choose to revert various settings back to the defaults it has defined (e.g. on installation) or only to 'fill' those defaults in if they don't exist.

There is still a fair bit of tidying to do / things to be mulled / questions to be answered. The ticket is http://issues.civicrm.org/jira/browse/CRM-10040 & I'll hunt out the various links.

In all cases the domain_id is implicitly the current_domain but an id, an array of ids or 'all' are accepted. I would like this behaviour to be the same across all api

Hi,

That's great! This is what I get with the api explorer

{
"is_error":0,
"undefined_fields":["domain_id"],
"version":3,
"count":1,
"id":1,
"values":[{
"is_enabled":"0",
"domain_group_id":"0",
"event_price_set_domain_id":"0",
"uniq_email_per_site":"0",
"tag_unconfirmed":"Unconfirmed",
"petition_contacts":"Petition Contacts",
"contact_view_options":["1","2","3","4","5","6","7","8","9","10","11","13"],
"contact_edit_options":["1","2","3","4","5","6","7","8","9","10","11"],
"advanced_search_options":["1","2","3","4","5","6","7","8","9","10","11","12","13","15","16","17","18","19"],
"user_dashboard_options":["1","2","3","4","5","7","8"],
"address_options":["1","2","3","4","5","6","8","9","10","11"],
"address_format":"{contact.address_name}\n{contact.street_address}\n{contact.supplemental_address_1}\n{contact.supplemental_address_2}\n{contact.city}{, }{contact.state_province}{ }{contact.postal_code}\n{contact.country}",
"mailing_format":"{contact.addressee}\n{contact.street_address}\n{contact.supplemental_address_1}\n{contact.supplemental_address_2}\n{contact.city}{, }{contact.state_province}{ }{contact.postal_code}\n{contact.country}",
"display_name_format":"{contact.individual_prefix}{ }{contact.first_name}{ }{contact.last_name}{ }{contact.individual_suffix}",
"sort_name_format":"{contact.last_name}{, }{contact.first_name}",
"editor_id":"2",
"contact_ajax_check_similar":"1",
"activity_assignee_notification":"1",
"contact_autocomplete_options":["1","2"],
"contact_reference_options":["1","2"],
"enable_cart":"0",
"profile_double_optin":"1",
"track_civimail_replies":"0",
"civimail_workflow":"0",
"civimail_server_wide_lock":"0",
"mailing_backend":{
"outBound_option":"3"
},
"profile_add_to_group_double_optin":"0",
"uploadDir":"upload\/",
"imageUploadDir":"persist\/contribute\/",
"customFileUploadDir":"custom\/",
"extensionsDir":"\/var\/www\/civi.custom\/extensions"
}],

Some are booleans but set as strings. Is this something missing in the xml/definitions or something weird in the ajax api?
eg. "is_enabled": "0" //instead  of :=


Some of the syntax is close to the machine, eg.

"advanced_search_options":["1","2","3","4","5","6","7","8","9","10","11","12","13","15","16","17","18","19"],

Is there a way to know what these indexes represent (or translate them by something easier to use?)
$
X+

Hey there,

That looks cool.  Stupid / obvious question.  Is one of the use cases for this initial installation set up of CiviCRM.  And do you have any ideas on how that might work? / suggestions on how that could be implemented.

Hi Michael,

The idea for installation is that you can use the settings api to set various things. Or you can define the defaults for your country (or whatever) and then 'revert' to them. What would be good to compile is a list of standard changes that you (or someone) makes when configuring a site to see how it maps against it.

Ideally at some point we would make the initial settings load based on the defaults (which are potentially hook-modified) rather than 'hard-sql'. Also I think the domain create action should 'fill' settings (@ the moment it doesn't create any at all).

Xavier,

1) I am fairly  agnostic about the storage format. I think I copied the use of xml based on that being in place for schema.
2) Looking at your output the getfields array doesn't seem to be keyed by the setting name which seems like a bug.
3) CiviCRM is already stored integers as strings in the settings table - that's what you are seeing. Probably should be fixed but not necessarily in the scope of this.
4) language/currency/countries... If these aren't in the list they are probably still stored in the civicrm_domain table. They should be moved. I think most will be fairly simple but ...
5) the handling of allowed states / countries need some thought - the current method is memory intensive. We could save the array as json in the settings table & unserialise it / use only when there is a country box. But there are other problems with the current method - e.g people like to restrict front end country entry - but then they can't even see the country for imported contacts from a non-permitted country. So, would be good to be clear firstly (because I'm not) what we expect from the country / state list restriction & then potentially look at how to store that.

Ok separate thread for the counrty list stuff since I can see it over-taking this thread
http://forum.civicrm.org/index.php/topic,26348.0.html

Thanks, Eileen, this is really moving along nicely now.

Michael: yes, the primary use case I had for sponsoring this was to allow auto-configuration of CiviCRM installations, eg from a drush script, etc. Ideally, this would make it possible to do something along the lines of a Drupal install profile.

Joe / others reading - it would be great if someone could compile a list of the things they usually change so I can focus on those settings. (I found the whole settings definition pretty exhausting so I went for a get-em-in-quick & tidy up after approach)

This isn't really an answer, but I can think of three distinct use-cases for "configuration bundles", and each would seem to gravitate towards different settings:
 * Localization (address format, currency, language, etc -- shared by sites in the same locale)
 * Service configuration (email routing, SMS, payment processing, etc -- shared by sites with the same hosting provider)
 * Usability improvements (enabling/disabling components, blocks, navigation items, default permissions, etc -- shared by sites in similar niches)

OK, I moved a whopping 1 setting from config to civicrm_settings & made the observation that it will be necessary for svn devs / upgrade scripts to

1) clear the civicrm_cache table &
2) run civicrm_api('setting','fill', array('version' => 3);

to not lose functionality.

(since I don't want to go around putting the default into the getitem calls).

I guess these 2 should be done by all upgrade scripts + the setup script for svn users