Skip to Content
KM started to serve as an efficient document management system, replacing many of the existing third party document management systems. When clients start to use KM they have varied enhancements and alterations to the KM structure and configuration. Some of the widely discussed configuration issues are presented in this article.

What is it all about ?

Many of my clients interested in incorporating KM in their business wanted it to be customized according to their own needs. Their requirement in nutshell, would be involving administrative users who has uncoltrolled previleges with the KM repository, end user who has restricted previleges to only view documents and if at all they need to communicate with the company they would use the contact us form to submit their query. You can always control a part of these requirements by setting permissions for the user. But there are other things which is not quite straight forward, and has to be done only through a work around. You have to set the context menu according to the permission set, so the end user cannot see options like “copy”, “move”, “delete”, “goto”, “add to portal favorites” and the list can go on. So in this article we would focus our discussion about how to present the KM repository for a business used by end clients.

First step: Creating a KM repository

The first step would be creating a separate KM repository. When you goto KM content in content administration role, you probably see the following structure, image I stripped out some sensitive information. Each of these listing you see namely, ~system, bluserhome, discussiongroups, documents are called repositories. Each of them are being used for different purposes. Some used by the portal itself  like the UME repository (internal repository) which would have all the list of UME details like contacts, groups, roles, users. BIUserHome repository (external repository) is used by external system like BI. So when we want to use KM for our douments, it is good to create a new repository exclusively for our project. Since creating KM repository is not our primary focus and it is a crucial process by itself, im leaving it as of now. Below is a link in help portal that suggest you enough info about repositories.

Second step : Creating content and layout

Now create your own folder structure and put the needed documents there. Now click on the wedge at the end of the folder as seen below, image In the resulting context menu select “details” menu item. This gives you a pop-window where you have a lot of things to work on. The pop-up window will look like this, image Click on the menu item called “Settings”. Then select “Presentation”. Select the layout you want after clicking “select Profile”. In my case I chose Broadcasting layout and then set the other options according to your own preference. image Now you have created the layout for the folder. Save and close the window and get back to the folder to see the new layout.

Third step : creating context menu configuration

Now that we have succesfully had the content in a presentable form, we would have to focus more on security now. The menu items like “give feedback”, “rate the document”, “start disucussion” (about a document) can be hidden when we create the repository. Just don’t select those services so the repository won’t have them. Incase you need them for administrative users and be hidden for another set of end users, then lets go along with the following work aorund.   Now lets goto “System administration” -> “System Configuration”. In the left hand menu select “Knowledge management” -> “Content Management”. In the content area select “User Interface” -> “Commands”. Now you would see three listings, “UI Commands”, “UI Command with Groups”, “UI Commands with Selection”. I will let you know about each of these in the forth coming section. As of now, please select “UI Commands”. image You will then land up in a page similar to the above. Now search for keyword “Delete”. You would get the command called “delete”. Now select it and click on edit. You would get a properties set box at the bottom. In that proerties set, look for a proeperty named “Roles with visibility”. Probably in this case it might be the last one listed. In its corresponding editable value box, enter the administrative roles for which alone it will be visible. The specified role should have the pcd path. For example if you want to specify the content administrator role, then specify “pcd:portal_content/administrator/content_admin/content_admin_role”. Similarly do this for any required role. Save the settings and you can see the changes taking effect immediately. This is the same way we do the configuration changes for other menu items too.

Fourth step : Understanding what to search where

Now that you know how to hide and unhide an option in context menu, you can decide which one of them has to hidden and which one has to disclosed to the user. But in this section I would like to give you an explanation that helps you search for each of the option. Actually this explanation is clearifying what each of the three categories under “Command” are. We already saw those three categories and they are,  ·         UI Commands  ·         UI Command with Groups  ·         UI Commands with Selection image Consider the snapshot above. In the context menu we see some menu items like “new”, “sort by”, “send to”, “go to”, “details”, “add to portal favorites”. Here commands like “add to portal favorites”, “send to”, “details” are one level commands; ie., they don’t have sub command level and they can be executed in the first level itself. Supposing we take the command “New”, it cannot be executed I the first level. It has a sub menu for itself and one of its sub menu (“Forms”) has yet another sub menu. So we would categorize the command “New” as command group. Whereas commands like “details “, ”send to”, “add to portal favorites” are simply UI Commands. Apart from these there are certain commands like “move”, “create link”, “create favorite”, “copy” which require a folder or a document to be selected and then be executed. The commands lile “copy”, “move” are called UI Commands with Selection since they need a selected KM object to be executed. To sum up all,  The commands you are intend to work on might be in either of these three groups namely, “UI Commands”, “UI Command with Groups”, “UI Commands with Selection”.  In order to determine which group your command falls into, first determine if it is just a single level simple command or multi level command enclosing a group of commands. If it is single level and a simple command it has to be in  “UI Commands” category. If it is multi level and enclosing a group of commands then it has to be in “UI Command with Groups”.  Even with some of the single level commands like “move”, “copy” they need a KM object like a folder or document to be selected to be executed. Those fall under the category “UI Commands with Selection”.

Fifth step : Here is my two cents

For command categories like UI Commands and UI Commands with Selection, you can always alter their visibility by sepecifying the roles you want. But when it comes to UI Command with Groups, you gotto find out its comprising commands and go to the constituting commands and edit their their roles of visibility property in order to hide/unhide the whole command groups.   After we do these changes we create a KM Navigation iView and point it to this repository. Then assign it to a user who has the content administrator role and another simple user without administrative previleges. You will see the content displayed with the layout you selected, with previleges you set in the permissions. The context menu remains unchanged in the content administrator role, but is altered in the simple user’s role.  Boom! We made KM an enterprise product that can be used in a business. But this is not it. These are just basic in requirement, but even before going live there are a lot of things to be taken care of. SAP customers make the utmost usage of the KM functionality and KM still withstands that exploit. Every implementation, every customer has different requirement than the other and each one of them wants to give the best to their business. Some to be specified are version controlling (the very important characteristic for any Doc management system), check in / check out (secured work environment where in you edit objects locally), incorporating search through TREX. We would see each of these seperately as each of it demands deep focus as well as deserves its own significance. 

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

Leave a Reply