Settings Specification

Description

CiviCRM needs a way of storing either site wide or user specific settings in a generic, extensible way. The current preferences table are very specific and have a column for each variable needed (which makes it non-extensible). We also want to avoid using serialized variables. Currently the focus is mainly on global settings and configuration

Examples

From the current civicrm.settings.php, we have quite a few constants that are used. Some examples include:

For some of the code sprint tasks (restrict assignee contacts in activity, case roles in civicase etc) we also need to add a "parameter string to send to the api" and contact reference MIH that returns the subset of contacts

Features

• Store settings meta data in a separate table
• Functions to create/edit/view/delete settings meta data
• Autogenerate forms to collect data
• Include type information (int, string, option-value) for each setting so we can validate
• Would be great to figure out how to show different civicrm objects (like groups) and then use a
• Hook so we can "alter" the value stored (i.e. group_id=4&....)
• Would be good to expose variables / values via form, so that admins can define some variables specific to their sites

Proposed design

• Rename CRM_Core_BAO_Setting to CRM_Core_BAO_ConfigBackend across code base
• Create two tables: civicrm_settings_type (meta information, better name needed) and civicrm_settings
• Implement features

Design example

For a variable like CIVICRM_ACTIVITY_ASSIGNEE_MAIL, we'll probably rename it to: activity.assignee_mail

• the meta data table will contain the record:
  • name = activity.assignee_mail
  • label = Send activity assignee contacts an email?
  • description = If enabled a mail will be sent to all activity assignees when an activity is created or updated
  • type = boolean
  • default = false
• When the admin sets this value (or during schema load time), a record is created in civicrm_settings
  • name = activity.assignee_mail
  • value = false
  • domain_id = XX
  • component_id = null (since this is civi core)

Upgrade

• During upgrade process we should migrate existing values to db.
• Migrate most/all of current preferences tables to the new format