Slow load/search time for request offering user selection

James_Johnson

Hello all,

I'm trying to create some new service request offerings and need to select some users such as manager etc for the requests. I turned on the Request Offering's Query Result Picker, which look so much better than the default, and it's working but it takes a full minute from opening the request offering page until searching a name actually shows the results of the search.

Other user pickers in the portal work fine and return results quickly, such as affected user in incidents or even the custom search bar, that probably everyone uses.

Here is a link to a video of how long it takes from typing in the name until it actually shows up: https://vimeo.com/user104128371/review/367353111/b1fff1051f

Is there anyway to speed this up? I'm using just the displayname for search and it's the only column showing.

Thanks!

James

Konstantin_Slavin-Bo

The issue is, that the portal caches the returned items, before letting the user search for them. There's a few workaround for this, not all of them are pretty.

The original workaround is to have a String prompt right above the query, where to prompt for a username, and use that input as a token in the criteria of your query prompt, where the user will have to select the result from the search. It'll look like this:

https://i.imgur.com/I1qz5t8.gifv

Not pretty, but there's some community solutions to clean it up a bit (like removing the 'Filter' box). The issue is, that you still have a limit on how many users are originally returned to be filtered, so you risk that not all users are searchable (read more in KA1100).

The more up-to-date approach is using the ROToolbox (newest version is found on github), which can make it a little prettier. The setup is the same: a (optional) text prompt for username and using that as a query prompt, except you'll need to add a text-only prompt above the text prompt with the text "@AutoComplete" or "@MultiSelect". But this time, ROToolbox allows us to combine the two prompts into one search-field, with the very important benefit that the filtering is done server-side, so you will always get all results. It looks like this:

https://i.imgur.com/QzCGNCl.gifv

Finally, there's also the new query picker, which can be activated in Admin Settings -> Features, which addresses some of the issues, although I believe it still does client-side filtering, where you can risk not having all users returned.

Edit: Apparently gifs aren't uploaded correctly to here, so I linked to the examples instead.

Timothy_Boyce

Are you limiting the search results in the Configure Prompt field to narrow down the results?

The more results returned the slower it will be, depending on how many users you are importing into the CMDB. Here is an example of one I am using. I am limiting to a child domain, and a particular OU.

There are other ways to accomplish this, like extending the Active Directory Users MP, into a custom MP, to also import the Users manager, so it is a filterable field, Or you could use Orchestrator to auto update the Request Offering with the required info.It all depends on how complicated you would like to be

James_Johnson

Hi @Timothy_Boyce, thanks for the answer.

The only way I could limit the choice is if I could filter by AD group membership which unfortunately isn't an option unless I do like you mentioned and extent the user class. Also we don't track supervisors in AD so that doesn't help me for that choice.

We also have 30k users in our portal DB, we don't support all of them but we have to have the option there just in case we might have to. It just seems like the logic of the query result picker is flawed and won't really work with that many users. Perhaps there is some kind of work around to picking users and settings them related fields or even just putting their usernames in a property somewhere?

Thanks!

James

Konstantin_Slavin-Bo

The issue is, that the portal caches the returned items, before letting the user search for them. There's a few workaround for this, not all of them are pretty.

The original workaround is to have a String prompt right above the query, where to prompt for a username, and use that input as a token in the criteria of your query prompt, where the user will have to select the result from the search. It'll look like this:

https://i.imgur.com/I1qz5t8.gifv

Not pretty, but there's some community solutions to clean it up a bit (like removing the 'Filter' box). The issue is, that you still have a limit on how many users are originally returned to be filtered, so you risk that not all users are searchable (read more in KA1100).

The more up-to-date approach is using the ROToolbox (newest version is found on github), which can make it a little prettier. The setup is the same: a (optional) text prompt for username and using that as a query prompt, except you'll need to add a text-only prompt above the text prompt with the text "@AutoComplete" or "@MultiSelect". But this time, ROToolbox allows us to combine the two prompts into one search-field, with the very important benefit that the filtering is done server-side, so you will always get all results. It looks like this:

https://i.imgur.com/QzCGNCl.gifv

Finally, there's also the new query picker, which can be activated in Admin Settings -> Features, which addresses some of the issues, although I believe it still does client-side filtering, where you can risk not having all users returned.

Edit: Apparently gifs aren't uploaded correctly to here, so I linked to the examples instead.

James_Johnson

@Konstantin_Slavin-Bo Thanks for the in-depth answer, I'll definitely check out the ROToolbox. It looks like it should help resolve most of the issues I am dealing with.

Thank you!

James