When doing a group search of any kind in which the Additional Search Arguments include the member list parameter "member_list.member IN (U'XXXX') (XXXX is a given contact's UUID), the search result displays all of the groups instead of group membership for the user UUID in question. In addition, several additional blank pages are presented beyond the search result. If no search parameters are included, the search count functions correctly, as does page display.
Display would be such that the web interface claims there are over 500 groups defined, but there are actually about 100 groups. Further, the group membership is not accurately reflected. The given user is meant to be a member of 10 groups, but instead ALL of the groups are listed, which would be construed as an inaccurate group count.
CA Service Desk Manager 11.2 and up
This is a result of the grpmem table being corrupted or erased entirely of content. There is also the potential that contact data was being copied/imported from one install of CA Service Desk over to another install, with only the ca_contact table copied and no other supporting tables.
The grpmem table is a backend table which contains a record of all group memberships. While this table is not usually manipulated directly, it is also inadvisable to alter or tamper with this table in any way. The best way to recover from such a situation is to restore the given table from a backup to re-establish all group member links.
The import of contact data from one install of Service Desk to another through database transfer is unsupported due to the number of supporting tables that are associated in describing a given Contact object. Contact entries in CA Service Desk requires multiple table listings to fully describe a given Contact object and issues such as the one described here are not uncommon as a result of improper table manipulation..