Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8377

Group KIM Type lookup returning too many results

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4212KIM screens have too many namespace options
      KULRICE-6326Too many entries in the namespace dropdown causes it to be unwieldy
      KULRICE-10400Many of the suggest configurations not returning results
      KULRICE-7487Lookup links on Role document not functioning and appearing in too many places
      KULRICE-3800Security / label checks are performed too many times during lookups
      KULRICE-13248Error on group lookup when searching by KIM type on groups with attributes
      KULRICE-12201Collection Group With Refresh has way too many rows
      KULRICE-7508Attempting to lookup groups by group type Organization Group results in stack trace
      KULRICE-12435Some quickfinder lookups are broken
      KULRICE-11786AFT Failure No values match this search no longer displayed in many tests, DemoLookUpOperatorsAft too, plus commas added to input fields
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Contributing Institution:
      Michigan State Univ

      Description

      A change was made to group creation in 5.0 where it automatically populates a new group as "default" rather than requiring the user to choose between "default" and "KFS-COA: Organization Group".

      When using the magnifying glass to change the group type to an Organization Group the KIM Type lookup screen is returning all 80 KIM Types rather than just those applicable to group creation. This will be a significant issue for end users.

        Issue Links

          Activity

          Hide
          Steve Manning (Inactive) added a comment -

          I've found what I believe to be the root cause of this issue, but am not sure how to proceed as far as a fix is concerned, as there are two possible solutions. First, a little background. The large number of results being returned by the KIM Type Lookup from the Group document is due to a piece of logic never evaluating correctly. In the KimTypeLookuableHelperServiceImpl class the following code:

          if(KimConstants.KimUIConstants.KIM_GROUP_DOCUMENT_SHORT_KEY.equals(fieldValues.get(KRADConstants.DOC_FORM_KEY))) {
            for(KimTypeBo kimTypeBo: searchResults){
              if(hasGroupTypeService(KimTypeBo.to(kimTypeBo))) {
                filteredSearchResults.add(kimTypeBo);
              }
            }
            return filteredSearchResults;
          }
          

          never has the 'if' statement evaluate to "true", which causes the unfiltered search results to be returned to the user. The first way to fix this is to use the DocumentTypeService to retrieve the doctype of the document (the fieldValues map contains the doc id), and if the document is a Group, to return the filter results.

          However, the method containing the chunk of code above also handles the filtering of KIM Type search results for the Role document, and while the logic is almost identical to the Group document, the logic works here. The reason the logic works here is because when a user hits the "Create New" button from the Role lookup screen, they are immediately taken to a KIM Type lookup screen and the fieldValues map is populated with a docFormKey with the value of "IMRD" which then causes the correctly filtered KIM Types to be returned. In contrast, when a user hits the "Create New" button from the Group lookup screen, they are taken to a new Group document, where they have the option of using the KIM Type lookup. When the KIM Type lookup action is taken from the Group document the fieldValues map doesn't have a docFormKey that will result in the 'if' statement evaluating to true. I'd like to know which method ought to be used to fix this issue.

          Show
          Steve Manning (Inactive) added a comment - I've found what I believe to be the root cause of this issue, but am not sure how to proceed as far as a fix is concerned, as there are two possible solutions. First, a little background. The large number of results being returned by the KIM Type Lookup from the Group document is due to a piece of logic never evaluating correctly. In the KimTypeLookuableHelperServiceImpl class the following code: if (KimConstants.KimUIConstants.KIM_GROUP_DOCUMENT_SHORT_KEY.equals(fieldValues.get(KRADConstants.DOC_FORM_KEY))) { for (KimTypeBo kimTypeBo: searchResults){ if (hasGroupTypeService(KimTypeBo.to(kimTypeBo))) { filteredSearchResults.add(kimTypeBo); } } return filteredSearchResults; } never has the 'if' statement evaluate to "true", which causes the unfiltered search results to be returned to the user. The first way to fix this is to use the DocumentTypeService to retrieve the doctype of the document (the fieldValues map contains the doc id), and if the document is a Group, to return the filter results. However, the method containing the chunk of code above also handles the filtering of KIM Type search results for the Role document, and while the logic is almost identical to the Group document, the logic works here. The reason the logic works here is because when a user hits the "Create New" button from the Role lookup screen, they are immediately taken to a KIM Type lookup screen and the fieldValues map is populated with a docFormKey with the value of "IMRD" which then causes the correctly filtered KIM Types to be returned. In contrast, when a user hits the "Create New" button from the Group lookup screen, they are taken to a new Group document, where they have the option of using the KIM Type lookup. When the KIM Type lookup action is taken from the Group document the fieldValues map doesn't have a docFormKey that will result in the 'if' statement evaluating to true. I'd like to know which method ought to be used to fix this issue.
          Hide
          Camille Ash added a comment -

          The fix is working how I had hoped. Thank you. This can be closed.

          Show
          Camille Ash added a comment - The fix is working how I had hoped. Thank you. This can be closed.

            People

            • Assignee:
              Steve Manning (Inactive)
              Reporter:
              Camille Ash
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel