CA Service Management

Most of them working on Knowledge Documents may have run into a situation wherein you try to edit a Knowledge document, the Hour glass keeps spinning and spinning and results in either a CGI Timeout Error or Cannot connect to webengine Errors. You logout or close the browser and login. You can still search and view that document again but EDIT just does not work.

REASON: This problem is generally associated with the Knowledge Read and Write Permissions missing for that document or the Knowledge category to which the document belongs. Below is a detailed explanation on how this actually works.

Below table will list the table names that we will be dealing with during the course of troubleshooting the problems with Permission groups.

1. The knowledge permissions of a document are controlled by the "read_pgroup" and "write_pgroup" column values of the SKELETONS Table. SKELETONS table is the table that stores all the knowledge documents.
2. Let us consider a case where the user complains they are unable to edit certain knowledge documents. For e.g. The ids of these documents are 424293, 424295, 424476, 429791, 430232, 431799. They may belong to different Knowledge categories.
3. We will first run a SQL query in SQL management studio to get the read_pgroup and write_pgroup ids from the SKELETONS table.                                                                                                                  select ID,read_pgroup,write_pgroup from skeletons where id in (424293, 424295, 424476, 429791, 430232, 431799 )
4. This will return     

  5.    If we take a look at the above output, all the read_pgroup values point to 401011 and write_pgroup values point to 401182.

  6.    These read_pgroup and write_pgroup ids are referencing/pointing to the id column value of the  p_group table.(Knowledge Permission Groups Table).

  7.    We will now run SQL Query on the p_group table to check if these read and write ids exist.

        select * from p_groups where id in (401011,401182).

          This returns only 1 row as below. That indicates the read_pgroup id exists but the write_pgroup id is missing.

    8.    As the write_pgroup id is missing the write permissions of the document will not be available as a result of which users will not be able to edit the document.

    9.    There could be an another possibility. Both the read_pgroup and write_pgroup ids will be existing in the p_groups table as shown below. Both of them have columns Grp_list_key and Grp_list. These store the contact_uuid's of the Groups that have permissions.

But the contact_uuids that are mentioned in the Grp_list_key and the Grp_list columns of the p_groups table that are referencing to the contact_uuids of the ca_contact table will not be existing in the ca_contact table. You can run the below SQL Query to determine whether the contact exists in the ca_contact table

select userid,last_name from ca_contact where contact_uuid in (0xE82EC9BBADE411E39E3018853CFC0000,0x62E9B370014F11E098B498010074F528)

Note: You need to add a prefix of "0x" to the Grp_list_key and Grp_list column values.

If this Query returns 0 records that indicates that the Contact Group record itself is missing. This indicates that the contact groups which have write permissions actually do not exist in the ca_contacts table

10.      We discussed 2 possibilities above. The 3rd possibility could be that the Knowledge permissions on the Knowledge categories are missing.

11.      The category id is stored in the primary_index column of the skeletons table.

12.      Run the below SQL Query to determine the Knowledge category

              select id,primary_index from skeletons

13.    Then run the below query on the knowledge categories table (O_INDEXES) to check the details of the category ids returned

          select id,caption,read_pgroup,write_pgroup from o_indexes where id in (408170,408107,408165,408107)

14.      Run a query on the p_groups table to check the permission groups set on the above Knowledge categories

          select * from p_groups where id in (400454,401011)

In case this returns 0 records that indicates that the permission ids for the above categories are missing.

STEPS TO FIX THIS PROBLEM

1.    In order to fix this we will first have to set READ and WRITE PERMISSIONS to EVERYONE.

2.      We will extract the problematic Knowledge Documents from the SKELETONS Table and Problematic Knowledge categories from the O_INDEXES table.

          pdm_extract -f "select id,READ_PGROUP,WRITE_PGROUP from SKELETONS where id in (424293, 424295, 424476, 429791, 430232, 431799)" > oldkd.txt

          pdm_extract -f “select id,READ_PGROUP,WRITE_PGROUP from O_INDEXES where id in (408107,408165,408170)” > oldcat.txt

3.    Open the oldkd.txt in a notepad and change the all the READ_PGROUP & WRITE_PGROUP values  to 0. Save the file as kd_new.txt

4.    Similarly open the oldcat.txt in a notepad and change all the READ_PGROUP & WRITE_PGROUP values  to 0. Save the file as cat_new.txt

5.    From the command prompt of the server run the commands

Pdm_userload –f kd_new.txt

Pdm_userload –f cat_new.txt

6.      Ideally reloading the files should resolve the problem. In case if it does not then Restart all the primary and secondary (if any) servicedesk services in the order Stop Primary -> Stop secondary -> Start              secondary -> Start Primary

7.      Once you are able to edit the document, you will have to reset the READ and WRITE permissions of the above categories by selecting new groups from the list in the ServiceDesk Web Interface.

IMPORTANT NOTE:

As this involves changes to the data, take a backup of the database before performing these steps.

Hope this helps everyone who come across problems with Knowledge document editing. Feel free to contact me in case you need any further explanations on this.

Regards

Nas

Great Post

Thanks for the tip Mohammed!