CA Service Management

Expand all | Collapse all

CA TUESDAY TIPS - EDIT KNOWLEDGE FAILS - KNOWLEDGE PERMISSION GROUPS

Paul Coccimiglio09-29-2014 03:00 PM

Christopher Hackett10-01-2014 05:48 PM

  • 1.  CA TUESDAY TIPS - EDIT KNOWLEDGE FAILS - KNOWLEDGE PERMISSION GROUPS

    Posted 09-29-2014 02:54 PM

    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.

     

    TABLE NAMEDESCRIPTION
    SKELETONSStores all the Knowledge documents
    O_INDEXESStores the Knowledge Categories
    P_GROUPSStores the Read and Write Permission id values of the Knowledge documents and Knowledge categories
    CA_CONTACTStores the contact's and group details

     

    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     

    ID

    Read_pgroup

    Write_pgroup

    424293

    401011

    401182

    424295

    401011

    401182

    424476

    401011

    401182

    429791

    401011

    401182

    430232

    401011

    401182

     

      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.


    Id

    401011

    Grp_list_key

    ,E82EC9BBADE411E39E3018853CFC0000

    Grp_list

    ,E82EC9BBADE411E39E3018853CFC0000

     

        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.

     

    Id

    401011

    Grp_list_key

    ,E82EC9BBADE411E39E3018853CFC0000

    Grp_list

    ,E82EC9BBADE411E39E3018853CFC0000

     

     

    Id

    401182

    Grp_list_key

    ,62E9B370014F11E098B498010074F528

    Grp_list

    ,62E9B370014F11E098B498010074F528,

     

    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

     

    ID

    Primary_index

    424293

    408170

    424295

    408170

    424476

    408107

    429791

    408165

    430232

    408107

     

    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)

     

    Id

    Caption

    Read_pgroup

    Write_pgroup

    408107

    Network

    401011

    400454

    408165

    Printer

    401011

    400454

    408170

    Email

    401011

    400454

     

    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



  • 2.  Re: CA TUESDAY TIPS - EDIT KNOWLEDGE FAILS - KNOWLEDGE PERMISSION GROUPS

    Broadcom Employee
    Posted 09-29-2014 03:00 PM

    Great Post



  • 3.  Re: CA TUESDAY TIPS - EDIT KNOWLEDGE FAILS - KNOWLEDGE PERMISSION GROUPS

    Former Employee
    Posted 10-01-2014 05:48 PM

    Thanks for the tip Mohammed!