It seems that a rather large challenge for Organizations and Knowledge Management is the open nature of Knowledge Base Categories and users who can Contribute to those Knowledge Bases. Out of the box, anyone with Contribute rights to that Knowledge Base can add or modify Categories as they see fit. Many group do not want this, and this can either cause contention or the complete locking down of all Category Editing. At Acorio, we've come up with a viable solution to restrict Knowledge Base Category editing based on a role, (coupled with CanContribute) which has been attached to this Document.

Here is an explanation of this modification:

First we created a new Role within ServiceNow called "knowledge_category_editor", which will be used to define users with the ability to edit Knowledge Base Categories. It has been kept within the naming scheme of ServiceNow's out of the box roles.

Next we created a new system property called "acorio.knowledge.category.edit.role", which will hold the name of the role(s) that would be required to edit Knowledge Base categories. By default, we've set this property to the role listed above. We've also ensured this System Property is apart of the out of the box "Knowledge Other" Category, so it will appear under the Properties page for Knowledge Management. Lastly, even without specifying them the knowledge_manager and knowledge_admin roles will always be able to edit those categories as normal, whether they are listed in the System Property or not.

We then needed a method for accessing the availability of this role on the Client Side, as the Knowledge v3 uses a specific UI Macro to invoke and create the Category dialogue window. This was done with a simple Display Business Rule, setting a new Scratchpad value (g_scratchpad.cannotEditCategories) to the String of either "True" or "False" depending if the current user has the required role. By design, this will still allow Admins, as they have every role.

Lastly, we took the UI Macro "kb_category_reference_lookup", and renamed it to "kb_category_reference_lookup_original" to ensure there were no collisions with naming and calling it. We then duplicated the UI Macro, returning the new version to the original name. In this new version, we inserted the following code after line 38:

              var disableCategoryEditing = kb_knowledge_base_gr.disable_category_editing;

              if ( disableCategoryEditing == 'false' ) {

                      disableCategoryEditing = g_scratchpad.cannotEditCategories;

              }

The purpose of this code was to rationalize two things. First, we don't care about the new roled function if Category editing has been disabled from a Knowledge Base level. If Category Editing is not disabled, we will then check our new g_scratchpad variable to see if from the roled perspective Category editing should be disabled. We then had to use this new variable, which we do so by replacing the line:

              dialog.setPreference('disable_editing', kb_knowledge_base_gr.disable_category_editing);

with:

              dialog.setPreference('disable_editing', disableCategoryEditing);

And that should do it. As mentioned, I've included the Update Set export and this should function well with out of the box Knowledge Management v3. Of course, every environment is different so please deploy in a sub-prod instance and test before deploying to Production. This is a freely shared set of updates, so while I do not warranty this work, I will help as much as possible within reason. Thanks and hopefully this helps!