Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.2
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-3219Move 'return selected' button location on multivalue lookups
      KULRICE-10302Analysis - Results not on the current page are not returned by multivalue lookup's "return selected" action
      KULRICE-124012.4.0 CDT: Multivalue Lookup returned incident report on return selected
      KULRICE-7256Multivalue lookup return not refreshing
      KULRICE-9938Field values for a multivalue lookup aren't returned correctly if lookup results fields are null
      KULRICE-11214MultiValue Lookup - select only on this page and then deselect only on this page the return select button stays clickable.
      KULRICE-9914Hitting certain buttons on a multivalue Lookup Results page after items have been selected results in a stack trace
      KULRICE-10350Determine whether multivalue lookups can be used for EBOs
      KULRICE-3616Return Selected button on multivalue lookup has black border
      KULRICE-6934Lookup does close lightbox when returning results
    • Rice Module:
      KNS
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      The multivalue lookups do not seem to be returning values back to the calling KFS document.

      A KFS developer has went through and has potentially tracked the issue, here are her notes:

      So I traced this problem into org.kuali.rice.kns.lookup.AbstractLookupableHelperServiceImpl.java in the Rice project and there is a method in there which I think is the source of this problem : getReturnInputHtmlData(BusinessObject businessObject, Properties parameters, LookupForm lookupForm, List returnKeys, BusinessObjectRestrictions businessObjectRestrictions).
      Inside this method, it's trying to get the lookupObjectId from the lookupForm to be set as the selectedObjId of each of the object to be returned as search result.
      Here's the line of code :

      String name = KRADConstants.MULTIPLE_VALUE_LOOKUP_SELECTED_OBJ_ID_PARAM_PREFIX + lookupForm.getLookupObjectId();
      
      I think it would work better and would fix this problem if we replace that line with this :
      
      String name = KRADConstants.MULTIPLE_VALUE_LOOKUP_SELECTED_OBJ_ID_PARAM_PREFIX + businessObject.getObjectId();
      

      This looks like a universal problem affecting multiple value lookups

        Issue Links

          Activity

          Hide
          Shannon Hess added a comment - - edited

          I was not able to reproduce using the method on KFSMI-7878 due to another error. However, this is an easy way to re-produce:

          • backdoor as bomiddle
          • open the "Asset Location Global" document
          • click on the "Look Up/Add Multiple Asset Lines" magnifying glass on the "Edit List of Assets" tab
          • hit the search button
          • select various asset lines and select the "return selected" button
          • Nothing is returned to the document at this point
          Show
          Shannon Hess added a comment - - edited I was not able to reproduce using the method on KFSMI-7878 due to another error. However, this is an easy way to re-produce: backdoor as bomiddle open the "Asset Location Global" document click on the "Look Up/Add Multiple Asset Lines" magnifying glass on the "Edit List of Assets" tab hit the search button select various asset lines and select the "return selected" button Nothing is returned to the document at this point
          Hide
          Greg Patterson (Inactive) added a comment -

          The lookupForm's object ID should be getting set previous to this, and should be using the LookupResultsService to do this.

          This essentially inspects the BO to determine what QualifyingSupportStrategy to use. In this case, it should be using the BO's object ID as the KFS developer mentioned, but not in all cases.

          In fact, in this case it is attempting to set the lookupForm objectID to be the same as the passed BO's (Asset for the case Shannon lists), but at the time where it is checked the BO Object ID has not been set yet, resulting in the lookupForm being set to null. The BO object ID must be set later on in the process, because it is by the time we attempt to return values from the page and hit the method noted above (AbstractLookupableHelperServiceImpl#getReturnInputHtmlData)

          Show
          Greg Patterson (Inactive) added a comment - The lookupForm's object ID should be getting set previous to this, and should be using the LookupResultsService to do this. This essentially inspects the BO to determine what QualifyingSupportStrategy to use. In this case, it should be using the BO's object ID as the KFS developer mentioned, but not in all cases. In fact, in this case it is attempting to set the lookupForm objectID to be the same as the passed BO's (Asset for the case Shannon lists), but at the time where it is checked the BO Object ID has not been set yet, resulting in the lookupForm being set to null. The BO object ID must be set later on in the process, because it is by the time we attempt to return values from the page and hit the method noted above (AbstractLookupableHelperServiceImpl#getReturnInputHtmlData)
          Hide
          Greg Patterson (Inactive) added a comment - - edited

          Ah,

          So the reason the business object ID is not coming back properly is because the BO we're looking at in these cases is a new instantiation. For BO's that are EBO's, a new instance is created prior to looking for the object ID.

          public interface CapitalAssetManagementAsset extends ExternalizableBusinessObject {
          
                      BusinessObject element = (BusinessObject) iter.next();
                      BusinessObject baseElement = element;
                      //if ebo, then use base BO to get lookupId and find restrictions
                      if (ExternalizableBusinessObjectUtils.isExternalizableBusinessObject(element.getClass())) {
                          try {
                              baseElement = (BusinessObject)this.getBusinessObjectClass().newInstance();
                          } catch (InstantiationException e) {
                              e.printStackTrace();
                          } catch (IllegalAccessException e) {
                              e.printStackTrace();
                          }
                      }
          
                      final String lookupId = KNSServiceLocator.getLookupResultsService().getLookupId(baseElement);
                      if (lookupId != null) {
                          lookupForm.setLookupObjectId(lookupId);
                      }
          

          If we were to use element (not baseElement), things work out okay as the base BO still has values set on it.
          So, two questions:
          1) Why are EBO's re-instantiated here?
          2) Should the new instance be a copy of the provided BO, at least as far as the baseBO elements go?

          Show
          Greg Patterson (Inactive) added a comment - - edited Ah, So the reason the business object ID is not coming back properly is because the BO we're looking at in these cases is a new instantiation. For BO's that are EBO's, a new instance is created prior to looking for the object ID. public interface CapitalAssetManagementAsset extends ExternalizableBusinessObject { BusinessObject element = (BusinessObject) iter.next(); BusinessObject baseElement = element; // if ebo, then use base BO to get lookupId and find restrictions if (ExternalizableBusinessObjectUtils.isExternalizableBusinessObject(element.getClass())) { try { baseElement = (BusinessObject) this .getBusinessObjectClass().newInstance(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } } final String lookupId = KNSServiceLocator.getLookupResultsService().getLookupId(baseElement); if (lookupId != null ) { lookupForm.setLookupObjectId(lookupId); } If we were to use element (not baseElement), things work out okay as the base BO still has values set on it. So, two questions: 1) Why are EBO's re-instantiated here? 2) Should the new instance be a copy of the provided BO, at least as far as the baseBO elements go?
          Hide
          Greg Patterson (Inactive) added a comment -

          1) This was due to some work done for KULRICE-6919 and running in REMOTE mode
          2) In the future, most likely (from what little I know/have learned)

          Essentially, the fix for this was simply rolling back the changes made in KULRICE-6919 where a BO was "re-instantiated" if it was found to be an EBO. Since EBO's are, now (and again), not their own impl (they are an interface due to the work in KULRICE-7080), this is unnecessary. The problem from the KFS perspective on this issue was that, due to re-instantiation, the necessary object ID was coming back as null, which was breaking the references required for the lookup to work.

          -Greg

          Show
          Greg Patterson (Inactive) added a comment - 1) This was due to some work done for KULRICE-6919 and running in REMOTE mode 2) In the future, most likely (from what little I know/have learned) Essentially, the fix for this was simply rolling back the changes made in KULRICE-6919 where a BO was "re-instantiated" if it was found to be an EBO. Since EBO's are, now (and again), not their own impl (they are an interface due to the work in KULRICE-7080 ), this is unnecessary. The problem from the KFS perspective on this issue was that, due to re-instantiation, the necessary object ID was coming back as null, which was breaking the references required for the lookup to work. -Greg
          Hide
          Greg Patterson (Inactive) added a comment -

          Fix committed, I'm going to go ahead and close this one out. If there are still issues with this after testing feel free to reopen/create as necessary.

          Show
          Greg Patterson (Inactive) added a comment - Fix committed, I'm going to go ahead and close this one out. If there are still issues with this after testing feel free to reopen/create as necessary.

            People

            • Assignee:
              Greg Patterson (Inactive)
              Reporter:
              Dan Lemus (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel