Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • documentation/docs/dev
  • totten/dev
  • bgm/dev
  • ivan_compucorp/dev
  • seamuslee/dev
  • artfulrobot/dev
  • ufundo/dev
  • wmortada/dev
  • lucky091588/dev
  • DaveD/dev
  • jtwyman/dev
  • rukkykofi/dev
  • JonGold/dev
  • jaapjansma/developer-docs
  • alainb/dev
  • noah/dev
  • justinfreeman/dev
  • pradeep/dev
  • larssg/dev
  • eileen/dev
  • darrick/dev
  • mattwire/dev
  • colemanw/dev
  • homotechsual/dev
  • JoeMurray/dev
  • maynardsmith/dev
  • kurund/dev
  • rocxa/dev
  • AllenShaw/dev
  • bradleyt/dev
  • chrisgaraffa/dev
  • martin.w/dev
  • herbdool/dev
  • MattTrim1/dev
  • Detlev/dev
  • ErikHommel/dev
  • brienne/devdocs
  • pminf/dev
  • SarahFG/dev
  • ayduns/dev
  • JKingsnorth/dev
  • ginkgomzd/dev
  • nicol/dev
  • almeidam/dev
  • arthurm/dev
  • damilare/dev
  • semseysandor/dev
  • major/devdocs
  • usha.makoa/dev
  • yurg/dev
  • shaneonabike/dev
  • andie/dev
  • mmyriam/dev
  • gngn/dev
  • florian-dieckmann/dev
  • jade/dev
  • luke.stewart/dev
  • vinaygawade/dev
58 results
Show changes
Commits on Source (3345)
Showing
with 1936 additions and 469 deletions
name: Mark stale issues and pull requests
on:
schedule:
- cron: "0 * * * *"
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v3
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
stale-issue-message: 'This issue has had no activity in 60 days and has been marked as stale, it will not be closed.'
stale-pr-message: 'This pull request has had no activity in 60 days and has been marked as stale, it will not be closed.'
stale-issue-label: 'no-issue-activity'
stale-pr-label: 'no-pr-activity'
days-before-stale: 60
days-before-close: -1
exempt-issue-labels: 'awaiting-approval,work-in-progress'
exempt-pr-labels: 'awaiting-approval,work-in-progress'
remove-stale-when-updated: 'True'
site
.idea
*~
This diff is collapsed.
# CiviCRM developer documentation
# CiviCRM Developer Guide
```bash
git clone https://github.com/civicrm/civicrm-dev-docs
cd civicrm-dev-docs
mkdocs serve
```
* **Issues have moved to https://lab.civicrm.org/documentation/docs/dev/-/issues**
* **Submit new merge/pull requests at https://lab.civicrm.org/documentation/docs/dev**
This will likely be merged with the `civicrm-core` repo at some point.
A documentation guide for people who develop with/for [CiviCRM](https://civicrm.org).
# See also
- [Read published version](http://docs.civicrm.org/dev/en/master)
- [Learn how to edit](https://docs.civicrm.org/dev/en/master/documentation/#how-to-edit)
* Download mkdocs: http://mkdocs.org/
* Browse published dev docs: http://docs.civicrm.org/dev/en/master
* Review general info about CiviCRM docs: https://github.com/civicrm/civicrm-docs
# Docs Infrastructure Links
- [Docs Publisher system and issue queue](https://lab.civicrm.org/documentation/docs-publisher)
- [Docs Book definitions for the Docs Publisher](https://lab.civicrm.org/documentation/docs-books)
- [Docs Working Group meta issue queue](https://lab.civicrm.org/documentation/meta)
......@@ -5,6 +5,9 @@
* Where should we store deprecated documentation? Should we include it at all?
* Should we rename `develop.md` (`core/develop.md` vs `extension/develop.md`?)
## Style Guide
* Add guide for using footnotes
## Tasks
* Finish importing [GitHub for CiviCRM](https://wiki.civicrm.org/confluence/display/CRMDOC43/GitHub+for+CiviCRM) to `develop.md` and `develop-deprecated.md`.
......
#!/usr/bin/env python
import yaml
import re
from os.path import dirname, abspath, join
PROJECT_ROOT = dirname(dirname(abspath(__file__)))
DOCS_ROOT = join(PROJECT_ROOT, 'docs/')
MKDOCS_YAML_FILE = join(PROJECT_ROOT, 'mkdocs.yml')
OUTPUT_FILE = join(DOCS_ROOT, 'hooks/', 'list.md')
HEADER = """# All hooks
<!--
-- DO NOT EDIT
--
-- This entire page is auto-generated by the following command:
-- ./bin/hook-summary.py
--
-->
This is an overview list of all available hooks and the event listeners that
are supported for use outside of core. Any event listeners not listed here
are not supported for use outside of core & could change without notice
"""
def findBetween( s, first, last ):
start = s.index( first ) + len( first )
end = s.index( last, start )
return s[start:end]
def getSummary(hookFile):
content = open(join(DOCS_ROOT + hookFile), 'r').read()
summary = findBetween(content, '## Summary', '##')
summary = re.sub('This hook (is)?(was)?', '', summary)
summary = re.sub('\s+', ' ', summary).strip()
if not (summary.endswith('.')):
summary = summary + '.'
return summary
output = f = open(OUTPUT_FILE, 'w')
with open(MKDOCS_YAML_FILE, 'r') as f:
doc = yaml.load(f, Loader=yaml.FullLoader)
pages = doc["nav"]
for section in pages:
if "Hooks" in section:
hookSection = section.get("Hooks")
output.write(HEADER)
for section in hookSection:
categoryHooks = list()
category, hookList = section.popitem()
if isinstance(hookList, list):
for hookDetails in hookList:
hookName = list(hookDetails)[0]
if re.match("^(<del>)?hook_civicrm_*", hookName) or re.match("^civi", hookName):
categoryHooks.append(hookDetails)
if len(categoryHooks) > 0:
output.write('\n## {}\n\n'.format(category))
for hookDetails in categoryHooks:
hookName, hookFile = hookDetails.popitem()
summary = getSummary(hookFile)
hookNameForLink = hookFile.replace('hooks/', '')
output.write('* **[{}]({})** - {}\n'.format(hookName, hookNameForLink, summary))
## FormBuilder Behaviors
### Overview
Simply put, a **Behavior** extends the functionality of an **entity**.
Behaviors are PHP classes written by a developer, which can be enabled in the GUI to affect how entities behave on a form.
Each Behavior class declares some configuration metadata which automatically appears in the Afform GUI. The user can
make selections to enable and configure the behavior.
To enact its functionality, a behavior class can listen to any Civi hook or event, notably `civi.afform.prefill` and `civi.afform.submit`.
These events are called for every entity on a form, and will include information such as the entity name, type, and any
behaviors that have been configured for that entity.
### Examples
A good example to emulate is the [Contact Dedupe Behavior](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/core/Civi/Afform/Behavior/ContactDedupe.php).
```php
class ContactDedupe extends AbstractBehavior implements EventSubscriberInterface {
```
It starts off by extending the `AbstractBehavior` class, which makes it discoverable to Afform,
and also implementing `EventSubscriberInterface`, which is the recommended way to subscribe to events. That interface
requires a `getSubscribedEvents` function:
```php
/**
* @return array
*/
public static function getSubscribedEvents() {
return [
'civi.afform.submit' => ['onAfformSubmit', 101],
];
}
```
That registers the callback function named `onAfformSubmit` in the same class, to be called every time an Afform entity
is about to be saved.
The next 4 functions are part of the `AfformBehavior` interface, and provide enough information for the AfformAdmin GUI
to show the behavior to the user for configuration:
```php
public static function getEntities():array {
return \CRM_Contact_BAO_ContactType::basicTypes();
}
public static function getTitle():string {
return E::ts('Duplicate Matching');
}
public static function getDescription():string {
return E::ts('Update existing contact instead of creating a new one based on a dedupe rule.');
}
public static function getModes(string $entityName):array {
...
}
```
Note that `getEntities` does not simply return "Contact" because Afform considers "Individual", "Household" and "Organization"
to all be their own entities.
The `getModes` function returns an array of operation modes (in this case dedupe rules) for a particular entity type.
So if your Behavior can act on more than one entity type as this one can, pay attention to the `$entityName` parameter
and only return modes relevant to that type of entity (in this case, there are different dedupe rules for "Individual" vs
"Organization", etc).
Finally, the callback registered with `getSubscribedEvents`:
```php
public static function onAfformSubmit(AfformSubmitEvent $event) {
$entity = $event->getEntity();
$dedupeMode = $entity['contact-dedupe'] ?? NULL;
if ($event->getEntityType() !== 'Contact' || !$dedupeMode) {
return;
}
// Apply dedupe rule if contact isn't already identified
foreach ($event->records as $index => $record) {
$supportedJoins = ['Address', 'Email', 'Phone', 'IM'];
$values = $record['fields'] ?? [];
foreach ($supportedJoins as $joinEntity) {
if (!empty($record['joins'][$joinEntity][0])) {
$values += \CRM_Utils_Array::prefixKeys($record['joins'][$joinEntity][0], strtolower($joinEntity) . '_primary.');
}
}
$match = Contact::getDuplicates(FALSE)
->setValues($values)
->setDedupeRule($dedupeMode)
->execute()->first();
if (!empty($match['id'])) {
$event->setEntityId($index, $match['id']);
}
}
}
```
This function checks the `contact-dedupe` mode set by the Admin (this is a kebab-case version of the class name)
and takes action on every record being saved for that entity (normally one entity saves one record, but because of the
AfRepeat feature, entities should always be treated as if they may be multivalued).
# Afform Core
The core of the Afform extension is an AngularJS module factory. Traditionally, to [add a new AngularJS module
in CiviCRM](../framework/angular/quickstart.md), one must create an `.ang.php` file, a js module file, some
controllers, components & templates, plus a page route to bootstrap AngularJS and load the module.
Afform Core does all that for you, all you need is a template `.aff.html` file and an optional configuration `.aff.json` file.
## Creating a Form in an Extension
As an extension author, you can define a form along with its default, canonical content.
Simply create a file `ang/MYFORM.aff.html`. In this example, we create a form named `helloWorld`:
1. Make sure you're in the directory with your extension (`cd /path/to/extension`)
2. Make an `ang` directory in your extension. (`mkdir ang`)
3. Add some HTML/JS code to your `aff.html` file. `echo '<div>Hello {{routeParams.name}}</div>' > ang/helloWorld.aff.html`
4. Add some JSON config to your `aff.json` file. `echo '{"server_route": "civicrm/hello-world"}' > ang/helloWorld.aff.json`
5. Flush the caches so CiviCRM picks up the new form. `cv flush`
A few things to note:
* The `ang` folder is the typical location for AngularJS modules in CiviCRM extensions.
* We defined a route `civicrm/hello-world`. This appears in the same routing system used by CiviCRM forms. It also supports properties such as `title` (page title) and `is_public` (defaults to `false`).
* After creating a new form or file, we should flush the cache.
* If you're going to actively edit/revise the content of the file, then you should navigate to **Administer > System Settings > Debugging** and disable asset caching.
* The extension `*.aff.html` represents an AngularJS HTML document. It has access to all the general features of Angular HTML (discussed more later).
* In AngularJS, there is a distinction between a "module" (unit-of-code to be shared; usually appears as `camelCase`) and a "directive" (a custom HTML element; may appear as `camelCase` or as `kebab-case` depending on context). Afform supports a tactical simplification in which one `*.aff.html` corresponds to one eponymous module and one eponymous directive.
Now that we've created a form, we'll want to determine its URL. As with most CiviCRM forms, the URL depends on the CMS configuration. Here is an example from a local Drupal 7 site:
We can use `cv` to get full URLs for any `civicrm/*` URL like so:
* `cv url "civicrm/hello-world"` returns `http://dmaster.localhost/civicrm/hello-world`
* `cv url "civicrm/hello-world/#/?name=world"` returns `http://dmaster.localhost/civicrm/hello-world/#/?name=world`
Open the URLs and see what you get.
## Form Overrides
Afform files inside an extension (aka a _"Packaged"_ form), are considered the default state, or _"base"_.
If you fetch your form via API (e.g. the APIv4 Explorer), `civicrm_api4('Afform', 'get')` will return something like this:
```
[
{
name: "helloWorld" // this corresponds to file name minus .aff.html extensions
server_route: "civicrm/hello-world" // as defined in helloWorld.aff.json
has_base: true,
has_local: false,
...
},
...
]
```
The calculated field `'has_base'` is **`true`** because the Afform files are packaged in an extension.
`'has_local'` is **`false`** for now. However, site builders can modify your form without touching your extensnion code
simply by making a copy of the form in their local files directory. In that case the form would be considered _overridden_
and Afform would automatically use the local copy in favor of the one on your extension and the same api call would return
data from the new files with `has_local: true`.
## Form Builder Events
### `civi.afform_admin.metadata`
*Alter metadata for the Form Builder GUI*
**Since:** CiviCRM 5.50
**Type:** `GenericHookEvent`
**Params:**
- **`entities`** (array) List of entities that can be used in the Form Builder GUI. Each item has array keys:
- `name` (string)
- `label` (string)
- `icon` (string:"fa-*")
- `type` (string:"primary"|"secondary")
- `defaults` (string:js object).
- **`elements`** (array) Static elements that can be added to a form, keyed by name. Each item has array keys:
- `title` (string) Title shown in Editor
- `afform_type` (array) Form types this element is used for
- `element` (array) Default markup for this element
- `directive` (string) Specify directive name in dash format (should match `['element']['#tag']`)
- `admin_tpl` (string) Editor template. Extensions can provide their own template for editing this element type,
by adding an Angular module with base page `'civicrm/admin/afform'`.
- **`inputTypes`** (array) Form widgets used to represent a field.
- **`styles`** (array) Bootstrap3 style strings.
- **`permissions`** (array) Permissions that can be set for an Afform.
- **`dateRanges`** (array) Date range options.
### `civi.afform.prefill`
*Prefill entity data when the form is being viewed.*
**Since:** CiviCRM 5.56
**Type:** `AfformPrefillEvent`
**Methods:**
- **getAfform()**: `array`
- **getFormDataModel()**: `Civi\Afform\FormDataModel`
- **getApiRequest()**: `Civi\Api4\Action\Afform\Prefill`
- **getEntityType()**: `string`
- **getEntityName()**: `string`
- **getSecureApi4()**: `callable`
- **setEntityId(int $index, int $id)**
- **setJoinIds(int $index, string $joinEntity, array $joinIds)**
### `civi.afform.validate`
*Validate submission of an Afform.*
**Since:** CiviCRM 5.56
**Type:** `AfformValidateEvent`
**Methods:**
- **getAfform()**: `array`
- **getFormDataModel()**: `Civi\Afform\FormDataModel`
- **getApiRequest()**: `Civi\Api4\Action\Afform\Submit`
- **getEntityValues()**: `array`
- **setError(string $errorMsg)**
### `civi.afform.submit`
*Handle submission of an `<af-form>` entity (or set of entities in the case of `<af-repeat>`).*
**Since:** CiviCRM 5.31
**Type:** `AfformSubmitEvent`
**Methods:**
- **getAfform()**: `array`
- **getFormDataModel()**: `Civi\Afform\FormDataModel`
- **getApiRequest()**: `Civi\Api4\Action\Afform\Submit`
- **getEntityType()**: `string`
- **getEntityName()**: `string`
- **getRecords()**: `array`
- **getSecureApi4()**: `callable`
- **setEntityId(int $index, int $id)**
- **setRecords(array $records)**
- **setJoinIds(int $index, string $joinEntity, array $joinIds)**
Form Builder provides a flexible form interface allowing editing a variety of CiviCRM entities as well as a developer interface.
## Exposing an entity to Form Builder
### Via event listener
The Form Builder GUI can be extended via the [`civi.afform_admin.metadata`](afform-events.md) event.
This event is used for adding entities, elements, input types, etc.
### Via an Afform entityType declaration file
It is also possible to expose entities in Form Builder by adding a declaration. To do this:
1. Add the [mixin](../framework/mixin/index.md) `<mixin>afform-entity-php@1.0.0</mixin>` to your extension's `info.xml` file (note: for backward compatability with versions < 5.50 you must [add a shim](https://github.com/eileenmcnaughton/deduper/pull/26).
2. Ensure the entity in question has apiv4 CRUD entities (these get generated automatically if using [civix with an extension](https://docs.civicrm.org/dev/en/latest/step-by-step/create-entity/#4-generate-sql-dao-and-bao-files))
3. Create a php file in the following location - `afformEntities/EntityName.php` as you can see [here in the `deduper` extension](https://github.com/eileenmcnaughton/deduper/blob/master/afformEntities/ContactNamePair.php). For more complex examples [see core](https://github.com/civicrm/civicrm-core/tree/master/ext/afform/admin/afformEntities).
```php
<?php
use CRM_MyExtension_ExtensionUtil as E;
return [
'type' => 'primary',
'defaults' => "{}",
'boilerplate' => [
['#tag' => 'af-field', 'name' => 'name'],
['#tag' => 'af-field', 'name' => 'xxx'],
],
];
```
4. The boilerplate specifies the fields that are automatically added to a new Submission Form. In the example above, the fields 'name' and 'xxx' would be added.
5. An entity can be available for "Submission forms" and/or for "Field blocks". In order for the entity to be available for Submission forms, add `'type' => 'primary'` [example](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/afformEntities/Individual.php) or only as Field blocks, leave blank or add `'type' => 'join'` [example](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/afformEntities/Address.php). A Field block (or join) is only available in relation to a primary entity.
[Core afform entities](https://github.com/civicrm/civicrm-core/tree/master/ext/afform/admin/afformEntities) have examples of other parameters that can be added such as `repeat_max`, `unique_fields`, `boilerplate`, `icon`, `alterFields`, and `data` defaults. Be sure to test them out to see what works best with a custom entity.
!!! tip "Making fields available for use in Form Builder"
If an expected element for an Entity is missing from Form Builder, it's likely that `input_type` needs to be added to the field. See [Entities](../../framework/entities) for possible values.
Find the `getFields` function in the corresponding `.entityType.php` file for that Entity and add an appropriate input type.
(for older entities using legacy xml schema files, the corresponding tag would be `<html><type>` and the code generator script would need to be run after updating).
## Introduction
Form-Builder (aka `afform`) is a core extension currently in active development.
It is intended to become the main building tool for CiviCRM forms and layouts going forwards.
## Embedding
Afforms can be embedded on any CiviCRM page as Angular directives; they also can be configured to
automatically appear on the dashboard or contact summary screen. Afforms can be embedded into
other Afforms simply by including the directive for one Afform in the markup of another; Angular
dependencies will be resolved automatically.
### Embedding in Smarty Templates
*Adding Afforms to traditional Smarty-based pages or forms can be a transitional step away from legacy screens*
**PHP Code**
```php
Civi::service('angularjs.loader')
->addModules('afformMyForm');
$this->assign('myAfformVars', $optionalVars);
```
Note - to figure out what to put in 'name' look at the name in the FormBuilder listing for your form. In the above example the 'name' would be the entire 'afformMyForm' (there isn't a magic prefix).
**Template Code**
```
<crm-angular-js modules="afformMyForm">
<form id="bootstrap-theme">
<afform-my-form options='{$myAfformVars|@json_encode}'></afform-my-form>
</form>
</crm-angular-js>
```
## Afform Types
- **form**: A form which submits through the `Afform::submit` api, editable in the form-builder GUI.
- **block**: A snippet meant to be incorporated into a larger form.
- **system** (default): Non-editable forms.
- **search**: An afform with an embedded [SearchKit Display](../searchkit/displays.md) and optional search filter fields.
## Afform markup
Althought angularjs offers extensive functionality it is recommended that, where possible, CiviCRM Angular forms are written using just html and CiviCRM afform markup. The reason being that there is demand to be able to render these forms using different front end libraries (eg. React) and funding is being sought to that end. If this does proceed then the first piece of work is likely to be rendering existing FormBuilder forms via React - something that would work seamlessly if no native
angularjs markup is used.
The CiviCRM Afform markup includes
| Type | Example |Notes |
| ------ | ------ | ------ |
| form embedding markup | `<contact-basic></contact-basic>` |Embed a FormBuilder form as defined in `contactBasic.aff.html` & `contactBasic.aff.js`|
| api 3 access markup | ``` <div af-api3="af-api3="['Contact','getsingle', {id: options.contact_id}]" af-api3-ctrl="contact"> </div> ``` |Call api v3 & assign results to variable `contact`|
| api 4 access markup | ```<div af-api4="['Afform', 'get', {select: ['name','title','is_public','server_route', 'has_local', 'has_base'], orderBy: {name:'ASC'}}]" af-api4-ctrl="listCtrl"></div>``` |Call api v4 & assign results to variable `listCtrl`|
A [SearchKit Display](../searchkit/displays.md) can be embedded in an Afform.
This switches the form fields from "create" to "get" mode so they can work as search filters.
Search Displays embedded in an Afform will use the permissions of the form to determine
whether they may be viewed; if a user has access to the Afform then SearchKit will grant
permission to view the Display as well.
\ No newline at end of file
# Entity Relationship Diagrams
Entity Relationship Diagrams provide a different view into how the entities accessed through the API are related to each other.
Most of the entities in APIv4 and APIv3 are mapped directly to tables in the CiviCRM database. A few are not, notably the Order API and the Payment API.
Collected below are a number of Entity-Relationship Diagrams. The diagrams were generated by [DBeaver](https://dbeaver.io/), with notes added manually. Each foreign key relationship that is defined in the database between two tables is represented by a line connecting the tables. A table can also have a relationship with itself, for example, a parent_id field linking to a different record in the same table.
The lines do not indicate the specific fields joined by the relationship unfortunately. The solid circle at the end of a relationship line touches the table that has a foreign key referencing another table. So the solid dot indicates the 'beginning' of the relationship, and is touching the 'source' table. When the foreign key field in the souce table is defined as NOT NULL, then the other end of the relationship line will go straight into the destination table. However, if foreign key field in the source table is optional, then there is a rectangle on the end touching the destination table.
CiviCRM has a field naming convention that helps in determining which field is a foreign key to a different table. A table named civicrm_tablename1 has a field named id as its unique primary key. References from other tables to that id field are named tablename1_id. (There are a few exceptions, such as when two fields in one table reference the key of a single other table, for different purposes.)
CiviCRM has non-standard patterns that it uses to implement one table references one amongst several other tables. We term this a pseudo foreign key. In most cases there is a pair of fields, entity_table and entity_id, with entity_table containing the name of the table being referenced and entity_id representing the value of id of the record in that field being referenced. A different pattern is present in the civicrm_value_* tables that are dynamically created to store custom fields that extend various entities in CiviCRM. In that case, entity_id present in the table, and the entity_table value is found in the appropriate civicrm_custom_group.extends field.
To aid in viewing and understanding the 200+ tables in CiviCRM, each diagram collects a handful of related tables.
For convenience, here is a clickable list of the Entity-Relationship Diagrams below:
- [ACLs](#acls)
- [Activities](#activities)
- [Batches and Queues](#batches-and-queues)
- [Cases](#cases)
- [Contact Info](#contact-info)
- [Contribution Financial](#contribution-financial)
- [Contribution Page](#contribution-financial)
- [Contributions recur](#contributions-recur)
- [Custom Fields](#custom-fields)
- [Deduping](#deduping)
- [External Providers](#external-providers)
- [Groups, Tags and Campaigns](#groups-tags-and-campaigns)
- [Interfaces](#interfaces)
- [Line Items](#line-items)
- [Mailings](#mailings)
- [Participants](#participants)
- [Pledges](#pledges)
- [Price fields and Premiums](#price-fields-and-premiums)
- [Relationships](#relationships)
- [System](#system)
## ACLs
ACLs are Access Control Lists that define permissions that a user has to view data of different sorts.
![ACLs](../../img/ERDs/ACLs.png)
## Activities
![Activities](../../img/ERDs/Activities.png)
The purpose of an Activity is specific to the activity_type. There can be custom fieldset defined for Activities, including for specific types.
## Batches and Queues
![Batches and Queues](../../img/ERDs/Batches_and_Queues.png)
The queue and queue_item tables are general purpose, and helpful when long-running processes need to have a backlog of tasks. The batch table was originally created to support financial batches, both those created by navigating to Contributions > Batch Data Entry, and ones created manually at Contributions > Accounting Batches > New Batch.
## Cases
![Cases](../../img/ERDs/Cases.png)
These are the primary tables used by CiviCase, though it also makes extensive use of Activities.
## Contact Info
![Contact Info](../../img/ERDs/Contact_Info.png)
This diagram illustrates the various tables containing contact information. These tables are more normalized than some schemas in data sources that contain multiple fields for the same type of content, for example, email1 and email2 or phone1 and phone2.
## Contribution Financial
![Contribution Financial](../../img/ERDs/Contribution_Financial.png)
This diagram includes tables related to accounting information for contributions, memberships and event registrations. Double entry bookkeeping is represented by debit and credit accounts in civicrm_financial_trxn and civicrm_financial_item for most entries, and occasionally for some simple transactions by the from and to account fields in civicrm_financial_trxn. These are the authoritative entries for auditing purposes. The amount fields in civicrm_contribution and civicrm_line_item are often more convenient for some reporting purposes. However, the civicrm_contribution.financial_type_id table is a deprecated field since it cannot accurately represent transactions with multiple line items with different financial types.
## Contribution Page
![Contribution Page](../../img/ERDs/Contribution_Page.png)
This diagram includes tables that store the settings defined when useing Contributions > Manage Contribution Page, and under Contributions > Manage Price Sets.
## Contributions recur
![Contributions recur](../../img/ERDs/Contributions_recur.png)
Recurring contributions, and memberships that are paid with them, are illustrated here.
## Custom Fields
![Custom Fields](../../img/ERDs/Custom_Fields.png)
CiviCRM databases typically have many sets of custom fields defined, and many tables named civicrm_value_*.
## Deduping
![Deduping](../../img/ERDs/Deduping.png)
The dedupe_rule_group has one record per rule in the user interface at Contacts > Find and Merge Duplicate Contacts. The dedupe_rule table has one row per 'field' entry for a particular rule.
## External Providers
![External Providers](../../img/ERDs/External_Providers.png)
These tables are used to store information used to connect to some standard external services.
## Groups, Tags and Campaigns
![Groups, Tags and Campaigns](../../img/ERDs/Groups__Tags_and_Campaigns.png)
Groups, Tags and Campaigns help to segment and relate entities in CiviCRM.
## Interfaces
![Interfaces](../../img/ERDs/Interfaces.png)
These tables define some menu and navigation elements in CiviCRM and permissions for users to see them.
## Line Items
![Line Items](../../img/ERDs/Line_Items.png)
There may be one or more line items related to a contribution, and each may relate to a membership, event registration or a different purpose.
## Mailings
![Mailings](../../img/ERDs/Mailings.png)
CiviMail is a powerful bulk emailing solution. Some of the tables in this diagram relate to the content of the emails, others are used during sending, and the remainder contain information on recipients interactions with those emails.
## Participants and Events
![Participants](../../img/ERDs/Participants.png)
Participants register in events. The registrations are stored in the same tables regardless of whether the event is paid or free.
## Pledges
![Pledges](../../img/ERDs/Pledges.png)
Pledges are prototypically used during capital campaigns to store promises to donate a certain amount over a period of time through payments to be specified later. When payments are made against the pledge, it reduces the amount owing.
## Price fields and Premiums
![Price fields](../../img/ERDs/Price_fields.png)
Price fields are part of the configuration of what people can buy or donate to through a CiviCRM site. Price_field_values are the options for certain types of price_fields; other price field types like a text entry field for an amount do not require price_field_values.
Premiums are used by fundraisers to incentivize people to donate more, with products representing things like mugs or Tshirts that are given away for donating over a certain level.
## Relationships
![Relationships](../../img/ERDs/Relationships.png)
Relationships can be created between contacts. Relationship types can be used to limit which contacts can be involved in a relationship (eg only organizations can be employers and only individuals can be employees). Relationships can be used to define permissions, for example, parents can be allowed to see and edit their children's information.
## System
![System](../../img/ERDs/System.png)
This diagram includes some of the more important system tables.
It is now possible to do two api calls at once with the first call feeding into the second. E.g. to create a contact with a contribution you can nest the contribution create into the contact create. Once the contact has been created it will action the contribution create using the id from the contact create as 'contact\_id'. Likewise you can ask for all activities or all contributions to be returned when you do a get. Some examples will explain
* [https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/ContactCreate.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/ContactCreate.php)
* [https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/ContactGet.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/ContactGet.php)
* [https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArray.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArray.php)
* [https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayFormats.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayFormats.php)
* [https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayValuesFromSiblingFunction.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayValuesFromSiblingFunction.php)
Note that there are a few supported syntaxes
```
civicrm('Contact', 'Create',
array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array('url' => 'Ateam.com'));
```
is the same as
````
civicrm('Contact', 'Create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website' => array('url' => 'Ateam.com'));
````
If you have 2 websites to create you can pass them as ids after the '.'
or an array
````
civicrm('Contact', 'Create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array('url' => 'Ateam.com',),
'api.website.create.2' => array('url' => 'warmbeer.com', ));
````
OR
````
civicrm('Contact', 'Create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array(
array('url' => 'Ateam.com', ),
array('url' => 'warmbeer.com', )));
````
the format you use on the way in will dictate the format on the way out.
Currently this supports any entity & it will convert to 'entity\_id' - ie. a PledgePayment inside a contribution will receive the contribution\_id from the outer call
CiviCRM has a stable comprehensive **API** (Application Programming
Interface) that can be used to access and manage data in CiviCRM. The
API is the recommended way for any CiviCRM extension, CMS module, or
external program to interact with CiviCRM. This section of the wiki
gives you an introduction to the basics of the API. This page's children
dive into the depths of the API.
Why use the API?
----------------
If you're not familiar with APIs, you might ask why you would use the
API when you could access the core functions (e.g. the BAO files) or the
data in the MySQL database directly?
The answer is that the community will ensure that the API will function
as expected with every new release. Great effort is made to preserve
backwards compatibility of the API for several versions of CiviCRM. If
you decide to use other ways to collect data (like your own MySQL
statements), you are left to your own devices. Changes in the schema and
BAO arguments, etc. will cause you grief.
A few comments before we start
------------------------------
The API is something that we as a community develop and maintain
together. A pretty awesome achievement so a big round of applause for
everyone who contributes! It also means that:
- the API is continuously developed and improved. Once you have
mastered the basics from this introduction it is a good idea to
delve deeper into the wiki and the forums for the latest and
greatest
- there is always a chance you run into a bug, if you do please report
it on the forum or go to the CiviCRM IRC channel if it is a real
urgency. Obviously it will be greatly appreciated if you fix it,
send it as a patch with a unit test
- This introduction is updated by the community too. If you do happen
to find some mistake, please log in and change
Exploring the API and documentation
-----------------------------------
The best place to learn about the API is your own ***test*** install of
CiviCRM, using the API explorer and the API parameter list.
Each install comes with two tools that will help you to explore the
wonders of the API and learn a little more about each one:
1. The**API parameter list**, which shows all available entities which
can be manipulated by the API and is available
at http://[CIVICRM\_URL]/civicrm/api/doc (or
http://[CIVICRM\_URL]/?q=civicrm/api/doc if you do not use clean
URLs in Drupal). You will first get a list of all the API entities.
If you click on an entity you will get a list of parameters that are
available for that specific entity, with the type of the parameter.
This can be very useful if you want to check what you can retrieve
with the API and what parameters you can use to refine your get
action or complete your create or update action.
2. The **API explorer**, which is available
at http://[CIVICRM\_URL]/civicrm/api/explorer (or
http://[CIVICRM\_URL]/?q=civicrm/api/explorer if you do not use
clean URLs in Drupal). This gives you the possibility to actually
try out the API in action. You can select the entity you want to
use, for example ' Contact' and the action you want to perform, for
example ' Get' . Again, be careful as the API explorer will actually
perform your actions! So if you delete a contact to check what API
call to use, it will really delete the contact. The API explorer
will show you the code you need to have to execute the API call you
have been testing. To see an example of the API explorer in action
check
[http://civicrm.org/API\_version\_3](http://civicrm.org/API_version_3).
It may be that it uses an older version of the API explorer, but you
will get the idea!
Public API
Explorer: [http://drupal.sandbox.civicrm.org/civicrm/api/explorer](http://drupal.sandbox.civicrm.org/civicrm/api/explorer) (login
as demo/demo)
On top of these tools, your CiviCRM installation will also contain a
directory full of examples on how the API can be used. These examples
will be inside the api/v3 directory and is called 'examples'. You can
also find the examples on GitHub:
[https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples)
There is also the code-level documentation which can be found at
[http://api.civicrm.org/v3/](http://api.civicrm.org/v3/)
Also, the [API Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/API+Reference) page
on this wiki.
Changelog
---------
Any API change you should be aware of will be recorded on this wiki
documentation at [API changes](https://wiki.civicrm.org/confluence/display/CRMDOC/API+changes)
Examples
========
<h3>Online Examples</h3>
All the API examples included with CiviCRM core are auto-generated so
the validity of the code is certain.
|Version|URL|
|:-----------|-------------|
|Upcoming Version|[https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples)|
|CiviCRM 4.5|[https://github.com/civicrm/civicrm-core/tree/4.5/api/v3/examples](https://github.com/civicrm/civicrm-core/tree/4.5/api/v3/examples)|
|CiviCRM 4.2 LTS|[https://github.com/CiviCRM42/civicrm42-core/tree/4.2/api/v3/examples](https://github.com/CiviCRM42/civicrm42-core/tree/4.2/api/v3/examples)|
<h3>Local Examples</h3>
CiviCRM ships with API examples included in the distribution. You can
find the examples specific to your installed version at:
<civicrm\_root\>/api/v3/examples
For example, if you have CiviCRM installed with Drupal the location to
the examples would be:
[/path/to/your/drupalroot/sites/all/modules/civicrm/api/v3/examples](http://path/to/your/drupalroot/sites/all/modules/civicrm/api/v3/examples)
# The CiviCRM API
CiviCRM has a stable, comprehensive **API** (Application Programming Interface) for accessing and managing data.
The API is the recommended way for any extension or external program to interact with CiviCRM.
CiviCRM also uses its own API to power all new UIs and bundled extensions.
Extensions can provide additional API entities or functionality. For help creating your own additions to the API, see [API Architecture](v4/architecture.md).
!!! tip "Why Use the API"
The API is superior to executing raw SQL or calling internal CiviCRM functions, because it offers consistency and stability.
It is designed to function predictably with every new release so as to preserve backwards compatibility when changes to the schema and BAO functions inevitably occur.
Using the API also ensures all hooks and events are dispatched, allowing CiviCRM business logic and 3rd party integrations to function properly.
The best place to begin working with the API is your own *test* install of CiviCRM, using the API Explorer.
## API Explorer
This is the go-to tool for both new and experienced developers. It gives detailed, interactive documentation on each entity, including the
available actions and their parameters, and will write API code for you. To access it:
1. Log in to a CiviCRM site as an administrator.
* This can even be the [demo site](http://dmaster.demo.civicrm.org/).
2. Within the CivCRM menu, go to **Support > Developer** and either **API Explorer v4** (URL `/civicrm/api4`) or the legacy **API Explorer v3** (URL `/civicrm/api3`).
!!! warning
The API Explorer executes real API calls. It can modify data! So if you execute a `Contact` `delete` call, it will really delete the contact.
As such, any experimenting is best done within a test site.
To get started, select an entity, for example `Contact` and an action to perform, for example `Get`.
Use the GUI to select additional parameters to configure your API call; as you do, the API Explorer will generate code
which you can copy & paste into your PHP, Javascript, REST or CLI application.
## API Versions
CiviCRM's API has major versions which are independent of the CiviCRM version. The API version increments more slowly in order to maintain stability within the extension ecosystem.
Typically, two versions of the API are maintained concurrently to allow gradual transitions. New releases of CiviCRM may add features to the API but will not break backward-compatibility within an API version.
- [**APIv4**](v4/usage.md) is the current stable version, with new features being actively developed.
- [**APIv3**](v3/usage.md) is minimally maintained with no new features and regression bug-fixes only.
Your code can use a combination of v3 and v4 API calls, but v4 is recommended for all new projects.
Although there are no plans at the time of this writing to remove APIv3, [upgrading existing code](v4/differences-with-v3.md) to use APIv4 is a good way to future-proof extensions.
## Changelog
All important changes made to the API are recorded in [APIv3 changes](v3/changes.md) and [APIv4 changes](v4/changes.md).
## Entity Relationship Diagrams
To make better use of the API, it can be helpful to have a visual understanding of the relationship between entities available in the API. [Entity Relationship Diagrams](ERDs/index.md) illustrating many of these are available as supplementary documentation to the API Explorer.
\ No newline at end of file
There are many parameters accepted by the CiviCRM API. Most parameters
depend on the entity – for current details in your version, see the
"Documentation" section; in particular, see the "API Explorer" and the
API examples. However, some parameters are particularly dynamic or
generic; these may not be explained well by the auto-generated
documentation. The format for passing options as parameters using the
REST interface is explained at [REST
interface\#optionsparameters](https://wiki.civicrm.org/confluence/display/CRMDOC/REST+interface#RESTinterface-optionsparameters).
**sequential**
--------------
* **Action**: get
* **Type**: bool
* **Default**: FALSE
* **Compatibility**: ??
* **Description**:
Determine whether the returned records are indexed sequentially (0, 1, 2, ...) or by ID.
Without sequential
````
$result= civicrm_api('UFMatch','Get', array('version' =>3, 'uf_id' => $user->uid);
$contactid=$contact['values'][$result['id']]['contact_id'] );
````
With sequential
````
$result= civicrm_api('UFMatch','Get', array('version' =>3, 'uf_id' => $user->uid, 'sequential' => 1);
$contactid=$result['values'][0]['contact_id'] );
````
Note that a single record is returned in this example - whenever a single record is returned the entity_id of that record should be in $result['id']
<h3>Example: sequential</h3>
````
civicrm_api('UFMatch','Get', array(
'version' => 3,
'uf_id' => $user->uid,
'sequential' => 1,
));
````
**options.limit**
-----------------
* **Action**: get
* **Type**: int
* **Default**: 25
* **Compatibility**: ??
* **Description**:
The maximum number of records to return
<h3>Example: options.limit</h3>
````
civicrm_api('UFMatch','Get', array(
'version' => 3,
'uf_id' => $user->uid,
'options' => array(
'limit' => 25,
),
));
````
**options.offset**
------------------
* **Action**: get
* **Type**: int
* **Default**: 0
* **Description**:
The numerical offset of the first result record
<h3>Example: options.offset</h3>
````
civicrm_api('UFMatch','Get', array(
'version' => 3,
'uf_id' => $user->uid,
'options' => array(
'limit' => 25,
'offset' => 50,
),
));
````
**options.sort**
----------------
* **Action**: get
* **Type**: ??
* **Default**: ??
* **Parameters**: field name, order (ASC / DESC)
* **Description**:
The criterion to sort on
<h3>Example: options.sort</h3>
````
civicrm_api3('Contact', 'get', array(
'sequential' => 1,
'return' => "contact_type",
'options' => array('sort' => "contact_type ASC"),
));
````
**options.reload**
------------------
* **Action**: create
* **Type**: bool
* **Default**: FALSE
* **Compatibility**: v4.4+
* **Description**:
Whether to reload and return the final record after the saving process
completes.
<h3>Example: options.reload</h3>
```
civicrm_api('Contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'first_name' => 'First',
'last_name' => 'Last',
'nick_name' => 'Firstie',
'options' => array(
'reload' => 1,
),
));
```
**options.match**
-----------------
* **Action**: create | replace
* **Type**: string | array
* **Default**: NULL
* **Compatibility**: v4.4+
* **Description**:
Attempt to update an existing record by matching against the specified
field.
<br />
If **one** matching record already exists, then the record will be
**updated**.
<br />
If **no** matching record exists, then a new one will be **inserted**.
<br />
If **multiple** matching records exist, then return an **error**.
<h3>Example: options.match</h3>
```
civicrm_api('contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'first_name' => 'Jeffrey',
'last_name' => 'Lebowski',
'nick_name' => 'The Dude',
'external_identifier' => '1234',
'options' => array(
'match' => 'external_identifier',
),
));
```
**options.match-mandatory**
---------------------------
* **Action**: create | replace
* **Type**: string | array
* **Default**: NULL
* **Compatibility**: v4.4+
* **Description**:
Attempt to update an existing record by matching against the specified
field.
<br />
If **one** matching record already exists, then the record will be
updated.
<br />
If **no** matching record exists, then return an **error**.
<br />
If **multiple** matching records exist, then return an **error**.
<h3>Example: options.match-mandatory</h3>
```
civicrm_api('contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'first_name' => 'Jeffrey',
'last_name' => 'Lebowski',
'nick_name' => 'The Dude',
'external_identifier' => '1234',
'options' => array(
'match-mandatory' => 'external_identifier',
),
));
```
**Custom Data**
---------------
Custom data attached to entities is referenced by custom\_N where N is
the unique numerical ID for the custom data field.
To set a custom field, or find entities with custom fields of a
particular value, you typically use a parameter like this:
```
$param['custom_N'] => 'value';
```
To return custom data for an entity, you typically pass a param like the
following:
```
$param['return.custom_N'] => 1;
```
*or (depending on which API entity you are querying)*
```
$param['return'] => 'custom_N';
```
*or*
```
$param['return'] => 'custom_N,custom_O,custom_P';
```
For setting custom date fields, (ie CustomValue create), date format is YmdHis, for example: 20050425000000.
This is just a brief introduction; each API may have different requirements and allow different formats for accessing the custom data. See the [API function documentation](https://wiki.civicrm.org/confluence/display/CRMDOC/Using+the+API) and also read the comments and documentation in each API php file (under civicrm/CRM/api/v3 in your CiviCRM installation) for exact details, which vary for each API entity and function.
For more details and examples, [see the tutorial on using custom data with the API here](https://wiki.civicrm.org/confluence/display/CRMDOC/Using+Custom+Data+with+the+API).
# APIv3 Actions
!!! warning "APIv3 Deprecation"
API version 3 is now deprecated. [Version 4](../v4/actions.md) is recommended.
Most entities support the following actions:
create
------
## create
Insert or update one record. (Note: If an *"id*" is specified, then an
Insert or update one record. (Note: If an `id` is specified, then an
existing record will be modified.)
delete
------
## delete
Delete one record. (Note: Requires an explicit "*id*". Note: if you
Delete one record. (Note: Requires an explicit `id`. Note: if you
want to skip the 'recycle bin' for entities that support undelete (e.g.
contacts) you should set \$param['skip\_undelete'] =\> 1);
contacts) you should set `$param['skip_undelete'] => 1);`
get
---
## get
Search for records
getsingle
---------
## getsingle
Search for records and return the first or only match. (Note: This
returns the record in a simplified format which is easy to use)
getvalue
--------
Does a **getsingle** & returns a single value - you need to also set
````
$param['return'] => 'fieldname'
````
## getvalue
Does a `getsingle` and returns a single value - you need to also set
`$param['return'] => 'fieldname'`.
getcount
--------
## getcount
Search for records and return the quantity. (Note: In many cases in
early versions queries are limited to 25 so this may not always be
accurate)
getrefcount
-----------
## getrefcount
Counts the number of references to a record
getfields
---------
## getfields
Fetch entity metadata, i.e. the list of fields supported by the entity
getlist
-------
## getlist
Used for autocomplete lookups by the
[entityRef](https://wiki.civicrm.org/confluence/display/CRMDOC/EntityRef+Fields) widget
[entityRef](./../../framework/quickform/entityref.md) widget
getoptions
----------
## getoptions
Returns the options for a specified field e.g.
````
```php
civicrm_api3(
'contact',
'getoptions',
'Contact',
'getoptions',
array('field' => 'gender_id')
);
````
);
```
returns
````
```php
array(
1 => 'Female',
2 => 'Male',
3 => 'Transgender'
1 => 'Female',
2 => 'Male',
3 => 'Other'
)
````
```
replace
-------
## replace
Replace an old set of records with a new or modified set of records.
(For example, replace the set of "Phone" numbers with a different set of
"Phone" numbers.).
Warning - REPLACE includes an implicit delete - use with care & test well before using in productions
<del>setvalue</del>
-------------------
"Phone" numbers.).
Warning - REPLACE includes an implicit delete - use with care & test well
before using in productions
## getunique
Returns all unique fields (other than 'id' field) for a given entity.
```php
civicrm_api3('Contribution', 'getunique');
```
return
```php
{
"is_error": 0,
"version": 3,
"count": 2,
"values": {
"UI_contrib_trxn_id": [
"trxn_id"
],
"UI_contrib_invoice_id": [
"invoice_id"
]
}
}
```
## <del>setvalue</del>
**Deprecated.** Use the create action with the param 'id' instead.
<del>update</del>
-----------------
## <del>update</del>
**Deprecated.** Use the create action with the param 'id' instead.
# APIv3 Chaining
!!! warning "APIv3 Deprecation"
API version 3 is now deprecated. [Version 4](../v4/chaining.md) is recommended.
It is possible to do two API calls at once with the first call feeding into the second. E.g. to create a contact with a contribution you can nest the contribution create into the contact create. Once the contact has been created it will action the contribution create using the id from the contact create as `contact_id`. Likewise you can ask for all activities or all contributions to be returned when you do a `get`.
See [api/v3/examples](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples) within the core source code for a plethora of examples (from unit tests) that use chaining. To start, look at these examples:
- [APIChainedArray.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArray.ex.php)
- [APIChainedArrayFormats.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayFormats.ex.php)
- [APIChainedArrayValuesFromSiblingFunction.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayValuesFromSiblingFunction.ex.php)
Note that there are a few supported syntaxes:
```php
civicrm_api('Contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array('url' => 'example.com'),
));
```
is the same as
```php
civicrm_api('Contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website' => array('url' => 'example.com'),
));
```
If you have 2 websites to create you can pass them as ids after the `.`
or an array
```php
civicrm_api('Contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array('url' => 'example.com'),
'api.website.create.2' => array('url' => 'example.org'),
));
```
or
```php
civicrm_api('Contact', 'create', array(
'version' => 3,
'contact_type' => 'Individual',
'display_name' => 'BA Baracus',
'api.website.create' => array(
array('url' => 'example.com'),
array('url' => 'example.org'),
),
));
```
The format you use on the way in will dictate the format on the way out.
Currently this supports any entity and it will convert to `entity_id` - i.e. a PledgePayment inside a contribution will receive the `contribution_id` from the outer call.
This diff is collapsed.