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

Should consider if a principal should be allowed to have a null principal name


    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-4213Allow principal names in Kim screens instead of only principal Ids
      KULRICE-4283IdentityServiceImpl methods convert principal name to lower case before going to the persistence layer but Person maintenance allows upper case principal names.
      KULRICE-7556DocumentSearchCriteria should support principal ids, right now it only supports specifying principal names
      KULRICE-8507IdentityCurrentAndArchivedServiceImpl.getPrincipals returns a null list if one of the principals is not found for the list of principalsIds passed in.
      KULRICE-2996Allow for kim principal names to be case insensitive without requring principal name to be stored all lowercase in KRIM_PRNCPL_T
      KULRICE-9646IdentityServiceImpl.updatePrincipal should retrieve the original principal by ID instead of name
      KULRICE-4229Principal Id/Name discrepancy on System notifications
      KULRICE-12349Person lookup does not return row if principal name is inactive or not present (unless no is selected for active ind)
      KULRICE-12344Issue with IdentityArchiveServiceImpl when entity does not have principal
      KULRICE-8186if principal name is null the Initiator name on doc search results can be incorrect
    • Rice Module:
    • KAI Review Status:
      Review Completed
    • KTI Review Status:
      Pending Review


      I think it's a legitimate case that you may have a principal that has a unique id but that doesn't have a principal name. I think this could occur for multiple cases:

      1. The principal is new and has not yet been assigned a principal name
      2. The principal has left the unversity and their principal name has been decomissioned or reassigned
      3. The principal represents some kind of system-level account which doesn't necessarily have or need credentials

      I'm sure there are other reasons but those are the main ones I can think of.

      Additionally, our KRIM_ENTITY_CACHE_T table currently allows principal names to be null (possibly for reasons similar to what I mentioned above). We had an issue here at IU that when we try to load KEW documents that are historical and their principal no longer had a principal name, we would get exceptions from the code that translated the princpals up to Principal objects because a null principal name was not allowed. We modified the code set the princpal name as "undefined" in this case but that sounds like a bad hack to me. It might make more sense to allow for prinpical names to be null.

      If it is decided to do this, some thought would need to be put in to determine how best to do this in a backward compatible way. For example, for an older client pulling back principal records through the KIM api, we may need to pass back "undefined" or "null" or something similar in those cases.

        Issue Links


          Matt Sargent added a comment -

          Per the KAI: Null principal name should have “unknown (principal ID)” propagated to the DB

          Matt Sargent added a comment - Per the KAI: Null principal name should have “unknown (principal ID)” propagated to the DB
          Corey Pedersen (Inactive) added a comment -

          Returned to backlog per gilesp.

          Corey Pedersen (Inactive) added a comment - Returned to backlog per gilesp.


            • Assignee:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created:

                Structure Helper Panel