CRM_Contact_BAO_Query

Class constructor which also does all the work.

Function which actually does all the work for the constructor.

Function for same purpose as convertFormValues.

Like convert form values this function exists to pre-Process parameters from the form.

It is unclear why they are different functions & likely relates to advances search versus search builder.

The direction we are going is having the form convert values to a standardised format & moving away from weird & wonderful where clause switches.

Fix and handle contact deletion nicely.

this code is primarily for search builder use case where different clauses can specify if they want deleted.

CRM-11971

Some composite fields do not appear in the fields array hack to make them part of the query.

Given a list of conditions in params and a list of desired return Properties generate the required select and from clauses. Note that since the where clause introduces new tables, the initial attempt also retrieves all variables used in the params list

If the return Properties are set in a hierarchy, traverse the hierarchy to get the return values.

If the return Properties are set in a hierarchy, traverse the hierarchy to get the return values.

Generate the query based on what type of query we need.

Get where values from the parameters.

Fix date values.

Convert values from form-appropriate to query-object appropriate.

The query object is increasingly supporting the sql-filter syntax which is the most flexible syntax. So, ideally we would convert all fields to look like array( 0 => $fieldName // Set the operator for legacy reasons, but it is ignored 1 => '=' // array in sql filter syntax 2 => array('BETWEEN' => array(1,60), 3 => null 4 => null );

There are some examples of the syntax in https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples/Relationship

More notes at CRM_Core_DAO::createSQLFilter

and a list of supported operators in CRM_Core_DAO

Function to support legacy format for groups and tags.

Fix values from query from/to something no-one cared enough to document.

Get the where clause for a single field.

Given a list of conditions in params generate the required where clause.

Generate where clause for any parameters not already handled.

Given a result dao, extract the values and return that array

Getter for tables array.

Sometimes used to create the from clause, but, not reliably, set this AND set tables.

It's unclear the intent - there is a 'simpleFrom' clause which takes whereTables into account & a fromClause which doesn't.

logic may have eroded?

Generate the where clause (used in match contacts and permissions)

Create the from clause.

WHERE / QILL clause for deleted_contacts

Where / qill clause for contact_type

Where / qill clause for contact_sub_type.

Where / qill clause for groups.

Function translates selection of group type into a list of groups.

Where / qill clause for cms users

All tag search specific.

Where / qill clause for tag.

Where/qill clause for notes

Where / qill clause for sort_name

Where/qill clause for greeting fields.

Where / qill clause for email

Where / qill clause for phone number

Where / qill clause for phone type/location

Where / qill clause for street_address.

Where / qill clause for street_unit.

Where / qill clause for sorting by character.

Where / qill clause for including contact ids.

Where / qill clause for postal code.

Where / qill clause for location type.

Where / qill clause for county (if present).

Where / qill clause for state/province AND country (if present).

Where / qill clause for change log.

Where / qill clause for relationship.

Add start & end date criteria in

Default set of return properties.

Get primary condition for a sql clause.

Wrapper for a simple search query.

These are stub comments as this function needs more explanation - particularly in terms of how it relates to $this->searchQuery and why it replicates rather than calles $this->searchQuery.

This function was originally written as a wrapper for the api query but is called from multiple places in the core code directly so the name is misleading. This function does not use the searchQuery function but it is unclear as to whehter that is historical or there is a reason CRM-11290 led to the permissioning action being extracted from searchQuery & shared with this function

Get the actual custom field name by stripping off the appended string.

The string could be _relative, _from, or _to

Convert submitted values for relative custom fields to query object format.

The query will support the sqlOperator format so convert to that format.

Are we dealing with custom field of type date.

Has this field already been reformatting to Query object syntax.

The form layer passed formValues to this function in preProcess & postProcess. Reason unknown. This seems to come with associated double queries & is possibly damaging performance.

However, here we add a tested function to ensure convertFormValues identifies pre-processed fields & returns them as they are.

If the state and country are passed remove state.

Country is implicit from the state, but including both results in a poor query as there is no combined index on state AND country.

CRM-18125

For some special cases, grouping by subset of select fields becomes mandatory.

Hence, full_group_by mode is handled by appending any_value keyword to select fields not present in groupBy

Include Select columns in groupBy clause.

Create and query the db for an contact search.

Fetch a list of contacts from the prev/next cache for displaying a search results page

Populate $this->_permissionWhereClause with permission related clause and update other query related properties.

Function calls ACL permission class and hooks to filter the query appropriately

Note that these 2 params were in the code when extracted from another function and a second round extraction would be to make them properties of the class

Getter for the qill object.

Default set of return default hier return properties.

Build query for a date field.

Calculate date from age.

Given the field name, operator, value & its data type builds the where Clause for the query used for handling 'IS NULL'/'IS NOT NULL' operators

See CRM-19811 for why this is database hurty without apparent benefit.

Builds the necessary structures for all fields that are similar to option value look-ups.

Check and explode a user defined numeric string into an array this was the protocol used by search builder in the old old days before we had super nice js widgets to do the hard work

Convert the pseudo constants id's to their names

Include pseudo fields LEFT JOIN.

Build qill for field.

Qill refers to the query detail visible on the UI.

Alter value to reflect wildcard settings.

The form will have tried to guess whether this is a good field to wildcard but there is also a site-wide setting that specifies whether it is OK to append the wild card to the beginning or only the end of the string

Process special fields of Search Form in OK (Operator in Key) format

Parse and assimilate the various sort options.

Side-effect: if sorting on a common column from a related table (city, postal_code, email), the related table may be joined automatically.

At time of writing, this code is deeply flawed and should be rewritten. For the moment, it's been extracted to a standalone function.

Convert a string of group IDs to a string of group labels.

The original string may include duplicates and groups the user does not have permission to see.

Set the qill and where properties for a field.

This function is intended as a short-term function to encourage refactoring & re-use - but really we should just have less special-casing.