CRM_Export_BAO_ExportProcessor

Get additional non-visible fields for address merge purposes.

Set additional non-visible fields for address merge purposes.

Should contacts with the same address be merged.

Set same address is to be merged.

Get additional fields required to do a postal export.

Set additional fields required for a postal export.

Get additional return properties.

Set additional return properties.

Get return properties by relationship.

Set the component table (if any).

CRM_Export_BAO_ExportProcessor constructor.

Set the value for a relationship type field.

In this case we are building up an array of properties for a related contact.

These may be used for direct exporting or for merge to household depending on the options selected.

Get the value for a relationship type field.

In this case we are building up an array of properties for a related contact.

These may be used for direct exporting or for merge to household depending on the options selected.

Get the id of the related household.

Has the household already been exported.

Return relationship types for household merge.

Set the query mode based on the export mode.

Get the name for the export file.

Get the label for the header row based on the field to output.

Add a row to the specification for how to output data.

Get the metadata for the given field.

Mark a column as only required for calculations.

Do not include the row with headers.

Build the row for output.

If this row has a household whose details we should use get the relationship type key.

Mark the given household as already exported.

Get array of fields to return, over & above those defined in the main contact exportable fields.

These include export mode specific fields & some fields apparently required as 'exportableFields' but not returned by the function of the same name.

Should payment fields be appended to the export.

(This is pretty hacky so hopefully this function won't last long - notice how obviously it should be part of the above function!).

Has specific payment fields been requested (as opposed to via all fields).

If specific fields have been requested then they get added at various points.

Get the name of the id field in the table that connects contributions to the export entity.

Have component payment fields been requested.

Get fields that indicate payment fields have been requested for a component.

Ideally this should be protected but making it temporarily public helps refactoring..

Get headers for payment fields.

Returns an array of contribution fields when the entity supports payment fields and specific fields are not specified. This is a transitional function for refactoring legacy code.

Get the default properties when not specified.

In the UI this appears as 'Primary fields only' but in practice it's most of the kitchen sink and the hallway closet thrown in.

Since CRM-952 custom fields are excluded, but no other form of mercy is shown.

Add the field to relationship return properties & return it.

This function is doing both setting & getting which is yuck but it is an interim refactor.

Add the main return properties to the household merge properties if needed for merging.

If we are using household merge we need to add these to the relationship properties to be retrieved.

Get the default location fields to request.

Get the sql column definition for the given field.

Get the munged field name.

In order to respect the history of this class we need to index kinda illogically.

On the bright side - this stuff is tested within a nano-byte of it's life.

e.g '2-a-b_Home-City'

Get the compiled label for the column.

e.g 'Gender', 'Employee Of-Home-city'

Get the mysql field name key.

This key is locked in by tests but the reasons for the specific conventions - ie. headings are used for keying fields in some cases, are likely accidental rather than deliberate.

This key is used for the output sql array.

Get params for the where criteria.

Is this contact a household that is already set to be exported by virtue of it's household members.

Get the various arrays that we use to structure our output.

The extraction of these has been moved to a separate function for clarity and so that tests can be added - in particular on the $outputHeaders array.

However it still feels a bit like something that I'm too polite to write down and this should be seen as a step on the refactoring path rather than how it should be.

Get default return property for export based on mode

Determine the required return properties from the input parameters.

Build array for merging same addresses.

Merge contacts with the same address.

The function unsets static part of the string, if token is the dynamic part.

Example: 'Hello {contact.first_name}' => converted to => '{contact.first_name}' i.e 'Hello Alan' => converted to => 'Alan'

Preview export output.

Set the template strings to be used when merging two contacts with the same address.

Create the temporary table for output.

Get the values of linked household contact.

Write to the csv from the temp table.

Set up the temp table.