Omnivex Ink – Advanced Search

1.  Introduction

This document introduces the advanced search capabilities of Omnivex Ink. Our goal in creating this feature is to provide you with a powerful tool to search for items such as Files, Apps, Displays, etc. In large installations these items can grow to number in the hundreds and being able to locate specific items is critical. 

2.  Regular Search vs Advanced Search

At the top of each showcase (Apps, Files, Displays, etc.) you will see a standard search box. This is where search queries are entered. 

A regular search query is simply one or more search words typed into the search box. You can either press Enter or wait a moment and the filtered items will be shown. If you type more than one word such as “yellow taxi”, all items with a name that contains both “yellow” and “taxi” will be displayed. The only property of the items that is being considered in a regular search is the Name.

If you want to search on properties other than Name, you will need to use the advanced search. To tell the search box that you want to use an advanced search, you must start the search query with a double right chevron “>>”. You then follow this with a string that identifies the parameters you would like to use for the search. When you have finished entering the search query, press Enter to execute the search.

To exit advanced search, simply click on the X at the right end of the search box to clear the search query and return to the regular search and a full view of all items.

3.  Advanced search parameters

As noted above, the advanced search query starts with a “>>”, followed by a logical statement made of conditions which are made up of properties, operators, constants, and parenthesis. 

For example, the search query >>(name CONTAINS “Ad”) AND (fileSize > 5000000) has two conditions joined with the logical operator AND.

Some comparison operators do not have a comparison value, or they may have an optional comparison value. 

For example, the operator SCHEDULED can omit a comparison value in which case the current date and time are taken as the comparison. Otherwise, if a comparison date/time is provided, that is used. Therefore, both the following searches are valid, but each will return a different set of items.

>>$.metadata.Schedule.value SCHEDULED

>>$.metadata.Schedule.value SCHEDULED “2025-12-01T18:00:00Z”

3.1  Data types

For comparisons there are several data types supported in the query. Every property of an item has a value which is one of these data types. These are the supported data types and their delimiters:

Note: If a number or Boolean value is contained in double quotes, it will be evaluated as a string, which will not give you the results you are looking for.

3.2  Properties

Each item type (Apps, Files, Displays, etc.) has a different set of properties that may be used in a search. There are some common properties such as name and updatedDateTime which are used by all objects. If you are in the Files showcase, you must use the property names applicable to Files.

3.2.1  Apps

3.2.2  Files

3.2.3  Sheets

3.2.4  Folders

3.2.5  Galleries

3.2.6  Displays

3.2.7  Users

3.3  Metadata

In this version of the advanced search, metadata must be accessed using what is called a JSON Path. This is simply a particular string that identifies the metadata field value. This string is case sensitive and must be all lowercase except for the metadata field name (e.g. “City” below) which must follow the case of the metadata field name in Ink. To do a search that involves a metadata field value, implement it as follows:

>>$.metadata.City.value IN [“New York”, “Boston”, “Houston”]

This ability to search based on metadata values is obviously only applicable in those showcases that support metadata, namely Files and Displays. The other object types such as Apps do not support metadata.

The EXISTS operator works with the metadata field, not the metadata value. So be aware that the format is slightly different as shown as the value is not what is being tested for:

>>$metadata.Terminal EXISTS

3.4  Operators

This table contains the operators currently supported by the advanced search query. Many of these are familiar and behave as expected. The operators are shown in uppercase in the table below but will work in either all uppercase or all lowercase. Mixed case will not work. So CONTAINS and contains will both work fine.

3.5  Boolean Operators

As all the comparison operators are either true or false in value, we can apply Boolean logic over these, making the filter clause a Boolean query, complete with the classical AND, OR and NOT operators. Briefly, the AND operator has two arguments, left side and right side, and returns true when both arguments evaluate to true, else it returns false. The OR operator has also two arguments and returns to true when at least one of the arguments is true, if all the arguments are false, it evaluates to false. The NOT operator has only one argument and it inverts the truth value of the argument, it returns true when the arguments is false and false when the argument is true.

3.6  Nesting

With the search query being a full Boolean expression, we can make use of composition using the above operators and parenthesis with any depth required. For example:

>>(name CONTAINS “Welcome”) AND (name CONTAINS “.png” OR name CONTAINS “.jpg”) AND (createdDateTime BETWEEN “2025-01-01” AND “2026-01-01”)