Service Portal snRecordPicker directive advanced reference qualifier

[Katie A]

Hello,

I am using the 'sn-record-picker' directive in the Service Portal. I have it working with a basic query active=true.

<sn-record-picker table="'sys_user'" value-field="'sys_id'" display-fields="'email'" search-fields="'name,email'" page-size="100" default-query="'active=true'"></sn-record-picker>

I want a much more advanced query to pull the results, that is not possible to achieve with simple conditions. I already have a script include class that I am using for this purpose in an Advanced Reference Qualifier in the standard ui.

Is it possible to utilize script include class to populate the results (just like the Advanced Reference Qualifier in the standard ui)?

I would imagine there must be a way to pass in a script include method into the default-query attribute?

<sn-record-picker table="'sys_user'" value-field="'sys_id'" display-fields="'email'" search-fields="'name,email'" page-size="100" default-query="'advancedRefQual()'"></sn-record-picker>

[Justin77]

It sounds like you are working in a widget.  Correct me if I'm wrong, but assuming you are working in a widget:

default-query has to equal a string. The directive builds a query string (like an encoded query), based on what is made the "default-query".

To dynamically set that string, you can run your script include server side, return a string, store that string in the data object, and use that data object as the default-query.

 Your HTML would look something like: default-query="data.dynamicRefQual"

And in your server script, you would need to define that with: data.dynamicRefQual = nameOfScriptInclude()

Yet again, that assumes the script include returns a string value.

Let me know if that helps at all!

[SIMTEC]

Thanks a lot for this quick reply! I have overseen the reply of "Katie A", where she was explaining the same solution! In the meantime, i have tried this and it works for smaller query-strings:

1. Widget: ServerScript call Script-Include and store encoded Query in string

2. Populate it to the data-object (data.yourQueryString)

3. HTML: use it in <sn-record-picker> directive: defalut-query="c.data.yourQueryString"

This will work with "smaller" strings. But right now, i am struggling with a string like: sys_idINabcde123...,abcde321...,edcba123...,[...] with appr. 1000 results. No results show up, only "Searching...". It looks like a performance problem: When i test it with 5 hardcoded sys_id's, it works fine. But not with the "longer" returned QueryString of the Script-Include-Call.

But: The Script-Include function works fine with for example Reference-Filed-Variables.

And: WITHOUT a default-query-string, the <sn-record-picker> directive handles the complete table with 4.300 records very smooth!

Any idea how to get it running?

[SIMTEC]

For all, that are interested in this: I now made a <select> directive with data generated in my Server-Script. There is no performance problem with that!

1. Make a GlideRecord and use the Script-Include for the query
2. Store the objects/values in the data object, e.g. data.myOptions
3. In HTML build the select directive and fill it with <option ng-repeat="value in c.data.myOptions">

It works really smooth - no waiting times for me with 200-1.000 records! ...while the sn-record-picker striked!

[Katie A]

Hmm I wonder if there's some sort of limit on the size of the query. Does it work with a smaller number of records vs a larger number? You mentioned it works with hard-coded sysids, but does the code itself work with a small number of records? I suggest testing to see if the problem is in fact the number of records being returned (and therefore the length of the query) by printing out the number of records and adjusting the result set accordingly. If it works with a small number of records but not a large number of records, there might be some limit on the ServiceNow side. My particular use case only has about 20 records maximum ever returned, and it works for me, but I have not tested with larger sets of records.

[Chris Martin8]

I found this thread while trying to solve this myself and have now discovered that there is now a system property - glide.sc.request_for.query - that holds the string used for default-query.


Cheers,

Chris