Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0-m1, 2.3
    • Component/s: Development, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Lookup
    • Application Requirement:
      Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      For GroupBo (Group.xml), we have a relationship set for kimTypeInfo with kimTypeId as primitive and kimTypeInfo.name and kimTypeInfo.namespaceCode as support attributes (both identifier="true") But the return url has only id, missing name and namespacecode. Per Jerry, support attributes should be returned back.

      It looks like QuickFinder.getRelationshipForField() calls DataObjectMetaDataService().getDataObjectRelationship() with keysonly=true, which is causing the issue.

        Attachments

          Activity

          Hide
          ewestfal Eric Westfall added a comment -

          Bulk update of incomplete 2.0.0-b2 issues to just a 2.0 fix version.

          Show
          ewestfal Eric Westfall added a comment - Bulk update of incomplete 2.0.0-b2 issues to just a 2.0 fix version.
          Hide
          shahess Shannon Hess added a comment -

          Venkat,

          I'm trying to reproduce this issue using the current KIM group screen by taking the following steps:

          The return value URL for the Kuali kim type is http://env1.rice.kuali.org/kim/identityManagementGroupDocument.do?refreshCaller=kimTypeLookupableHelperServiceImpl&methodToCall=refresh&docFormKey=3&id=1 so I'm seeing the issue where only the id is passed back, but this is how it also worked in past versions of Kuali (I checked 1.0.3)

          However, the code mentioned above ( QuickFinder.getRelationshipForField() calls DataObjectMetaDataService().getDataObjectRelationship()) is never hit for this situation. Since this is a KNS screen, KimTypeLookupableHelperServiceImpl.getReturnHref is the method that determines the return value url, and it is passed only id for the return keys

          Call chain to get the return key, which ends up just being id in this situation.

          AbstractLookupableHelperServiceImpl.performLookup -->
          AbstractLookupableHelperServiceImpl.getReturnKeys -->
          DataObjectMetaDataServiceImpl.listPrimaryKeyFieldNames

          I've tested another screen, such as the document type screen and it looks good.

          example -

              <property name="relationships">
                <list>
                  <bean parent="RelationshipDefinition">
                    <property name="objectAttributeName" value="parentDocType"/>
                    <property name="primitiveAttributes">
                      <list>
                        <bean parent="PrimitiveAttributeDefinition" p:sourceName="docTypeParentId" p:targetName="documentTypeId"/>
                      </list>
                    </property>
                    <property name="supportAttributes">
                      <list>
                        <bean parent="SupportAttributeDefinition" p:identifier="true" p:sourceName="parentDocType.name" p:targetName="name"/>
                      </list>
                    </property>
                  </bean>
                </list>
              </property>
          

          URL includes supportAttributes - http://localhost:8080/kr-dev/kr/lookup.do?docTypeParentId=2997&refreshCaller=docTypeLookupable&parentDocType.name=IdentityManagementPersonDocument&methodToCall=refresh&docFormKey=16&anchor=topOfForm&docNum=

          Do you have a situation where you are using the GroupBo (Group.xml) and it is actually hitting the QuickFinder.getRelationshipForField() code?

          Thanks,
          Shannon

          Show
          shahess Shannon Hess added a comment - Venkat, I'm trying to reproduce this issue using the current KIM group screen by taking the following steps: go to the group lookup http://env1.rice.kuali.org/portal.do?channelTitle=Group&channelUrl=http://env1.rice.kuali.org/kr/lookup.do?methodToCall=start&businessObjectClassName=org.kuali.rice.kim.impl.group.GroupBo&docFormKey=88888888&returnLocation=http://env1.rice.kuali.org/portal.do&hideReturnLink=true select the create new button Select the type name lookup push enter The return value URL for the Kuali kim type is http://env1.rice.kuali.org/kim/identityManagementGroupDocument.do?refreshCaller=kimTypeLookupableHelperServiceImpl&methodToCall=refresh&docFormKey=3&id=1 so I'm seeing the issue where only the id is passed back, but this is how it also worked in past versions of Kuali (I checked 1.0.3) However, the code mentioned above ( QuickFinder.getRelationshipForField() calls DataObjectMetaDataService().getDataObjectRelationship()) is never hit for this situation. Since this is a KNS screen, KimTypeLookupableHelperServiceImpl.getReturnHref is the method that determines the return value url, and it is passed only id for the return keys Call chain to get the return key, which ends up just being id in this situation. AbstractLookupableHelperServiceImpl.performLookup --> AbstractLookupableHelperServiceImpl.getReturnKeys --> DataObjectMetaDataServiceImpl.listPrimaryKeyFieldNames I've tested another screen, such as the document type screen and it looks good. example - <property name= "relationships" > <list> <bean parent= "RelationshipDefinition" > <property name= "objectAttributeName" value= "parentDocType" /> <property name= "primitiveAttributes" > <list> <bean parent= "PrimitiveAttributeDefinition" p:sourceName= "docTypeParentId" p:targetName= "documentTypeId" /> </list> </property> <property name= "supportAttributes" > <list> <bean parent= "SupportAttributeDefinition" p:identifier= " true " p:sourceName= "parentDocType.name" p:targetName= "name" /> </list> </property> </bean> </list> </property> URL includes supportAttributes - http://localhost:8080/kr-dev/kr/lookup.do?docTypeParentId=2997&refreshCaller=docTypeLookupable&parentDocType.name=IdentityManagementPersonDocument&methodToCall=refresh&docFormKey=16&anchor=topOfForm&docNum= Do you have a situation where you are using the GroupBo (Group.xml) and it is actually hitting the QuickFinder.getRelationshipForField() code? Thanks, Shannon
          Hide
          vpremcha Venkat PremChandran (Inactive) added a comment -

          Sorry, this was an issue with KRAD implementation (not with KNS). I think we need to check how KRAD handles the supporting attributes. As we created this jira nearly 2 years ago, this might be working in krad now.

          Show
          vpremcha Venkat PremChandran (Inactive) added a comment - Sorry, this was an issue with KRAD implementation (not with KNS). I think we need to check how KRAD handles the supporting attributes. As we created this jira nearly 2 years ago, this might be working in krad now.
          Hide
          shahess Shannon Hess added a comment - - edited

          This appears to be work working in KRAD now so I'm going to close this issue. Here is an example of the URL that is created for the relationship below, which has two supporting attributes - person.name and memberName.

          return url -

          http://localhost:8080/kr-dev/kr-krad/peopleFlowMaintenance?newCollectionLines['document.newMaintainableObject.dataObject.members'].memberId=erin&newCollectionLines['document.newMaintainableObject.dataObject.members'].person.name=Employee%2C+Erin&refreshCaller=PersonImpl-LookupView&newCollectionLines['document.newMaintainableObject.dataObject.members'].memberName=erin&methodToCall=refresh&formKey=94facc85-88f6-4a72-b589-11870f88b225&refreshDataObjectClass=org.kuali.rice.kim.impl.identity.PersonImpl
          
                <bean parent="RelationshipDefinition" p:objectAttributeName="person">
                    <property name="primitiveAttributes">
                      <list>
                        <bean parent="PrimitiveAttributeDefinition" p:sourceName="memberId"
                              p:targetName="principalId"/>
                      </list>
                    </property>
                    <property name="supportAttributes">
                      <list>
                        <bean parent="SupportAttributeDefinition" p:identifier="true"
                              p:sourceName="memberName" p:targetName="principalName"/>
                        <bean parent="SupportAttributeDefinition" p:sourceName="person.name"
                              p:targetName="name"/>
                      </list>
                    </property>
                  </bean>
          

          Thanks,
          Shannon

          Show
          shahess Shannon Hess added a comment - - edited This appears to be work working in KRAD now so I'm going to close this issue. Here is an example of the URL that is created for the relationship below, which has two supporting attributes - person.name and memberName. return url - http: //localhost:8080/kr-dev/kr-krad/peopleFlowMaintenance?newCollectionLines['document.newMaintainableObject.dataObject.members'].memberId=erin&newCollectionLines['document.newMaintainableObject.dataObject.members'].person.name=Employee%2C+Erin&refreshCaller=PersonImpl-LookupView&newCollectionLines['document.newMaintainableObject.dataObject.members'].memberName=erin&methodToCall=refresh&formKey=94facc85-88f6-4a72-b589-11870f88b225&refreshDataObjectClass=org.kuali.rice.kim.impl.identity.PersonImpl <bean parent= "RelationshipDefinition" p:objectAttributeName= "person" > <property name= "primitiveAttributes" > <list> <bean parent= "PrimitiveAttributeDefinition" p:sourceName= "memberId" p:targetName= "principalId" /> </list> </property> <property name= "supportAttributes" > <list> <bean parent= "SupportAttributeDefinition" p:identifier= " true " p:sourceName= "memberName" p:targetName= "principalName" /> <bean parent= "SupportAttributeDefinition" p:sourceName= "person.name" p:targetName= "name" /> </list> </property> </bean> Thanks, Shannon

            People

            • Assignee:
              shahess Shannon Hess
              Reporter:
              vpremcha Venkat PremChandran (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: