- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-05-2018 02:09 PM
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.
Solved! Go to Solution.
- 15,457 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-19-2019 08:56 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-06-2018 10:12 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-06-2018 07:50 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-13-2018 01:42 PM
Thank you very much Sungsu!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-13-2019 02:46 AM
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.
Regards
Paul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-19-2019 08:56 AM
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.