- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-31-2024 05:36 PM
We have a URL field on a UI form (rm_epic) that we would like to display a different text for the link than the base URL value. We have been told that this is not a feature of the URL field but that we could request an Enhancement for it, so if you are looking this up for the same reason, please consider submitting an Enhancement request yourself for this.
First, we looked at a DOM solution from the community, which modifies the HTML on the page itself, something that is not supported, but which worked on a similar form (rm_story). Both are derived from task, like most ticket tables. This was done using a UI Policy that ran this script: (note the URL and the label fields are both custom, u_external_link and u_external_id, both are declared at the task table level so they are inherited as the same field on both forms.)
function onCondition() {
var record = new GlideRecord('rm_story');
var sysID = document.getElementById('document_tags').getAttribute('data-sys_id');
//g_form.addInfoMessage('epic sys_id:' + sysID);
record.addQuery('sys_id', sysID);
record.query();
while(record.next()){
if(record.u_external_id){
document.getElementById('rm_story.u_external_url_link').innerHTML = record.u_external_id;
} else {
document.getElementById('rm_story.u_external_url_link').innerHTML = 'Open in external system';
}
}
If the URL has an entry, it looks for a value in the u_external_id field and sets the HTML display for the link to that value (rather than the http address). This works fine in rm_story. But the exact same code (with the table names replaced) does not work in rm_epic. It appears that for some reason the document.getElement().innerHTML calls are halting the script. No errors appear evident and a try/catch doesn't trip.
The current testing version of the UI Policy for rm_epic script is:
function onCondition() {
var sysID = g_form.getUniqueValue();
var rec = new GlideRecord('rm_epic');
var found = rec.get(sysID);
if (found && rec.u_external_id) {
g_form.addInfoMessage('found and u_external_id=' + rec.u_external_id);
document.getElementById('rm_epic.u_external_url_link').innerHTML = rec.u_external_id;
} else {
g_form.addErrorMessage('not found');
document.getElementById('rm_epic.u_external_url_link').innerHTML = 'Open in external system';
}
}
Note that I have replaced the original document. call with a g_form.getUniqueValue() to get the sys_id. I have not found a ServiceNow recommended solution for changing the displayed URL link however.
The g_form.addInfoMessage() does run and the message states found along with the external id for that entry, so the record is being accessed and u_external_id value is set and available. But the document.getElementById().innerHTML call on the next line seems to just end the script run.
Note that I did check the page source and confirmed that the id 'rm_epic.u_external_url_link' does exist as well.
I'm guessing for reasons that are unclear the DOM protection is being activated on one form and not the other.
Support confirmed that the likely issue was DOM access but did not explain why the code worked for rm_story but not for (the far less customized) rm_epic.
I have seen the mentions of a widget/formatter solution, in these two community posts:
https://www.servicenow.com/community/developer-articles/usage-of-quot-custom-with-label-quot-variabl...
and
https://www.servicenow.com/community/developer-forum/change-url-display-text-in-list/m-p/1360876
Management is deciding whether to use more development hours to implement this.
In the meantime, anyone else have any other ideas on how this could be done?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-05-2024 06:42 AM
The issue was a simple one, the original solution applied to the rm_story included modifying the 'Isolate script' field on the UI Policy, setting it to "false" (disabling DOM protection for that UI Policy specifically).
Hat tip to my fellow Synoptek architect Davin for recognizing the UI Policy also had this feature. (Note: this is a non-displayed field normally, but you can view and modify it by adding it to the list view of the table.)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-31-2024 06:49 PM
Hey Kelly,
I understand what you are trying to achieve here. Frankly, I feel using a UI Policy to do this is a hack that will fail someday or the other. Plus, in future if one wishes to modify the config, the last place one would check is a UI Policy😉
Imho, the best way to do this is:
- Create a form button on your table(UI Action)
- Have it call a GlideDialogWindow/GlideModal popup (UI Page)
- In the UI Page, place an HTML anchor tag -> then use g_form to fetch the URL field value on the current record, and finish it off with DOM manipulation to update the anchor tag with your display text. (jQuery to the rescue😎)
- And Oh, hide your URL field on the record form. (People should use the popup to get to the URL. Hassle? I'd say it's cleaner, and much stabler)
P.S. A formatter is ok'ish thing to do... but still meh...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-05-2024 06:36 AM
It appears that you are suggesting to replace the built-in functionality of a URL field with a UI Action that calls a UI Page. I'm not seeing the value added by doing so. Is this more secure in some fashion?
As for changing the appearance of a form using a UI Policy, I would make a case that this is the first place an experienced admin would look to find code that changes a field display, but maybe that's just me. I do recognize that UI Policies are generally overlooked because they allow low-code options to modify field displays, but maybe this could be a useful reminder that they can run scripts in addition to the handy packaged actions.
Putting this aside, you haven't provided a solution to the issue of using DOM manipulation to change the anchor tag, just moved where it's done. So your suggestion doesn't address the core question of finding an alternative to DOM manipulation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-05-2024 06:42 AM
The issue was a simple one, the original solution applied to the rm_story included modifying the 'Isolate script' field on the UI Policy, setting it to "false" (disabling DOM protection for that UI Policy specifically).
Hat tip to my fellow Synoptek architect Davin for recognizing the UI Policy also had this feature. (Note: this is a non-displayed field normally, but you can view and modify it by adding it to the list view of the table.)