Service Portal: Submit button gets stuck on "Submitting..." when Business Rule aborts the record ins
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi everyone,
I am facing a persistent issue in Service Portal (Record Producer) where the "Submit" button gets stuck in the "Submitting..." state after a server-side Business Rule aborts the submission.
Scenario:
- I have a Record Producer with an onSubmit Client Script that performs a confirmation dialog using g_modal.confirm.
- When the user clicks "OK", g_form.submit() is called.
- A Before Business Rule on the server-side validates the data and executes current.setAbortAction(true) with gs.addErrorMessage() if the validation fails.
- The form correctly shows the error message and stays on the page.
The Problem:
After the error message appears, if the user corrects the input and clicks "Submit" again, or if the user clicks "Submit" and then clicks "Cancel" on the confirmation dialog, the button remains in the "Submitting..." state and becomes unresponsive. It seems like the internal submission flag of the Service Portal widget is not being reset when the server-side abort occurs.
My Constraints:
- I cannot include validation logic in the onSubmit script itself because this script is stored in a Variable Set used across multiple Record Producers, so it must be generic.
- I am looking for a way to handle this button state issue without making complex modifications to the widgets or the platform internals, if possible.
Current Implementation:
function onSubmit() { if (g_scratchpad.submitFlg == null) { // First pass: Show confirmation popup getMessage("Confirmation", function(title) { getMessage("Submit Popup", function(msg) { g_modal.confirm(title + "<br><br>" + msg, function(confirmed) { if (confirmed) { // If OK is pressed, set submitFlg to '1' g_scratchpad.submitFlg = '1'; } else { // If Cancel is pressed, set submitFlg to '0' g_scratchpad.submitFlg = '0'; } // Trigger submit again g_form.submit(); }); }); }); return false; } else { // Second pass: Evaluate logic based on submitFlg if (g_scratchpad.submitFlg == '1') { // Proceed with submission return true; } else { // Clear submitFlg g_scratchpad.submitFlg = null; } return false; } }
Questions:
- Is there a standard way to reset the "Submitting..." state in the Service Portal when a server-side abort occurs?
- Are there any best practices for implementing a "Submit Confirmation" dialog in a Record Producer that co-exists well with server-side validation?
- Is there an officially recommended approach for this common scenario?
Any insights or workarounds would be greatly appreciated.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
This is a neat thing to see. I made an assumption that I could kind of replicate this in a standard Client Script and see how it actually works in a Workspace considering you are using g_modal. As it is, it was not working for me at all. I did get something working though which looks like this:
function onSubmit() {
if (!g_scratchpad.submitFlg) {
getMessage("Confirmation", function (title) {
getMessage("Submit Popup", function (msg) {
g_modal.confirm(title + "<br><br>" + msg, function (confirmed) {
if (confirmed) {
g_scratchpad.submitFlg = true;
g_form.submit() || g_form.save();
}
});
});
});
return false;
}
}
Whenever I am using submit() alone, something seems to be broken so including save() helps as a backup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I think you just have a client side js error that is causing the values in the widget scope to not update hence the view not updating. At least I couldn't reproduce this. Try it with the console open and see if you have something erroring silently in there.
As for validating the changes in a BR or even the RP script i don't think there is a way without customizing something in the widget. The widget will just call the service catalog api and it does not "fail" for a submitted producer if the insert is aborted with setabortaction.
sc api response
status 200 ok
{
"result": {
"sys_id": "-1",
"number": null,
"$$uiNotification": [],
"record": "api/now/table/incident/-1",
"redirect_portal_url": "",
"redirect_url": "incident.do?sys_id=76d6de569303c7540898b4897bba1001&sysparm_view=", //the api sets a sysid 'manually' but it will not be inserted, see sys_id prop
"table": "incident",
"redirect_to": "generated_record"
}
}
//this is a snippet from the redirect handler from the widget
function handleRedirect(n, table, sys_id, redirectTo, redirectUrl) {
var page = 'form';
if (table == 'sc_request')
page = sc_request_page;
else if (n)
page = 'ticket';
if (sys_id == -1)
sys_id = undefined; //<-----
if (redirectTo == 'catalog_home')
page = 'sc_home';
//....
So you'll just be redirected to the order confirm page without a valid sysid.
I'd say the use case for record producers is to gather a few key pieces of information from low priviledged users. If you need more functionality then you'd just use a form page. If you have to do this, then do the validation with a glideajax/gliderecord
