Chapter 4. Search Use automation controller's search tool for search and filter capabilities across many functions. An expandable list of search conditions is available from the Name menu in the search field. 4.1. Rules for searching These searching tips assume that you are not searching hosts. The typical syntax of a search consists of a field, followed by a value. A colon is used to separate the field that you want to search from the value. If the search has no colon (see example 3) it is treated as a simple string search where ?search=foobar is sent. Note Search functionality for Job templates is limited to alphanumeric characters only. The following are examples of syntax used for searching: name:localhost In this example, the user is searching for the string localhost in the name attribute. If that string does not match something from Fields or Related Fields , the entire search is treated as a string. organization.name:Default This example shows a Related Field Search. The period in organization.name separates the model from the field. Depending on how deep or complex the search is, you can have multiple periods in that part of the query. foobar This is a simple string (key term) search that finds all instances of the search term using an icontains search against the name and description fields. If you use a space between terms, for example foo bar , then results that contain both terms are returned. If the terms are wrapped in quotes, for example, "foo bar" , automation controller searches for the string with the terms appearing together. Specific name searches search against the API name. For example, Management job in the user interface is system_job in the API. organization:Default This example shows a Related Field search but without specifying a field to go along with the organization. This is supported by the API and is analogous to a simple string search but carried out against the organization (does an icontains search against both the name and description). 4.1.1. Values for search fields To find values for certain fields, refer to the API endpoint for extensive options and their valid values. For example, if you want to search against /api/v2/jobs > type field, you can find the values by performing an OPTIONS request to /api/v2/jobs and look for entries in the API for "type" . Additionally, you can view the related searches by scrolling to the bottom of each screen. In the example for /api/v2/jobs , the related search shows: "related_search_fields": [ "modified_by__search", "project__search", "project_update__search", "credentials__search", "unified_job_template__search", "created_by__search", "inventory__search", "labels__search", "schedule__search", "webhook_credential__search", "job_template__search", "job_events__search", "dependent_jobs__search", "launch_config__search", "unifiedjob_ptr__search", "notifications__search", "unified_job_node__search", "instance_group__search", "hosts__search", "job_host_summaries__search" The values for Fields come from the keys in a GET request. url , related , and summary_fields are not used. The values for Related Fields also come from the OPTIONS response, but from a different attribute. Related Fields is populated by taking all the values from related_search_fields and stripping off the __search from the end. Any search that does not start with a value from Fields or a value from the Related Fields, is treated as a generic string search. Searching for localhost , for example, results in the UI sending ?search=localhost as a query parameter to the API endpoint. This is a shortcut for an icontains search on the name and description fields. 4.1.2. Searching using values from related fields Searching a Related Field requires you to start the search string with the Related Field. The following example describes how to search using values from the Related Field, organization . The left-hand side of the search string must start with organization , for example, organization:Default . Depending on the related field, you can provide more specific direction for the search by providing secondary and tertiary fields. An example of this is to specify that you want to search for all job templates that use a project matching a certain name. The syntax on this would look like: job_template.project.name:"A Project" . Note This query executes against the unified_job_templates endpoint which is why it starts with job_template . If you were searching against the job_templates endpoint, then you would not need the job_template portion of the query. 4.1.3. Other search considerations Be aware of the following issues when searching in automation controller: There is currently no supported syntax for OR queries. All search terms are AND ed in the query parameters. The left part of a search parameter can be wrapped in quotes to support searching for strings with spaces. For more information, see Rules for searching . Currently, the values in the Fields are direct attributes expected to be returned in a GET request. Whenever you search against one of the values, automation controller carries out an __icontains search. So, for example, name:localhost sends back ?name__icontains=localhost . Automation controller currently performs this search for every Field value, even id . 4.2. Sort Where applicable, use the arrows in each column to sort by ascending order. The following is an example from the schedules list: The direction of the arrow indicates the sort order of the column.

Commands:
"related_search_fields": [ "modified_by__search", "project__search", "project_update__search", "credentials__search", "unified_job_template__search", "created_by__search", "inventory__search", "labels__search", "schedule__search", "webhook_credential__search", "job_template__search", "job_events__search", "dependent_jobs__search", "launch_config__search", "unifiedjob_ptr__search", "notifications__search", "unified_job_node__search", "instance_group__search", "hosts__search", "job_host_summaries__search"