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

Person Inquiry not working for external implementations of Identity service. Need to update UiDocumentServiceImpl

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.2
    • Fix Version/s: 1.0.3
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4395addMember via the Role Screen does not work with external identity service
      KULRICE-4001overriding identity service only does not really work
      KULRICE-4840UiDocumentServiceImpl::getMember should not call BO service to get Principals,groups, roles. Use kim services
      KULRICE-3111Person lookups by external identifier do not work when identifier is encrypted
      KULRICE-3760Improve overridability of UiDocumentServiceImpl
      KULRICE-3612Implement a tool that can be used for post data load encryption, have it work better with the KIM external ids
      KULRICE-5087External BO's are not working
      KULRICE-4502Add lookupPrincipals method to Identity Service
      KULRICE-2638Add support for service-level annotations that help to identity the role of a particular service
      KULRICE-4668Evaluate remote KIM services: implementation
    • Rice Module:
      KIM

      Description

      If you have an external implementation of the IdentityService the Person Inquiry does not work.

      The person inquires are powered by UiDocumentServiceImpl::loadEntityToPersonDoc. Here the issues with this method:
      1. it calls getPrincipalImpl(). This method calls the BO service, which breaks external implementations
      2. getEntityImpl. Again, calls the BO Service
      3. protected List<PersonDocumentAffiliation> loadAffiliations(List <KimEntityAffiliationImpl> affiliations, List<KimEntityEmploymentInformationImpl> empInfos)
      – Uses Impl's
      4. protected List<PersonDocumentName> loadNames( IdentityManagementPersonDocument personDoc, String principalId, List <KimEntityNameImpl> names, boolean suppressDisplay ) {
      – Uses Impls
      – calls docName.setEntityNameType(name.getEntityNameType()); // Why do we need a name type? it's not on the KimEntityNameInfo object.
      5. loadEmails
      6. loadPhones
      7. loadAddresses

      I have converted all the impl's to infos so that's not too big of a deal. The problems I had were with the Type objects. EntityNameType and EntityEmailType. The PersonDocumentName and the PersonDocumentName set those type objects.

      Do we actually need them? removed the setting of the type objects and was able to get the Person screens to create/edit/view properly.

      I have attached the patch file and would like some advise on if we need those objects.

        Activity

        Hide
        Garey Taylor added a comment -

        Watchers,
        I've created a patch for this one, but I want to know if we really need to set the Type objects on the PersonDocument objects. Let me know what you think.

        Thanks!

        Show
        Garey Taylor added a comment - Watchers, I've created a patch for this one, but I want to know if we really need to set the Type objects on the PersonDocument objects. Let me know what you think. Thanks!
        Hide
        Jonathan Keller added a comment -

        It's probably used for displaying the labels for the types, but that's all. If you aren't seeing any problems, then it should be OK. If they are needed, then I would do what some of the other "Info" classes do and load them upon demand.

        Show
        Jonathan Keller added a comment - It's probably used for displaying the labels for the types, but that's all. If you aren't seeing any problems, then it should be OK. If they are needed, then I would do what some of the other "Info" classes do and load them upon demand.
        Hide
        Garey Taylor added a comment -

        I've committed my changes to the 1.0.3 branch. With the number of changes needed + altering of protected method definitions I was uncomfortable with committing to the 1.0.2.1 branch. We can still do so, but I need a solid request.

        The patch attached is for 1.0.2.1, but it's missing the fix for the phone and address type castings, so look at the 1.0.3 commit to see the full change set.

        Show
        Garey Taylor added a comment - I've committed my changes to the 1.0.3 branch. With the number of changes needed + altering of protected method definitions I was uncomfortable with committing to the 1.0.2.1 branch. We can still do so, but I need a solid request. The patch attached is for 1.0.2.1, but it's missing the fix for the phone and address type castings, so look at the 1.0.3 commit to see the full change set.

          People

          • Assignee:
            Garey Taylor
            Reporter:
            Garey Taylor
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel