Knowledge Checkout Button...restrictions? script definition?

matthew_magee1
Giga Guru

Hi all,

We've opened the UI Action 'Checkout' to a group of users based on role. The Checkout button works great if the author or admin clicks it. They get the nice message 'A new version of the article is created for revision'

But...even through I've opened the UI action to users w/ a specific role, when they click the Checkout button, they get the not so good message: 'You cannot checkout this article as it is already checked out'

I've confirmed the article is NOT checked out.

Anyone know what secret magic that allows the author and admin to use the Checkout button correctly?

I've messed with ACL's and no luck there either

Thanks in advance

1 ACCEPTED SOLUTION

Matthew Glenn
Kilo Sage

That error message is terribly ambiguous and misleading. 

There's quite a bit going on behind the scenes when it comes to KB versioning and the checkout process. The Checkout UI Action calls a Script Include named "KBVersioning", which then calls another Script Include named "KBVersioningSNC". Have you reviewed KBVersioningSNC to see if anything stands out? If not....

There are a few functions within it that return false when certain conditions aren't met. A few of the conditions are:

  • User is a KB Owner
  • User is a KB Manager
  • User is member or manager of the group referenced in KB article ownership_group column
  • User has the knowledge_admin role

If false is returned, your UI Action spits out the message you're receiving. 

I'm guessing, without seeing the KB article(s) in question or knowing your environment, one of the aforementioned conditions is the root of your issue. 

Unfortunately, though, since KBVersioningSNC has a protection policy applied to it, you have limited options to get around this check:

  • Override the conditions by adjust KBVersioning
  • Adjust the UI Action script
  • Revert the UI Action to it's original state and utilize the ownership_group column to identify who can checkout/modify each article

Since you've already opened the UI Action to users with a role, if you're set on having a specific group of users be able to checkout articles, you could create a group with that role applied to it, set said group as the default on the ownership_group column if you're not already using it, and patch existing articles by setting that group as the ownership_group with a fix script. This would not only fix your issue, but also ensure that you don't run into issues down the line with skipped updates during your patches.

 

Hopefully this makes sense and helps. If not, or if you find that this isn't the issue, report back and we'll dig deeper

 

View solution in original post

4 REPLIES 4

Matthew Glenn
Kilo Sage

That error message is terribly ambiguous and misleading. 

There's quite a bit going on behind the scenes when it comes to KB versioning and the checkout process. The Checkout UI Action calls a Script Include named "KBVersioning", which then calls another Script Include named "KBVersioningSNC". Have you reviewed KBVersioningSNC to see if anything stands out? If not....

There are a few functions within it that return false when certain conditions aren't met. A few of the conditions are:

  • User is a KB Owner
  • User is a KB Manager
  • User is member or manager of the group referenced in KB article ownership_group column
  • User has the knowledge_admin role

If false is returned, your UI Action spits out the message you're receiving. 

I'm guessing, without seeing the KB article(s) in question or knowing your environment, one of the aforementioned conditions is the root of your issue. 

Unfortunately, though, since KBVersioningSNC has a protection policy applied to it, you have limited options to get around this check:

  • Override the conditions by adjust KBVersioning
  • Adjust the UI Action script
  • Revert the UI Action to it's original state and utilize the ownership_group column to identify who can checkout/modify each article

Since you've already opened the UI Action to users with a role, if you're set on having a specific group of users be able to checkout articles, you could create a group with that role applied to it, set said group as the default on the ownership_group column if you're not already using it, and patch existing articles by setting that group as the ownership_group with a fix script. This would not only fix your issue, but also ensure that you don't run into issues down the line with skipped updates during your patches.

 

Hopefully this makes sense and helps. If not, or if you find that this isn't the issue, report back and we'll dig deeper

 

Great write matthew. Thanks so much. The only thing I don't see (on my London instance) is the ownership_group dictionary you referred to. I dug into the script includes you mentioned and see this for canCheckout:

canCheckout: function(current){
if(this.isExternalArticle(current))
return false;
if(!this._isValidVersion(current))
return false;
if(current.workflow_state!=this.MAJOR_STATE)
return false;
if(!this._knowledgeHelper.canContribute(current))
return false;
if(this._getCheckedoutRecord(current))
return false;
return true;
},

 

I'm not the best at reading code in script includes but I think this says that whoever 'can contribute' has the checkout ability. I tried this out on my instance and it worked beautifully. 

I'm cool w/ this approach but if you have more info on the ownership_group field you mentioned, I'm all ears

 

Thanks!
Matthew

Checkout button won't work if I combine the below condition.

!(new KBCommon().isStackNameDialog()) && (new KBCommon().isVersioningEnabled()) && (new KBVersioning().canCheckout(current)) && gs.getUser().isMemberOf(current.assignment_group)

 

trying to show the button to only members who are in the assignment_group. 

Karina Larson
Kilo Expert

one other thing to understand is the "Can-Contribute" user criteria specified for the Knowledge Base