Using the new favourites widget effectively

[Barry_W]

I was really pleased to see the addition of a portal 'favourites list' for knowledge articles, in the Rome release. It's a really useful way for customers to bookmark specific articles, rather than search for them each time.

However, in testing, if you have version control activated, I've noticed if an article is updated, the previous (outdated) version remains in the favourites widget, meaning the hyperlink takes the customer to an old version. The only way to add the new version as a favourite is to navigate to that new version and click on the Star icon, then remove the old one. Very frustrating.

Has anyone found a way to configure this so the widget is updated to show only the latest version? Other widgets (e.g. Most Read) do this OOTB, so I cant understand the logic in this one not doing that. With version control in place, why would you direct customers to old versions?

The only documentation I can find on the subject is pretty brief: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/build/service-portal/task/create-a-...

Thanks in advance for any hints.
Barry.

[Sam Goode]

It seems like the sp_favorite widget (the start button) is pulled into the kb-article-content widget, and when it is clicked, it records the sys_id of the current article in the sp_favorite table. 

Then the sp_favorites widget then constructs and displays items from the sp_favorite table. So it feels like if something were to be changed to make the links point to the latest version of the article, cloning the widget and doing it here would be a good place to do it. 

Around line 21 in the html template you have the bit that populates the link.

<div class="content favorite-content">
  <a aria-label="${Open} {{::fav.short_description}}" ng-href="?id=kb_article&sys_id={{::fav.sys_id}}" class="h4 text-primary m-b-sm block">
    <span ng-if="fav.short_description">{{::fav.short_description}}</span>
  </a>
...

You could try to change this so it points to the article number, which should always load the latest version of the article e.g. 

<a aria-label="${Open} {{::fav.short_description}}" ng-href="?id=kb_article&sysparm_article={{::fav.number}}" class="h4 text-primary m-b-sm block">

However you would need to have access to the article number, either by storing it somewhere in the sp_favorite table in the first place, or by doing a look up in the widget code to fetch it.

[Barry_W]

Thanks Sam, that's really helpful and gives me a good idea on where to start.

[Leri Andrews]

We found this also - very VERY odd behaviour out-of-the-box.  The subscription widget behaves in a similarly peculiar way, as does the 'recent items' widget.  You can end up with a V1 favourite article 6 months out of date, a recent articles widget containing V1, V2 and V3 of the same article and a useless subscription set up alerting you every time V1 is updated (i.e. never).  In building our new portal we managed to iron out these kinks somehow (I'm not sure I'd be able to find out how, sorry) but it added a lot of unexpected development time. 

[Barry_W]

Thanks for the reply Leri. Totally agree. I've also had these issues with subscriptions, and was really hopeful that favourites would solve the problem. We have some huge knowledge bases, with multiple versions of articles, meaning customers have ended up with up to 30+ links to the same article in the widget, one for each version. I don't understand the value in the link not updating to the latest version.