Email Hacker V3.4.6 Activation Code 46
Gabriella Waser
Legacy REST performed authentication with HTTP parameters (?key=...&api_key=...). This looked like a "stateless HTTP" style, butit often left behind extraneous records in session-storage. AuthX supports both stateless styles (eg HTTP parameters and HTTPheaders) and stateful styles (eg HTTP login/session). Stateless styles do not leave behind extraneous records in session-storage.
On the CiviCRM server, verify the settings. Navigate to "Administer => System Settings => Authentication". "HTTP Parameter" should accept credentials of type "API Key". (This should be enabled by default.)
The API has now been changed such that when setting the value of a custom field using the API if you pass the string 'NULL' then it will set the field value to be the String NULL not the database NULL. If you want the value to be truely NULL then you need to either not pass in the value or use 'null' instead
From 5.8 it is now possible for Extension authors to store examples for their API entities in a folder /api/v3/examples// in the same structure as is in core. They will now be displayed in the API Explorer just like the core examples.
A field defined with the key 'serialize' (in the metadata) will be serialized on save/create with no additional handling if using basic create methods. Generally this is used by adding JSON to the xml when generating the DAO. Example declaration
The EntityTag api had nonstandard output which indexed results by the tag_id column instead of the id column. This was cleaned up as part of permission fixes in 4.7.13. Any custom code relying on this quirk will need to be updated.
A generic validate action which can be used to return an array of errors in an API call. The error values returned are key => value pairs with the key being the name of the field and value array containing a description message and error code. For example:
With previous versions of the API, you could not search on custom fields of entities, except for contacts. This issue has been resolved: now you can search the custom fields of any entity type. See CRM-16036 and CRM-16036 Changes. This fix involved a considerable change in the inner workings of the API, so it may cause some unexpected results. If you bump into an issue, please report it.
In previous versions of the API, multi-select custom fields were returned either as numerical indexed arrays, either as key-value arrays, depending on the entity type the custom field set applied to. From CiviCRM 4.6.7 on, all multi-select custom fields are returned as numerical indexed arrays. See CRM-15915 and CRM-15915 Changes. (This is still work in progress)
The 'setvalue' generic api action was used to change one field of a given entity. It was problematic in that it bypassed hooks and business logic related to updating that entity, and is now deprecated. Use the 'create' action instead to update all entities by passing their id plus fields to be modified.
To detect other references, one must implement hook_civicrm_referenceCounts or CRM_Core_Component_Info::getReferenceCounts(). For example, CRM_Case_Info implements getReferenceCounts() to count references from CiviCase XML to activity-types.
API action "getlist" is a wrapper for API action "get." It is used mainly for quicksearch and autocomplete widgets. A call to, for example: CRM.api3('contact', 'getlist', input: 'bob') will internally call contact.get and return a list of resuts formatted for use by the select2 widget or other autocomplete/search forms. It supports formatted description, icons or other images in the results, infinite scrolling or paging of search results, and context-aware searching.
The 'sequential' param will cause results to be returned in a non-associative array, which is especially useful for json. Prior to 4.4, this param was ignored for the 'getoptions' action. This has now been fixed.
When calling the "create" or "replace" action, one may wish to update an existing record. In this past, this required passing the ID. If one passes 'options.match', the API will attempt to update an existing record.
CRM-12140: The API update action was a clunky hack (get+create) to workaround the problems on the create api with an id set (mostly forcing default values). We have now have all (well, at least most of) the entities that behaves on create. We are keeping the action=update working as it was, but no longer mention it in the docs and have removed it from the api explorer as a default action
When calling either the get or getsingle action for the Extension API you will now by default be returned all information on an extension rather than just id status and key - See CRM-19414. However the initial implementation meant that there was no ability to filter Extensions down to just retrieve either information on one extension or a specific set of fields for extensions. This has been fixedin CRM-20532 released in 4.7.20
Deprecated ability to use the 'create' method with multiple contacts / groups in the format contact_id.1, contact_id.2 / group_id.1, group_id.2 etc. This will be removed in a future version. The new approach, using arrays, is documented in the API additions section.
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.
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 method instead of the constant api. See Pseudoconstant (option list) Reference
This means that contact get api now gets only the contacts for which the logged in person is permission if you set the check_permissions flag on the api call (it is always set for REST calls & Smarty). Note that the fields that can be returned from contact api if check_permissions is set are restricted to those shown by 'getfields'
If you create a contribution then a default line item will be automatically created for it according to various rules. If you wish to create the line items yourself you need to add the param 'skipLineItems' => 1
The event api can now clone templates similar to how the UI can do it. Add the param template_id and all properties of that event template (including payment processors, profiles, scheduled reminders, etc) will be added to your new event.
This api can be called to change the format of the log_conn_id fields to a 17 Char varchar - and to switch to using truly unique connection ids. Calling this api can also convert log tables to INNODB - using this hook hook_civicrm_alterLogTables either in your code or with the Extension
It is now possible to add multiple contacts to one or more groups using a standard array. The 'create' method now correctly accepts an array of contact ids in the contact_id param, or an array of groups in the group_id param. This replaces the legacy functionality that was deprecated in this version.
Similar to profile.submit - this takes the values you would pass into the form and uses them for post processing. - including credit card processing, creating memberships etc. This api has mostly been used in the test suite so far so you should investigate carefully before using it. (Profile.submit is more mature)
The CaseType API allows one to create, modify, and delete case types. This includes support for setting the detailed activity/relationship configuration with the "definition" property. For examples, see api_v3_CaseTypeTest.
Using these api along with get you can build your own profile form prefilled with a contact id and use the params from it to submit as if you were using the built in profile. The prefilling on cid=0 pages use the profile.get with contact_id
This api takes a pending contribution and completes it, updating related entities like memberships and sending out emails as required. Some IPN call this function in their handlePaymentNotification function (as soon as they have ascertained a successful payment)
Settings can be set / retrieved / reverted to defaults for single or mulitple domains using the setting api. There is also the ability to define default settings e.g country - specific ones by hook (Try the civiconfigure extension for more on that)
Although location blocks are no longer used by CiviCRM contacts, they are currently still used for events. So the main purpose of this api is to allow you to CRUD the address, emails and phones associated with an event.
Classes which implement this interface must implement a new method called buildTaskList. This method is responsible for building the list of actions (e.g., Add to Group) that may be performed on set of search results. It differsfrom hook_civicrm_searchTasks in that the hook allows a developer to specify tasks by entity (e.g., Contact, Event, etc.) whereas buildTaskList provides the ability to target a specific form. The new method takes a CRM_Core_Form_Search object as an argument and should return an array. Dump CRM_Core_Form_Search()->_taskList to learn about the format of the array. The array returned by buildTaskList will completely replace the task list.
Aside from the community-maintained custom searches in CRM/Contact/Form/Search/Custom/, this change does not affect CiviCRM core. Custom searches which extend CRM_Contact_Form_Search_Custom_Base (as do those built on civix) will not be affected, as the method is implemented there.
In previous versions, the properties in CRM_Core_Config were loaded from a mix of sources, most notably a SQL field (civicrm_domain.config_backend). The config_backend contained a mix of canonical settings and caches. For any given property, it was very difficult to trace the lifecycle (e.g. to identify where the property was canonically stored, how it was filtered, or how it could be changed).
b37509886e