@@ -197,7 +197,7 @@ Because 'sequential' gives a more concise format, it has been made the default i
Fetch the options for a specified field e.g. `civicrm_api('contact', 'getoptions' array('field' => 'gender_id'));` returns `array(1 => 'Female', 2 => 'Male', 3 => 'Transgender')`
See [Pseudoconstant (option list) Reference](/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
See [Pseudoconstant (option list) Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
### 4.5.0: Case API: "case_type" corresponds to machine-name
When creating a new Case record, the "create" API previously accepted `case_type` using the displayable title of the case-type (e.g. "Housing Support"). Beginning in v4.5, the `case_type` should specify the internal machine-name of the case-type (e.g. `housing_support`). Submitting the displayable title will still work - but this is deprecated. For more discussion about changes to handling of case-type names, see [Check Case Type Name Consistency](/confluence/display/CRMDOC/checkCaseTypeNameConsistency).
When creating a new Case record, the "create" API previously accepted `case_type` using the displayable title of the case-type (e.g. "Housing Support"). Beginning in v4.5, the `case_type` should specify the internal machine-name of the case-type (e.g. `housing_support`). Submitting the displayable title will still work - but this is deprecated. For more discussion about changes to handling of case-type names, see [Check Case Type Name Consistency](https://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency).
### 4.4.0: Activity API Changes
...
...
@@ -299,7 +299,7 @@ When creating a new Case record, the "create" API previously accepted `case_type
### 4.3.0: Deprecate Constant API
Most `CRM_*_Pseudoconstant methods` (which the 'constant' api is a wrapper for) are deprecated in 4.3 and many are removed in 4.4. To future-proof your code, use the [api.getoptions](/api/changes#getOptions) method instead of the constant api. See [Pseudoconstant (option list) Reference](/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
Most `CRM_*_Pseudoconstant methods` (which the 'constant' api is a wrapper for) are deprecated in 4.3 and many are removed in 4.4. To future-proof your code, use the [api.getoptions](/api/changes#getOptions) method instead of the constant api. See [Pseudoconstant (option list) Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
### 4.3.0: Contact get API now respects ACLS
...
...
@@ -540,7 +540,7 @@ See also: [CRM-16373](https://issues.civicrm.org/jira/browse/CRM-16373)
### 4.7.0: Global $civicrm_setting: Multiple changes
The global variable `$civicrm_setting` is used to [override CiviCRM settings](/confluence/display/CRMDOC/Override+CiviCRM+Settings). It has been changed:
The global variable `$civicrm_setting` is used to [override CiviCRM settings](https://wiki.civicrm.org/confluence/display/CRMDOC/Override+CiviCRM+Settings). It has been changed:
- In previous versions, settings were indexed by group name (e.g. `Search Preferences`). In v4.7+, settings should be indexed by entity name ("domain" or "contact"). For backward compatibility, most group names are treated as an alias for "domain" or "contact".
@@ -598,7 +598,7 @@ See also: [Pull Request](https://github.com/civicrm/civicrm-core/pull/4865)
-`CRM_Core_Transaction` has traditionally used a reference-counting mechanism to combine multiple pieces of business-logic into a single transaction. In 4.6, this remains the default behavior, but one can also use nested transactions (by passing `$nested=TRUE` to the constructor). Any work done in the nested transaction can be rolled back without affecting the overall transaction.
- Prior to 4.6, the idiom for managing transactions was to call `$tx = new CRM_Core_Transaction()` and rely on the destructor to cleanup the transaction (e.g. issue the COMMIT/ROLLBACK). Unfortunately, it can be cumbersome to correctly apply this idiom when handling exceptions generated by non-Civi classes. 4.6 introduces a safer notation: `CRM_Core_Transaction::create()->run(function($tx){});` which automatically rolls back in case of an exception.
For more details, see [Transaction Reference](/confluence/display/CRMDOC/Transaction+Reference).
For more details, see [Transaction Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Transaction+Reference).
### 4.5.3: AJAX, Regions, and Resources
...
...
@@ -619,7 +619,7 @@ CiviCRM 4.2+ allowed developers to inject content on a web page using the [Regio
3. If a CiviCase XML file references an unknown activity-type or relationship-type, then it will be auto-created as a ManagedEntity. Moreover, if the XML changes or disappears, and if there are no records which rely on the activity-type or relationship-type, then it will be auto-removed. ManagedEntities are reconciled (created/preserved/deleted) when editing Casetypes via GUI, during extension install, and during other system flushes.
4. When using CiviCase XML files, the file-name and machine-name (`civicrm_case_type.name`) **should**match. Admins may occasionally see a warning if these are mismatched.
1. See also: [checkCaseTypeNameConsistency](/confluence/display/CRMDOC/checkCaseTypeNameConsistency)
1. See also: [checkCaseTypeNameConsistency](https://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency)
2. The example CiviCase XML files have been renamed:
| Case Type (Title)| Case Type (Name) | Old Filename | New Filename |
