"Attachment Link" in KB article no longer automatically opening attachment (after Istanbul upgrade)

[kc99]

Hi,

we moved to Istanbul earlier this week and (despite end user testing) nobody spotted that that the KB attachments on one of our CMS portals were not opening automatically as happened in Fuji.

Instead, the article itself is opening on the page and the customer has to then click the attachment link in the displayed article to open any attachments.

This only appears to be a problem in our V2 knowledge base - we have several V3 KBs and these aren't affected.

As a workaround we have set the 'Display Attachments' on each V2 KB article so, at least, the customer can see the link on each KB article affected.

Does anyone have an idea why this may be happening?

Hope you can help,

thanks,

Keiron.

[miguelagarcia]

Hello,

This issue is still happening in Jakarta Patch3.

I've had to workaround it by linking the Attachment instead which is not desirable in the long term.

I'm not sure if not many people use that functionality or it is only failing in some cases: anyone who has this working Out of the Box in Jakarta?

Kind regards,

Miguel A. Garcia.

[Eric Viets]

I'm wondering if the Attachment Link and Display Attachments checkboxes only pertain to Knowledge v2, not Knowledge v3 (and should therefore be removed from the forms for those who have upgraded to Knowledge v3).   I'm saying that because I very recently was made the process owner for Knowledge Management for the university at which I work and the Topic and (old) Category fields are still on the form (even though when we went to Fuji, that should have been dealt with...   we're now on Istanbul, upgrading to Jakarta).   So, if those old fields remain, perhaps the Attachment Link and Display Attachments checkboxes are old vestiges too.

For what it's worth, I actually much prefer users (who have the ability to write/edit articles) to be able to attach images to the article.   It is much better than attaching images to the database (where all articles use the same file of the same file name - so, if one is overwritten, then that overwritten file image is displayed everywhere the previous image was used).   It's much better to constrain to the single article, in my opinion.

*Edit: So, in further testing (testing in Jakarta), I finally figured out what the Attachment Link box does.   When a person searches for an article in the KB article search, if "Attachment Link" is checked, the article will *not* open; but, instead, the attachment linked to the article will automatically download to the user's computer. It's a little confusing at the beginning because the article doesn't open, and you're not instantly sure why that is. (It may be helpful to indicate in the article's Description a "[Download]" prefix to alert users to expect a download instead of an article opening.)   I think for us, I'm going to remove that option from the form (and thus, turn off the ability to use it).   (Anyone else have a really good reason to keep it?   Does it confuse your users when the article doesn't open?)

**Edit: And "Display Attachments" displays links to each attachment in order for the attachment(s) to be available for easy download at the bottom of the article.   So, I think these features are alive and well as intended (in Jakarta -- and, perhaps, not as understood or hoped for).   For us, we'll be keeping the Display Attachments and removing the Attachment Link checkbox to reduce confusion (one user thought that was how he was supposed to attach a file to the article).

[Shane J]

We're still in Helsinki but the same thing occurs for us.   In fact, I'm not sure I ever saw attachments auto-open when bringing up a KB article.   We are nto yet big KB users but I did move us to V3.

Does anyone have more info on this?

[HugoFirst]

I found Eric Viets' post quite informative, and it explains a lot of the difficulty I ran into.

The checkboxes are labeled exactly opposite of what I would use.

"attachment link"  does NOT show a link to the attachments, but rather displays the (first) attachment as a surrogate to the article.

"display attachments"  does NOT display the attachments, but rather displays (a) link(s) to the attachments.

So far, I'm just parroting Eric's advice.

Here's my additional info:  Over time the URL to that KB article will change and any links to that article will break.

Here's why:
Suppose you have a KB article with an attachment and the  checkbox for "display attachments" is checked.  In other words, you want users to see the attachment and not the text in the KB article.

Now let's further suppose that you want to link to this article from another article or web page.  So you:
    1. display KB Homepage, find the link to the article and right-click -> Copy Link Address to get the URL.
    2. then paste that URL into another article or webpage.

So far so good. The link in the other article works fine.

Next, there comes a time where you need to revise the KB article.  So you download the attachment, revise it, and attach the revised file to the KB article.  To keep things up to date, you delete the (now obsolete) attachment. 

This action will change the URL.  Now any link to the KB article created prior to the new attachment will break.