Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major 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
    • Similar issues:
      KULRICE-3375Remove support for "display parameters" in the XML rule attributes
      KULRICE-5925Lookup return functionality is not working when used on Workflow search attributes
      KULRICE-13225Problems with lookup return and easyxdm
      KULRICE-10690Potentially infinite Attribute ID breadcrumbs in Attribute Inquiry
      KULRICE-4755Dynamic Attribute support
      KULRICE-7095Add bread crumbs support between lookup and inquiry
      KULRICE-12911Rule lookup by attributes not working
      KULRICE-7152Selenium tests for Attribute Definition Lookup
      KULRICE-6602PeopleFlow Role lookup not returning
      KULRICE-2100Create new Entity doc enter info on the Global Attributes tab, then go to the next tab Custom Entity Attributes and do a look up, data in the Global Attribute tab disappears
    • 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.

        Activity

        Hide
        Eric Westfall added a comment -

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

        Show
        Eric Westfall added a comment - Bulk update of incomplete 2.0.0-b2 issues to just a 2.0 fix version.
        Hide
        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
        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
        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
        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
        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
        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:
            Shannon Hess
            Reporter:
            Venkat PremChandran (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel