question Knowledge article dynamic linking in Developer forum

Knowledge article dynamic linking

Beth11 — Mon, 05 Feb 2018 22:09:55 GMT

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:

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.
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.
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.
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.

Re: Knowledge article dynamic linking

Jon Barnes — Mon, 05 Feb 2018 23:04:02 GMT

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?

Re: Knowledge article dynamic linking

Beth11 — Mon, 05 Feb 2018 23:21:15 GMT

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.

Re: Knowledge article dynamic linking

Beth11 — Tue, 06 Feb 2018 00:07:16 GMT

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.

Re: Knowledge article dynamic linking

Jon Barnes — Tue, 06 Feb 2018 00:43:59 GMT

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.

Re: Knowledge article dynamic linking

Carl Fransen1 — Wed, 23 May 2018 22:05:49 GMT

Hi,

I'm also struggling with this - we use both the /sp and /hrportal and these do not work, i can't show anything but the backend version of the knowledge article using the url below:

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

I have tried a number of iterations but they all show as error 404 or 'article not found'.

Anyone solved this on the portals?

Thanks

Carl.

Re: Knowledge article dynamic linking

Beth11 — Thu, 21 Jun 2018 23:44:47 GMT

Hi Carl,

I ended up going with an iffy solution that involved a fair bit of work to get going. In the end, how you proceed is going to depend on how important it is to your end users to be able to view past article versions. If it isn't, here's what I would do:

Clone the existing knowledge content widget (I believe it's kb-article-content). From here you can either manipulate the date being fed in populateParameters() or point it at a new function in KBViewModel.
In the populateParameters or the new function, Run two queries: one to get the article passed by sys_id, and a second to get the latest version of that article.
Feed that article back the same way that KBViewModel is intended to work.

This might require some trial and error to make sure you're covering all of the URL types that you might see, particularly in articles that link to other articles. What we ended up doing was slightly more complex and involved making the page handle both sys_id and KB number, since that was an additional requirement, but if you don't have to do that there's no reason to complicate matters.

Let me know if that's confusing and I'll try to clarify with some examples.

Re: Knowledge article dynamic linking

Beth11 — Thu, 21 Jun 2018 23:46:36 GMT

We ended up overriding the default behavior in the knowledge content widget to check for the latest version before it retrieved the full KBViewModel widget.

Re: Knowledge article dynamic linking

Carl Fransen1 — Sun, 24 Jun 2018 19:49:37 GMT

Thanks for taking the time to explain how I can go about changing this, I will look into this further and see if I can get this working.

Cheers

Carl.

Re: Knowledge article dynamic linking

natty29 — Tue, 04 Sep 2018 04:32:51 GMT

Hi Beth

Can you please demonstrate the script you used in your knowledge content widget to query for the latest version?

Nat

Re: Knowledge article dynamic linking

Beth11 — Thu, 06 Sep 2018 17:12:47 GMT

I can't demonstrate, but I can describe what we did! Basically if you take a look at the service portal widget, you can see it's populating parameters at a certain point. Where it populates the sys_id parameter, we intercept that parameter and run a couple of queries:

(worth noting that all of these changes are in the server script; I did not need to touch client script or HTML for this modification.)

First, we grab the record identified by the sys_id url parameter

Then we get the latest record using the kb helper for versioning

Then we feed that back into the script instead of letting it use the URL parameter

The latest version helper is found in the KB_Versioning script include and I believe it takes the KB number and not a sys_id, which is the reason for the first query. You might be able to get away without it if I'm remembering incorrectly.

Did that clear it up?

Re: Knowledge article dynamic linking

s_kang — Fri, 07 Sep 2018 02:50:28 GMT

I have created a custom portal widget. And I confirmed that it works properly.

in this way!

KB Article Page

https://[your instance].service-now.com/nav_to.do?uri=sp_widget.do?sys_id=c6545050ff223100ba13ffffffffffe8

Please replace with this code in Server Script after clone widget.

-----------------------------------------------------------------------------------------------------------

var t = data;
data.kb_knowledge_page = $sp.getDisplayValue("kb_knowledge_page") || "kb_view";
var articleGR = GlideRecord("kb_knowledge");
var newestKB = newestGet($sp.getParameter('sys_id'));
articleGR.get(newestKB);
var recordIsValid = articleGR.isValidRecord();
var canReadArticle = articleGR.canRead();
t.isvalid = recordIsValid && canReadArticle;

if (canReadArticle) {
articleGR.incrementViewCount(); // update sys_view_count immediately on kb_knowledge record
var art = new GlideRecord("kb_use");
if (art.isValid()) {
art.article = articleGR.getUniqueValue();
art.user = gs.getUserID();
art.viewed = true;
art.insert(); // kb_use records are aggregated to update sys_view_count nightly
$sp.logStat('KB Article View', "kb_knowledge", articleGR.getUniqueValue(), articleGR.short_description);
}

t.category = articleGR.getValue('kb_category');
t.sys_id = newestKB;
t.showAttachments = false;
if (articleGR.display_attachments)
t.showAttachments = true;
t.categoryDisplay = articleGR.getDisplayValue('kb_category');
t.short_description = articleGR.getValue('short_description');
if (articleGR.getValue('article_type') == 'wiki')
t.text = GlideWikiModel().render(articleGR.getValue('wiki'));
else
t.text = articleGR.getValue('text');
t.sys_view_count = articleGR.getDisplayValue('sys_view_count');
t.author = articleGR.getDisplayValue('author');
t.publishedUtc = articleGR.getValue('published');
t.number = articleGR.getValue('number');
if (showStarRating())
t.rating = articleGR.getValue('rating');
t.direct = false;
if (articleGR.direct)
t.direct = true;

t.breadcrumbs = [{label: t.short_description, url: '#'}];
if (!articleGR.kb_category.nil()) {
var rec = articleGR.kb_category.getRefRecord();
while (rec.getRecordClassName() == "kb_category") {
t.breadcrumbs.unshift({label: rec.getDisplayValue(), url: '?id=kb_category&kb_category=' + rec.getUniqueValue()});
rec = rec.parent_id.getRefRecord();
}
}
t.breadcrumbs.unshift({label: gs.getMessage("Knowledge Base"), url: '?id=' + t.kb_knowledge_page});
}

function showStarRating() {
if (options.show_star_rating == "Yes")
return true;

if (options.show_star_rating == "No")
return false;

if (gs.getProperty("glide.knowman.show_star_rating", "true") != "true")
return false;

return gs.hasRole(gs.getProperty("glide.knowman.show_star_rating.roles"));
}

function newestGet(sys_id){
var kb = new GlideRecord('kb_knowledge');
kb.addQuery('sys_id', sys_id);
kb.addQuery('workflow_state', 'outdated');
kb.query();

if(!kb.next()){
return sys_id; // current sys_id
}

var kbn = new GlideRecord('kb_knowledge');
kbn.addQuery('number', kb.number);
kbn.addQuery('workflow_state', 'published');
kbn.query();

if(kbn.next()){
return kbn.sys_id; // newestKB sys_id
}
return sys_id; // exception
}

-----------------------------------------------------------------------------------------------------------

Hope things are going well for you!

Sungsu

Re: Knowledge article dynamic linking

natty29 — Thu, 13 Sep 2018 20:42:31 GMT

Thank you very much Sungsu!

Re: Knowledge article dynamic linking

Paul Curwen — Tue, 13 Aug 2019 09:46:54 GMT

It's really painful that KB versioning is so hard to get right in Portal with us all reinventing the wheel. ServiceNow really dropped the ball with KB versioning and Portal.

I cannot imaging a scenario in Portal where you would ever want to see an old version of the article. Surely ServiceNow should have updated all related widgets by now to have a 'go to latest version' option which would be the default.

Re: Knowledge article dynamic linking

Beth11 — Mon, 19 Aug 2019 15:56:15 GMT

Since this has become something of a hub for this conversation:

As far as I know, there's still no good answer for this problem. Owning the KB view widget partially solves the problem, but there are other widgets that start to have issues (like kb_header) and long term it feels like I'm going to own more and more of this page if I want everything to work right.

Realistically, everything I do is a band-aid, since we don't have good visibility on some of the versioning code to fix the problem at the source. If/when SN comes out with a better solution, I'll circle back and update this answer, but right now check the comments for several potential workarounds for this problem.

Re: Knowledge article dynamic linking

James150 — Fri, 06 Sep 2019 09:36:15 GMT

You can retain branding by using the Madrid Knowledge Base portal plugin (com.snc.knowledge_serviceportal). This adds a new portal (/kb) designed to replace the Service Portal knowledge base page.

Articles can then be permalinked directly to the portal, e.g.:

https://xxxx.service-now.com/kb?id=kb_article_view&sysparm_article=KB0010528

A copy permalink button appears at the bottom of articles within this portal:

Re: Knowledge article dynamic linking

Michael QCKM — Thu, 12 Dec 2019 20:01:45 GMT

Thank you Beth for this very detailed write up. It seems we are all suffering from the same issues. That is sadly comforting. I am HIGHLY interested in any solutions you obtain for this, and I in-turn will share if we obtain any. In my opinion, based on so many shortcomings is that SN is NOT a useful KM solution.

Re: Knowledge article dynamic linking

Paul Curwen — Fri, 13 Dec 2019 16:35:50 GMT

I believe our payers on versioning (and frustrations with this) have been answered in New York. See:

https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/build/service-portal/task/redirect-knowledge.html

Haven't tested this out yet but if what I'm reading is right it's the answer we've been looking for for years. This is the fella:

Let me know if anyone has success with this.

Regards

Paul

Re: Knowledge article dynamic linking

Erik24 — Tue, 29 Sep 2020 08:58:40 GMT

Old thread but I'm guessing it's still a problem? I at least have not found a way to create durable links between articles (preferably using the internal/ITIL view kb_view permalink) that directs you to the same UI you're viewing it from.

We tried using the permalinks from the portal but then there was a change on the portal URL and all links broke.

Re: Knowledge article dynamic linking

Beth11 — Fri, 02 Oct 2020 21:37:05 GMT

Hi Eric,

Yes, we still have our custom solution in place. We added a custom parameter (kb_number) and check for that parameter as well as the default sys_id; if we see kb_number defined, then we use a quick gliderecord on the server script for the article's sys_id. We then feed that into the default code for the widget. This invoved owning the header and body widgets (which has proved a pain when we wanted to implement knowledge blocks!)

A smoother method I've ended up using elsewhere is this:

- Accept any sys_id

- Check to see if the retrieved article is the latest version

- If it's not, go retrieve the latest and use it instead.

It's got the benefit of being seamless and not requiring you to own everything that ever generates a link to articles, just the things that process them (the header and and the body only, I think; if memory serves, the comments section gets the article information from the header, though that may have changed.) It's allowed me to greatly decrease the footprint of widgets we own related to this, and allows for more graceful handling of the links generated by contextual search.

Let me know if you need a hand and I can probably whip up some quick demo code on my developer instance.