Encoded Query not working when it contains non-URL Safe characters

[pault1]

Trying to query SN table via REST API and discovered that when I pass in a sysparm_query that contains non-URL Safe special characters, matching records are not returned.

Query Example:

"u_tag_source=Hosting^u_key=!@#$%^&*() A tag"

When I try to do the same thing in the table's List view, I get the same result.

First image is with a single filter on u_tag_source:

Second image is by right-clicking the u_key column on the first record and selecting "Show Matching".

Notice that the filter added cuts off everything after the percentage sign. And when I add that filter, the URL is set to:
nav_to.do?uri=/u_configuration_item_tag_list.do%3Fsysparm_query%3Du_tag_source%253DHosting%255Eu_key%253D!%2540%2523%2524%2525%255E%2526*()%2520A%2520tag%26sysparm_first_row%3D1%26sysparm_view%3D

I think the filter is not being URL encoded, which explains why this doesn't work in the UI, but

When I URLEncode the filter value and submit via REST API, this is what I am submitting:

"u_tag_source=Hosting^u_key=!%40%23%24%25%5e%26*()+A+tag"

This still doesn't work. Anyone seen this behavior and found a solution?

[bernyalvarado]

Here goes the complete information of what worked for me:

Incident with short description : !@#$%%^&*

Query:

var gr = new GlideRecord('incident');


gr.addEncodedQuery('active=true^short_descriptionSTARTSWITH!@#$%%\^&*');
gr.query();
if (gr.next()){
       gs.print(gr.short_description);
}

Output

*** Script: !@#$%%^&*

Thanks,

Berny

[bernyalvarado]

Hi Paul,

I hope this helps. Please let me know if you have any further questions.

Thanks,

Berny

[pault1]

So looking at where you're going with this, it looks like the special character we're having an issue with is the carat (^)? Which makes sense since that character is used as an AND operator. Searching more specifically for this condition I found this thread which seems to be my exact issue:

https://community.servicenow.com/thread/232046

As for your solution, I'd rather not use STARTSWITH, because what I'm doing is syncing key value pairs for a configuration item into CMDB, so I need an exact match, otherwise I might delete records that exist in CMDB but not in my tag source that I am syncing. I guess within my sync logic, post-REST call, I could then re-assert the match against the results, so there's a workaround there, but I think it's sloppy. But I don't see any other options.

[pault1]

So talking to another developer here, we think what we'll do is create a custom field that will store the base-64 encoded value we are searching on, and that will allow us to get an exact match. Thanks for the suggestions Berny, you got me steered in the right direction!

[divya mishra]

Hey Paul,

You can use "contains" in your query.

post me your feedback

Please Hit ✅Correct, ��Helpful, or ��Like depending on the impact of the response

Have a lovely day ahead

Regards,

Divya Mishra