Request create property panel - JavaScript API unstable

Can you please share what is going on behind the scenes when the event with serialize method is executed:

AP.require(["events"], function(events) {
        var requestProperties = new AP.jiraServiceDesk.RequestProperties();

        events.on("jira-servicedesk-request-properties-serialize", function() {
            requestProperties.serialize({
                com_company_myapp_location_issue_property: $("#location").val()
            });
        });
...
}

I was searching for source code, but it seems like it is dynamically inserted, I can’t find it in debug-all.js

Our customers reports that creating requests (saving property) using this API is unstable, around 1% of requests don’t contain properties that should be saved.

API documentation states:

Your app must call the corresponding API method immediately. There must not be any asynchronous operations done between receiving the event and calling the API method.
https://developer.atlassian.com/cloud/jira/service-desk/request-create-property-panel/

We double checked that.

Is the body of the event executed in a Web Worker? If yes, do you know any corner cases, beside browser support which we should be aware of and could investigate further?

If the implementation of this API is publicly visible, could you help me find it?

We really need your help in this case, we are struggling to find the root cause

@shwa could you help :slight_smile: ?

Hi @maciej.dudziak, the code does not exist in all-debug.js because it is registered dynamically when your app’s iframe is loaded. It will be hard for you to see because this registration code is minified.

My suspicion is there are circumstances where your iframe did not load, and JSD portal UI will not block request creation because of this, hence the requests are created without the data.

And no the body of the event doesn’t run in a WebWorker.

1 Like

Hi @gtan, thank you for your help. We are aware of the case with the iframe load, it is a pity that the “send” button can’t be blocked earlier, but I am aware of pros and cons of this solution.

What we want to understand and what we are not 100% sure is, what actually happens with the event. We have reports from our customers that users did entered data ( using our part of the form ) and later those data were not present

During investigation we did an experiment, we put simple endless “for” loop (synchronous) in the body of the event. After 2-3 seconds request was sent nevertheless which caused redirect to request details. Therefore my assumption that WebWorker or maybe other technology is used there, because the body of the event is not executed in the same thread as the rest of the code.

Could you provide more details how it is implemented?