Hi owessels ,

Just an update to tie up any loose ends.  I have feedback from the customer regarding what they are seeing:

The issue we’re experiencing is in regard to JSDCLOUD-9917, where we have an assets field, and ~120 objects. When a user goes to populate the field in a request from the portal, they can only scroll and see the first 50 objects, and only by manually typing can they see past the first 50.

So it is as you described and working as designed

Thank you!

Thank you for your response owessels .  I will circle back on this

Hi again, the fix is now rolled out to all production instances.

Hi everyone,

Apologies for the confusion, the fix has been rolled out to most of production, but not yet all sites so that's why some people would still be encountering the bug. I will close this again once it is 100% rolled out.

Cheers,

Oliver Wessels

Jira Service Management Engineer

Works on our cloud instance ! Thanks

Not working for me.

Hello,

This is still not working not even intermittently for me. Kindly revalidate this.

Hi, I've just test this fix and noticed it Intermittent, only works sometimes.

Can you please re-test 

Hi, Do we a have an ETA for this fix

Hello everyone,

This bug is currently being worked on by our development team. Thank you all for your patience. 

Regards,

Alex - Product Manager (Insight Cloud)

This work around in unacceptable;

"As a workaround, kindly add the Insight field to the View and Edit screen operations. Once done, edit it outside of the transition"

We are paying for the Jira Service Management Premium plan so putting it on "Long Term Backlog" is not acceptable.

I concur that long term backlog is disappointing. My company is in the process of merging with another. Originally one of the two halves of our company used Jira. We did a ton of research and decided to use Jira primarily because of Insights. Asset management was a critical part of the half of our company that was not originally using Jira. We are currently in the trial of the Premium version to setup and make sure Jira will work for us. It was clear that Jira was designed to make Issue creation simple and efficient. This adds a significant number of clicks to do what I was under the impression Jira was designed to do.

Wow, a bug like this is a long term backlog?  That seriously makes me reconsider our future with Jira.  This is a day to day issue my support desk has to fight with all day, every day.

Thanks Atlassian for putting it on the backlog, but I would argue 'Long Term Backlog' is wrongly categorized in this instance.
Seeing as the bug directly hinders user experience (forcing them to not use the handy transition screens, especially 'Create') it should be prioritized more highly.

Hi,

We need this bug to be fixed. Is there any planned date for its resolution?

Regards.

Search function behaviour outlined in this ticket returns first 50 insights objects from the remote endpoint and then filtering it out using the insight field input box value, locally via browser's javascript.

Going through the event listeners attached to the autocompletion insights field, a missing implementation of handling query attribute, required by autocomplete endpoint is evident.

This issue is due to missing the required "query" attribute as a part of the payload for autocomplete endpoint:
https://x-y-z.atlassian.net/rest/servicedesk/cmdb/1/field/customfield_10166/config/10319/autocomplete

The issue appears to surface originally in the incubateRequest function calling up Json Object string serializer via data() function which is passed in incubateRequest in 

module-key = 'jira.webresources:select-pickers', location = '/includes/ajs/select/fetchers/ajax-descriptor-fetcher.js'

Please note the line: 

if (typeof ajaxOptions.data === 'function') {
    ajaxOptions.data = ajaxOptions.data(query);
}

Code for the incubateRequest: 

/**
 * Prepare the data and prevent throttling of server
 * @param {jQuery.Deferred} deferred
 * @param {Object} ajaxOptions - standard jQuery ajax options
 * @param {String} query - in most cases this is the user input
 * @param {Boolean} force - ignore request buffers. I want my request dispatched NOW.
 */
incubateRequest: function(deferred, ajaxOptions, query, force) {    clearTimeout(this.queuedRequest); // cancel any queued requests    if (force && this.outstandingRequest) {
        this.outstandingRequest.abort();
        this.outstandingRequest = null;
    }    if (!ajaxOptions.query && this.lastResponse) {
        deferred.resolve(this.lastResponse);
    } else if (!this.outstandingRequest) {
        if (typeof ajaxOptions.data === 'function') {
            ajaxOptions.data = ajaxOptions.data(query);
        } else {
            ajaxOptions.data.query = query;
        }        if (typeof ajaxOptions.url === 'function') {
            ajaxOptions.url = ajaxOptions.url();
        }        if ((query.length >= parseInt(ajaxOptions.minQueryLength, 10)) || force) {
            this.makeRequest(deferred, ajaxOptions, query);
        } else {
            deferred.resolve();
        }
    } else {
        this.queuedRequest = setTimeout(_.bind(function () {
            this.incubateRequest(deferred, ajaxOptions, query, true);
        }, this), ajaxOptions.keyInputPeriod);
    }    return deferred;
},

the ajaxOptions.data is a function reference, initialised via 'jira.webresources:select-pickers' module init, and is missing implementation of handling the passed in query parameter.

Please refer to the data function implementation in

module-key = 'com.atlassian.servicedesk.frontend-webpack-plugin:context-jira.create.issue', location = 'jira.create.issue.bundle.js'

As you can see in the code snippet below, there is no query argument passed into inline function, and the implementation is just to return a json object of all form fields.

ajaxOptions: {
    ...
    data: function() {
        return JSON.stringify(m())
    }
} 

Implementation of data() function in other modules (user picker for example) includes appending query attribute.
Example for User Picker data handler (this is just for your reference, on how the insights autocomplete "data" handler could have been implemented

function data(query) {
    r.actionDescriptorId = void 0,
    g();
    var data = {
        projectKeys: r.projectKeys,
        issueKey: r.assigneeEditIssueKey,
        actionDescriptorId: r.actionDescriptorId,
        maxResults: 50,
        startAt: 0 === h._pagination.numberOfShowingItems ? 0 : h._pagination.numberOfShowingItems + 1
    };
    return p(data, query)
}
function p(data, query) {
    return u.extend({
        query: query
    }, data)
}

I have tested by modifying inflight request payload to the autocomplete endpoint, with the additional query attribute, and autocompletion returns a number of elements (less then stated 50) filtered by the query parameters.