I got a requirement to adjust the visibility of the "Edit" button on Knowledge articles

Arindam Ghosh
Mega Guru

Detail requirement is as below:

The "Edit" button in a knowledge article should only be available to those users, who:

a. Are the author of the respective Knowledge article, OR

b. Are part of the Assignment Group of the Configuration Item used for creating the Knowledge article

----------------------------------------------------------------------------------

While analyzing this I found that in "kb_view_common_header_toolbar" UI Macro the below condition is coded for 'Edit' button.

<j:if test="${showUpdateAction}">

<button id="editArticle" title="${gs.getMessage('Edit content')}" class="btn btn-default navbar-btn snc-article-header-toolbar-button">${gs.getMessage("Edit")}</button>

</j:if>

Here variable showUpdateAction is being set in another UI Macro "kb_view_common"

After that I am lost. Not exactly able to understand how and where the conditions are written and how can I modify to implement my requirements.

Any help is greatly appreciated. Thanks in advance.

1 ACCEPTED SOLUTION

Your question got me to rethink my answer.



I tought instead of doing all these scripts override which are global and override OOTB stuff, you can simply create a scripted user criteria and apply it as the only user criteria for the required knowledge bases. However, these user criteria are somehow cached in the user session, so for example: a user is the author of an article, he changes the author to someone else so that he should no longer have write access, however he keeps the write access because of a weird caching with user criteria. I conclude that user criteria should not be used to be dynamic with the record.



However, your point about the canContribute method is good, you could in fact make this simpler by overriding the canContribute method that is defined in KBCommon. And remove the previous overriding I proposed:



var KBCommon = Class.create();


KBCommon.prototype = Object.extendsObject(KBCommonSNC, {


      initialize: function(){


              this._knowledgeHelper = new SNC.KnowledgeHelper();


              this._knowledgeHelper.canContribute = function(knowledgeGR){


                      var defaultContribute = new SNC.KnowledgeHelper().canContribute(knowledgeGR);


                      if(!defaultContribute){


                              return false;


                      }


                     


                      var isAdmin = gs.hasRole('admin');


                      if(isAdmin){


                              return true;


                      }


                     


                      var isKnowledgeBase = knowledgeGR.getRecordClassName() == 'kb_knowledge_base';


                      if(isKnowledgeBase){


                              return true;


                      }


                     


                      var isAuthor = knowledgeGR.author == gs.getUserID();


                      if(isAuthor){


                              return true;


                      }


                     


                      var isMemberOfCIGroup = gs.getUser().isMemberOf(knowledgeGR.cmdb_ci.support_group);


                      if(isMemberOfCIGroup){


                              return true;


                      }


                     


                      return false;


              };


      },


     


      type: 'KBCommon'


});


View solution in original post

25 REPLIES 25

HI @LaurentChicoine 

 

I want to simply hide the button. Could you please help me with my community question .

 

Thanks!

Ramkumar

 

staceybailey
ServiceNow Employee
ServiceNow Employee

laurentchicoine and arindamghosh.net,


Given the ability to apply user criteria at the article level in Jakarta, could you also set that with a scripted user criteria there? I would think that should not be cached from article to article.


Good point Stacey,



I haven't tried that, but your right at the article level should be able to work, but it would require a business rule automatically adding the user criteria to each articles. arindamghosh.net you might want to try that once you'll upgrade to Jakarta.


Larrent,



I think we should just be able to use the Set default knowledge field values field on the kb_knowledge_base form to set it automatically for new articles. . . at least for new ones.



find_real_file.png


Edited to add: These fields must be displayed on the Knowledge article form for these values to be set properly.   By default, Can Read and Cannot Read are not on the form layout.   Then, it works. . . at least to set the article-specific user criteria.   (I didn't write a scripted user criteria to match the original question's requirement.)


Yep Laurent, I will try this once our version upgraded to Jakarta.