In pre-Istanbul instances, search screen modules are running client scripts and UI policies, causing undesired conditions in their queries.

For example, if you populate a user in the Caller field, it automatically sets the location, phone number, etc... (Any other derived field on the form/view) This changes the query from



location=25b3d04b0a0a0bb300176b546c22db27^caller_id=62826bf03710200044e0bfc8bcbe5df1^caller_id.phoneSTARTSWITH(855) 505-6555

This causes issues when the glide.ui.format_phone system property is set to true (by default). Search screens support only STARTSWITH queries and because the condition looks for caller_id.phone records that start with (###), no records are being returned because the phone number values are stored without the parenthesis in the sys_user table.

Steps to Reproduce

Note - These steps to reproduce show an example of the detrimental effect of client scripts running on an Incident search screen but this problem also applies to UI policies and to Problem and Change search screens.

  1. Ensure that demo user Abel Tuter has both a location and phone number defined in his user record.

  2. Ensure that Location and the derived field Business Phone are added to the incident form (default view).

  3. Create one or two incidents with Abel Tuter as the caller.

  4. Right-click the Incident application menu and choose Edit.

  5. Add a new module in the related list with the following values:

    Link Type: Search Screen
    Table: Incident
    View name: Default

  6. Open the module and enter Abel Tuter.

    The location and phone number are populated unexpectedly.

  7. Click Search.

    Note that the phone number and location are included in the search conditions and that the phone number is formatted with parenthesis around the area code. This formatting results in no records being returned from the search.

    Removing the phone number condition from the query returns the expected results. Setting the glide.ui.format_phone property to false will format the phone number as it is listed in the user record, which will return the records.


There is no known workaround for this issue. The permanent fix to this issue was released in Istanbul.

Related Problem: PRB650436

Seen In

Fuji Patch 10
Fuji Patch 7 Hot Fix 5
Fuji Patch 8
Fuji Patch 9 Hot Fix 1
Geneva Patch 7
Helsinki Patch 3

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-04-10 10:37:41