The situation we have is that we have created Managed Documents for the purpose of controlling versions and publishing approval. We then "linked" these to a Knowledge Article using the Related Links -> Link to Knowledge. on the Managed document page.
Here is where we are having an issue. We have created separate Knowledge Article (like the one below) that is like an overview page for the users. Think of it as a "Landing Page". It contains information and a set of links to other knowledge articles.
The links on the page are associated to Knowledge Articles that are linked to a "Managed Document". When the user clicks the link on the "landing page", it opens the related Knowledge Article. The behavior we want is for it to download the and related attachment and not open the Knowledge Article. We have set the flags ATTACHMENT LINK to True and DISPLAY ATTACHMENTS to False on the Article related to the Managed Document.
The code we are using for the "Blackout and Maintenance Schedule" link on the "Landing Page" is:
<td class="tg-uc1p"><img id="sphere" src="/green_sphere.pngx" alt="" /><a href="/kb_view.do?sysparm_article=KB0015502" target="_blank">Blackout and Maintenance schedule</a></td>
<td class="tg-031e">Used to load Blackout and maintenance windows in Drive IT, with associated Schedule entries and Child schedules.</td>
If you go to the Knowledge base and search on "Blackout and Maintenance Schedule", you are presented with a list of related articles. Clicking on the first article, gives us the behavior we are looking for. I downloads the attachment for the user.
If we point to the "href' on the "Landing Page" to the sys_attachement table it does behave like we want. However, this is not a solution for us as when the user updates the Managed Document and relinks the new version of the document to the Knowledge Article a new attachment is placed in the sys_attachment table and our landing page in now broken.
The issue arises when we try to add the link to the Article to another page. Instead of downloading the Attachment, it opens the knowledge article in new page. We are looking to see if anyone knows how to get the link on a page to behave the same way as if you click the link in the Knowledge Search results.
James and Ashley, when you search for knowledge articles and the list of articles is displayed, behind the scenes code is setting the URL behind the "click" of each article in the list based on whether the attachment link checkbox is checked. Here is an example...
I setup a few articles that start with "Michael Test" in my instance that have attachments. One has the attachment link checkbox checked and the other does not.
Using the Service Portal Knowledge Search (standard/platform UI behaves the same) notice when I hover over an article called Michael Test 2 that has an attachment but the attachment link checkbox is false the URL will show me the article text:
Now if I hover an article called Michael Test 3 that has an attachment with the attachment link checkbox true, notice the URL is directly to the sys_attachment table to download the attachment:
So again code behind the scenes is setting the appropriate URL based on that checkbox. So if you hard code a URL to use "/kb_view.do?sysparm_article=KB0015502" it will always display the article since the code that is changing the download behavior isn't "baked" into that UI page.
So how do you fix this? Well something needs to perform the same type of lookup to see if the checkbox is checked and change the URL to the Attachment for download otherwise display the article. The out of the box kb_view.do UI page won't work, however there is a feature called Processors that can perform this action for you. You may not recognize/know what a processor is, but you have definitely used them without knowing when you export records as Excel, PDFs, etc - a processor is behind the scenes making that work. With a processor, you will then have to use a "special" URL in your KB Article body instead of "/kb_view.do...."
- Navigate to System Definition \ Processors and click New
- Give it a name, I called mine "Knowledge Attachment"
- Set the type to script
- Set the path to the URL you want to invoke this processor. I set mine to "kb_attachment"
- Set the script to the following
(function process(g_request, g_response, g_processor) {
// Get the KB number from the query string
var kbNumber = g_request.getParameter("sysparm_article");
var redirectURL = "";
// Check to see if the KB article has the attachment link flag set to true
var kbArticle = new GlideRecord("kb_knowledge");
kbArticle.addQuery("number", kbNumber);
kbArticle.addQuery("workflow_state", "published");
kbArticle.addQuery("direct", true);
kbArticle.query();
if (kbArticle.next()) {
// KB Article has attachment link flag set to true query for the attachment SysID
var sysAttachment = new GlideRecord("sys_attachment");
sysAttachment.addQuery("table_sys_id", kbArticle.getValue("sys_id"));
sysAttachment.query();
if (sysAttachment.next()) {
// KB Article attachment found, redirect the user to download the attachment based on the attachment's SysID
redirectURL = "sys_attachment.do?sys_id=" + sysAttachment.getValue("sys_id");
} else {
// KB Article attachment not found, display KB article
redirectURL = "kb_view.do?sysparm_article=" + kbNumber;
}
} else {
// KB article does not have attachment link flag set, display KB article
redirectURL = "kb_view.do?sysparm_article=" + kbNumber;
}
// Redirect user to appropriate URL
g_response.sendRedirect(redirectURL);
})(g_request, g_response, g_processor);
Now in your KB article, you must use this processor's URL instead, kb_attachment.do?sysparm_article=KB9310053 as an example based on my settings above.
Then when the user click's the link the processor will check the article's attachment link flag and direct them accordingly.
Please mark this post as helpful or the correct answer to your question if applicable so others viewing may benefit.
