Knowledge article dynamic linking

[Beth11]

So this is a problem I'm dead certain someone else has had to tackle and answer. I'm importing and converting a very well-written and maintained knowledgebase. Images, videos, all of that is tackled, but what I can't seem to puzzle out is links between KB articles.

There are a lot of them, and the problem isn't as straightforward as it might at first appear. The way I see it, I've got two hurdles I need to overcome: Versioning and Service Portal.

Versioning, by itself, is not insurmountable. The system itself provides a way, here: links that use the KB number.

https://<instance>.service-now.com/kb_view.do?sysparm_article=KB0000030

Which, awesome, this will always link to the latest version of the article. But when you throw Service Portal into the mix, it falls apart for a few reasons:

1. Service Portal recognizes https://<instance>.service-now.com/sp/kb_view.do?sysparm_article=KB0000030 well enough, but it does so by stripping out the /sp/ and loading the kb article in the default ITIL view. This won't work for us; we need to preserve the SP branding and nagivation bars.
2. No matter how an article is called, the url displayed is always in this format:   service-now.com/sp?id=kb_article&sys_id=d15de43187032100deddb882a2e3ec7d
   This makes linking the latest article from a web browser just about impossible.
3. The links in the article itself won't work properly. Instead of sending the user to the Service Portal view of the article, the link will send them to the unadulterated (no navigation menus or other kibble) link in the full application view. This is undersable because we don't want end users in the itil view at all, and if they somehow get there showing them zero context is jarring and unhelpful at best.
4. If I were to include all of these links, somehow, in a way that worked for Service Portal, now I have the issue where I'm breaking the ITIL users if they try to browse articles and forcing them out into Service Portal. This is also less than ideal.

So, to recap:

Currently, the kb_view.do? method of linking articles works to counteract the versioning problem. But Service Portal vs ITIL is still an issue that I don't see an easy way around. So my question is this:

• Is there a way to configure kb_view.do or create my own custom linking mechanism?
• If I do so, does anyone have a recommendation on programming it to detect if the user is on SP/Full view?

Thanks in advance for any help or suggestions you might have.

UPDATE: Having unsucessfully tried modifying the UI page and creating a processor to intercept the kb_view references, I'm starting to think that I need to disable the html sanitizer on the knowledge text view and use a javascript onclick for routing... It's either that or own both the SP widget and the UI Page for displaying knowledge articles. I hate to mess with the sanitizer, but my options are looking a little thin at the moment.

[Jon Barnes]

Because your KB Articles all link to other articles with the URL formatted as you have stated, I think you will have to build your solution into the "kb_view" UI Page. You should be able to write a g:evaluate script at the top that will determine if the URL is a service portal URL, and then use the KB_article parameter of the URL to do a gliderecord query search of the kb_knowledge table finding the latest version of the article with that number, and then format a URL that is service portal formatted and redirect from there.

Does that make sense?

[Beth11]

That... might work, actually. I was going down the processors route, and while I think that would eventually work getting the referring URL was proving to be a real pain. Let me try it this way and see how it looks.

Thanks for setting me on a path, I'll update with what I find out.

[Beth11]

With a little more research, I've hit a somewhat silly stumbling block. I tried dropping a kb_view link into the body of a test article. I can click on it all right and it does as expected (take me to the itil view.) I put a quick <script> into the kb_view UI page and had it write out document.referrer, and it doesn't seem to be preserving the actual reference: it's spitting out the exact address of the link (so the current url, not the referring one).

I took a stab at some other methods for getting the referring URL, but RP.getReferringURL() in the g:evaluate tag seems to have the same problem. I even cast futher afield and tried

var tr = new GlideTransaction.get();
gs.log("second try " + tr.getRequest().getRequestURL(),"kb_view_2");

But this also returned the new URL:

second try http://llnldev.service-now.com/kb_view2.do

When the actual referring URL is:

https://<instance>.service-now.com/sp?id=kb_article&sys_id=bb18d1aadb4c1b801a9efd0e0f961967

Any thoughts on how I can successfully determine if the kb is being viewed from the portal or not? I've done a bit in jelly but very little with service portal at this point, so I might just be missing something in my google searches.

Edit: added actual source URL for clarity.

[Jon Barnes]

actually, yes, I was thinking about them being relative URLs, so thought the URL in getRequestURL() would have "sp" in it.

Ok, another direction you could go that may be more promising:

You could clone the KB Article Page widget, and in the server script, after you set data.text to the content of the article, do a global replace of "https://<instance>.service-now.com/kb_view.do?" with "?id=kb_article&". which should leave you with the URLs as "?id=kb_article&sysparm_article=KB0000030", which should take you where you want to go.

Then, you would also update the server script to allow sysparm_article parameter, and if that is passed in, find the latest article by that number instead of looking up by sys_id as it is now.

Finally, you will have to update the kb portal page to use your new widget.