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

Make relationships to Person in KIM from other KRAD apps mostly configuration free

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-8610Make it so that the role qualifiers built in the DocumentTypePermissionService can be configurable by client apps.
      KULRICE-12363Make priority of KIM cache messages configurable
      KULRICE-6399Make configuring the reloading data dictionary easier for client app developers
      KULRICE-2721Add switch on KIM Configurer to make run in local or remote modes
      KULRICE-4147Remove tax ID from KIM person
      KULRICE-3685Kim entity tables missing foreign-key relationships
      KULRICE-12183Configure KRAD sample app on Developer Environment Setup
      KULRICE-6749Configure rice sample app as a client app running against a standalone server
      KULRICE-14090Make improvements to KIM integration performance
      KULRICE-10190Remove personal .sh and other scripts from the codebase
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Right now, in order to do this, you need to add a large amount of configuration in XML to your UIF xml. Person is an EBO, so it seems we should be able to levarage a plain-old-relationship to Person and have the UIF handle rendering of the lookup link and handling of field conversions automagically.

        Activity

        Hide
        Jonathan Keller added a comment -

        Do we have an example of the XML needed at the moment so I know what I will need to replace?

        Show
        Jonathan Keller added a comment - Do we have an example of the XML needed at the moment so I know what I will need to replace?
        Hide
        Eric Westfall added a comment -

        This answer is late in coming, but this is a good question, I think this goes hand in hand with implementing a PersistenceProvider and MetadataProvider that maps down to the PersonService which is a separate jira (KULRICE-9188 I believe). Once we have this, we should just be able to reference a Person on our data object, annotate it appropriately to indicate the relation ship and it should "just work".

        Furthermore, doing this would allow us to get rid of certain "hacks" in the codebase where we are checking for person packages in code that should have no such knowledge. Specifically, see these...we need to get rid of them!

        In AnnotationMetadataProviderImpl:

        			// HACK ALERT!!!!!!!! FIXME: can be removed once Person is annotated for JPA
        			if (f.getType().getName().equals("org.kuali.rice.kim.api.identity.Person")) {
        				referencePkFields = Collections.singletonList("principalId");
        			}
        

        In PrimitiveAttributeDefinition:

                        // Just a temp hack to ignore null Person objects
                        if ((sourcePath != null && !StringUtils.contains(sourcePath, ".principalId"))
                                && (targetPath != null && !StringUtils.contains(targetPath, ".principalId")) ) {
                            String currentValues[] = {"source = " + sourcePath + "' (" + sourceClass + ")",
                                    "target = " + targetPath + "' (" + targetClass + ")"};
                            tracer.createError("Source and target of different types", currentValues);
                        }
        

        In UifDefaultingServiceImpl:

                } else if ( attrDef.getName().endsWith( ".principalName" ) && dataObjectAttribute != null ) {
                    // FIXME: JHK: Yes, I know this is a *HORRIBLE* hack - but the alternative
                    // would look even more "hacky" and error-prone
                    c = ComponentFactory.getUserControl();
                    // Need to find the relationship information
                    // get the relationship ID by removing .principalName from the attribute name
                    String relationshipName = StringUtils.removeEnd(attrDef.getName(), ".principalName");
           ....
        

        There may be others as well, but I think these are some of the most egregious.

        Show
        Eric Westfall added a comment - This answer is late in coming, but this is a good question, I think this goes hand in hand with implementing a PersistenceProvider and MetadataProvider that maps down to the PersonService which is a separate jira ( KULRICE-9188 I believe). Once we have this, we should just be able to reference a Person on our data object, annotate it appropriately to indicate the relation ship and it should "just work". Furthermore, doing this would allow us to get rid of certain "hacks" in the codebase where we are checking for person packages in code that should have no such knowledge. Specifically, see these...we need to get rid of them! In AnnotationMetadataProviderImpl: // HACK ALERT!!!!!!!! FIXME: can be removed once Person is annotated for JPA if (f.getType().getName().equals( "org.kuali.rice.kim.api.identity.Person" )) { referencePkFields = Collections.singletonList( "principalId" ); } In PrimitiveAttributeDefinition: // Just a temp hack to ignore null Person objects if ((sourcePath != null && !StringUtils.contains(sourcePath, ".principalId" )) && (targetPath != null && !StringUtils.contains(targetPath, ".principalId" )) ) { String currentValues[] = { "source = " + sourcePath + "' (" + sourceClass + ")" , "target = " + targetPath + "' (" + targetClass + ")" }; tracer.createError( "Source and target of different types" , currentValues); } In UifDefaultingServiceImpl: } else if ( attrDef.getName().endsWith( ".principalName" ) && dataObjectAttribute != null ) { // FIXME: JHK: Yes, I know this is a *HORRIBLE* hack - but the alternative // would look even more "hacky" and error-prone c = ComponentFactory.getUserControl(); // Need to find the relationship information // get the relationship ID by removing .principalName from the attribute name String relationshipName = StringUtils.removeEnd(attrDef.getName(), ".principalName" ); .... There may be others as well, but I think these are some of the most egregious.

          People

          • Assignee:
            Jonathan Keller
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 1 day, 4 hours
              1d 4h
              Remaining:
              Remaining Estimate - 1 day, 4 hours
              1d 4h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Structure Helper Panel