Which database table contains KB permalink information?

[ibt]

Which database table contains KB permalink information?

[Goran WitchDoc]

to view articles it uses the ui page kb_view.

í�f you look at the code there you can find var permalink = kbViewModel.permalink;

Looking into script include you find KBViewModel and that only extends to KBViewModelSNC which is read only. But in that you find the method "permalink".

And in the end you can se it creates a URL from this (gs.getProperty("glide.servlet.uri") + "kb_view.do?sysparm_article=" + number);

so the permalink isn't stored anywhere

Hope this answers your questions.

//Göran

[StephLindorff]

Just to make sure I understand - are you looking for the ability to track cross-linked articles?

One of the things I've always felt should be Out Of The Box functionality for knowledge was the ability to manager intra-article links - report on articles with links to other articles that no longer exist etc.

How are other people managing this need?

[ibt]

Hi Stephanie,
Yes. We have a Knowledge Base. People write useful articles that nobody looks at. Sometimes several people write the same article over the years because they could not find the other articles. EXAMPLE: my company has 3 articles written about 18 months apart that all are supposed to be the "Overview" for a major application. All of them are out of date. What I want to do is to create an "Overview" article for each application and "pin" it to the top of the KB search using the application name as the "keyword". Like "Outlook" being the application. The "keyword" is "Outlook" so the "Outlook Overview" KB would come up first in a search. The Overview is a high level view of what the application does. It then contains meaningful links to ALL of the other KB articles that have anything to do with Outlook: user "how to" documents; Help Desk "before you call MS support, try this" documents and "after you have tried everything, who do you call" documents. An outline of what I am developing is below. My goals:

· Have a starting point for every application so that new people know where to look and can then "follow the bread crumbs" to an answer.
· By having links to ALL related articles, people can know that they have finished a search. There are not many things as frustrating as looking for something that does not exist (I think this a major reason why users do not even bother to try searching for an answer. It is easier to just call the Help Desk).
· By using the "keyword" and Overview article, KB writers are not competing to have their article come up first by using stacked meta or the ts_weight process (and since everybody believes that their article is more important than anybody else's…).
· The KB Admin controls the Overview articles. Any new article would have to fit into one of the existing Overviews before it could be published (or a new Overview would be created).
o But, the authors could still update their articles as the application changed over time.
My problem is that when a KB is retired, the link still works. In other words, you can "link" into a retired KB article that does not show up in a search.
The only thing I know right now is that the KB Link is stored in the "Text" field of the KB (Knowledge kb_knowledge table). The text:
How do I reset my password? KB0012994
In the article where the "permalink" is attached to "KB0012994" (user clicks on KB0012994 to open that KB. It is set to open in another window (Target: New window (_blank)) in case it is not the correct article. That way, the user simply closes the new window and still has the Overview KB open and can click on the next promising link) It is stored in the database as:

How do I reset my password?   KB0012994 </li>
What I am working on:

· Determining if the link in an article is still pointing to a "Published" KB.
· Searching for a repeatable process to determine if all non-Overview articles have links in an Overview article (no orphans).
o What I hope to do is write a Scheduled Report that would detect both "dead" links and "orphan" articles.



APPLICATION NAME - Overview


This document is the standard UHO "READ ME FIRST" KnowledgeBase(KB) article. The main purpose of this document is to simplify a user's search for specific information without having to be completely familiar with the search algorithms in ServiceNow. Each user application should have an "Overview" KB article that is displayed at the top of the search results list based on the name of the application attached to the article as a "keyword". EXAMPLES: XXXXX; YYYYY; ZZZZZZ. As users become more familiar with searching, they can tailor a search for specific results and bypass the "Overview" article. However, both new and experienced users will find the "Overview" helpful at times.


The Overview is divided into the following sections:
· ABOUT: description of the application; links to user instructions.
· USER FAQs: link to article for "Frequently Asked Questions".
· KNOWN ISSUES: link to article describing known issues and how to resolve.
· HELP DESK: link to article for 1st Level Support. Remediation tasks to be performed before escalation.
· ESCALATION: link to article for 2nd Level Support. For issues the Help Desk cannot fix.


(NOTE: this "Overview text should remain in the KB)


ABOUT


APPLICATION NAME is used by USER DEPARTMENT to:


· FUNCTION — short description and link to KB
· FUNCTION — short description and link to KB


Access Method: This web application is used in the local desktop environment.
Authentication: Standalone credentials are required to access this application


USER FAQs


KNOWN ISSUES


HELP DESK


· Description of the issue (including the EXACT error message). This is the mandatory ticket information to be included as well as the preferred categorization.


· Category: CATEGORY Subcategory: SUBCATEGORY Configuration Item: CONFIGURATION ITEM
· Incident Information:
o How many customers are impacted
o Workstation Hostname
o Office/Cube Location
o Troubleshooting steps performed to resolve issue


ESCALATION


After performing all documented remediation steps in the Known Issues and Help Desk sections, check the On-Call Calendar for GROUP NAME and contact the On-Call personnel according to the schedule.

[Lloydo]

I run a report of all "live" KBAs and import this into Excel, including the complete Solution and Internal Solution fields. Excel runs a macro of all of this to detect all internal and external URLs embedded and then launches each URL to test for 404 errors (and a couple other possibilities). We have about 4500 KBAs, of which 3000 have a total of 12,000 embedded links. I know that we have about 90% known to be working, 3% known to be broken and 7% needing manual testing to confirm either way.

The following caveats apply:

- just because a link "works" doesn't mean it goes to the intended content - some sites redirect to an error or 'catchall' page rather than show a pure 404 error...so a small portion of 'known good' links may in fact still be bad.

- mailto and file download links are placed into the 'undetermined' list for manual testing.

When I first started writing and running the macro, it was taking 8+ hours to process about 3,000 KBAs. Through improvement I have got this down to about 30 minutes (with the total now being 3,200 KBAs). This was achieved through the macro adding to and maintaining a list of 'known good' URLs, and testing presence in this list before trying to launch it...the greatest amount of time spent is in the launching and status check of each URL.