Update - Resolved: It seems that the HTML Sanitizer (or more accurately a subset of it) was responsible for what we were seeing, despite the fact that all of the offending tags are in the built in whitelist. The short version is that while you can't modify the property com.glide.security.check_unsanitized_html once it's been set to "enforce" you can delete it in the list view of system properties, which has the same effect. Once we did this, the output from the script returned to normal.
Leaving this here in case anybody else runs into a similar problem.
Update: We did discover that the HTML Sanitizer was set to "enforce" in Dev, but "log_only" in Test. I'm disinclined to blame this setting, however since the tags that were removed are included in the built in whitelist -- which is immutable. I suspect that it's something very much like this, though.
Both our Development and Test instances were recently cloned from Production and subsequently upgraded to San Diego in preparation for upgrading our production to San Diego.When we do this, we have a narrow window of time where the state of all three instances is essentially the same, and no additional development happens until everything is on the same release again.
We have a UI Action to generate a knowledge article for a release that lists all of the stories and component releases that's generated when the major release goes to Beta, and again when it goes to GA. The scrip in the UI Action hasn’t been modified since September of 2019, and it has been working fine in every release up to Quebec, and is working fine in San Diego as well -- in the Test Instance. But it's broken in Dev. Which leads me to the conclusion that there is something configured differently in Dev, but since I haven't worked on ServiceNow since around the time the last changes were made to this script, I don't know where to begin looking for the "what" that's different.
Getting to the specific problem, there's a form button that the release manager clicks to "Create BETA KB Post". The script that runs behind that button, hoovers up every sub-release that has this major release as a parent, and every story that has one of the sub-releases as a parent, and iterates over the results to create a table that lists each sub-release, and all of its dependent stories in turn. The example only had one story, so it's perhaps not obvious that there's a table there when you look at the post, but in Test it looks like this:
If we look at it in the editor we can see the table:
And if we look at the source code we see what the script hath wrought:
If we do the same thing with the same release in Dev (remember that both of these were cloned form Prod, so we have them in more or less identical states) we see something that isn't at all like what we expect:
The entire table -- headings and all -- has been condensed into one line. Whic hbecomes obvious when we look at it in the editor:
And even more obvious when we look at the source code:
The <table>, <th>, <tr>, and <td> tags were all replaced by a single <p>aragraph tag when the record was created.
I don't know how this happened, or why it's only happening in Dev and not Test. But if I edit the article and manually add the markup to create the table, it doesn't complain about that. I can save the knowledge record with the table in it just fine. But the script can't.
The clones of Dev and Test happened a few weeks apart, but they were both cloned from the same source (Production) where the script has been happily generating tables since 2019. And since there wasn't (and still isn't) any problem in Production, I'm forced to conclude that whatever is causing this behavior is unique to the Dev instance -- and originated there, and wasn't overwritten by the clone. Because Prod (Quebec) and Test (San Diego) are doing just fine.
Any ideas -- even strange one -- are welcome. Because I'm all out of them myself, and this is holding up the Production upgrade because nobody knows what the root cause is.
Thanks in advance!
