- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-19-2024 09:32 AM
(This was posted in the Developer forum as well, but thought I may have luck here.)
I have duplicated the OOTB form widget and am using it to display case data on a custom page. I am using a custom table that is a child of HR Case and an HR Service built on that custom table. Whenever I save the form (even using OOTB UI actions), the widget "refreshes" and all of the values in string/checkbox fields get cleared. However, the updates do actually push to the server -- if I refresh the page or view the case in the back-end, the updates are there.
I believe this has something to do with my table specifically... When I test this using the OOTB form widget, table=sn_hr_core_case and another (HR Service) record's sys_id, the widget "refreshes" but the values stay on the form. If I change only the sys_id to that of my custom HR Service, the values get cleared. So any time my HR Service or table is inputted, the values clear, even on the OOTB form widget.
Do I need to add a record watch? I am confused because this appears to work for other HR Services. It may also be worth noting that I am unable to post work notes/comments to the case from the back-end currently. Not sure if this is related somehow.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2024 11:51 AM
Hey @James Chun, I actually just was able to figure out the issue... there is a function spUtil.simulateFakeFormSubmitForAutoComplete('widget-form', $scope.data.f._fields) that gets called within the function constructResponseHandler() in the client script of the form widget (ID: widget-form). I can't find any documentation on this specific function and have reached out to HIWAVE for more info... but commenting out this code seems to fix the inputs disappearing.
spUtil.simulateFakeFormSubmitForAutoComplete() function, which causes inputted fields to disappear
I figured this out by looking for when/how the widget data gets loaded. Sure enough, when the UI action completes (per the screenshot below) the loadForm() function gets called and then this constructRespondHandler() function gets called. At the end, this fakeSubmit thing happens.
widget-form client script (loadForm() function)
I'll update this thread when I hear back from HIWAVE. Until then... thanks for your help debugging! Hope this helps someone in the future.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-19-2024 08:59 AM - edited 08-19-2024 09:03 AM
Hey @Sndeveloper Adm , HIWAVE determined that the most probable cause was my custom service portal theme. When they tested changing the theme back to an OOTB one, supposedly the issues stopped. They also passed along this KB0759390. Maybe that will help you?
For me, commenting out that line worked. I'm not sure if the form widget received any updates in the past two ServiceNow family releases (Washington and Xanadu); that's my only hunch why it may not work for you. I'd recommend going through the code and commenting out functions one-by-one to see if they are the problem... that's ultimately how I figured out which function to comment out.
Edit to add: I saw an email notification for a different comment you left asking about cloning the widget versus just modifying the OOTB one -- best practice would be to clone the widget rather than modifying the OOTB one. The OOTB one will potentially be updated by ServiceNow in the future, meaning you would have to merge any of your fixes each time you upgrade your instance. Furthermore, you may not want this affecting all of your pages that use the form widget. By updating in the OOTB widget, you're making a global change.