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

KIM Attributes are referenced by a non-unique identifier

    Details

    • Type: Bug Fix Bug Fix
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-7372Relax validation on non-editable identifiers in KIM
      KULRICE-3411Remove constant referencing "WorkflowAdmin" in KEWConstants
      KULRICE-2633KEN classes should not be referencing KimGroupImpl
      KULRICE-8219Services in KIM referencing KRAD dictionary validation service
      KULRICE-6634Improve LDAP module support for external identifiers
      KULRICE-5947Add validation for data dictionary defined custom attributes
      KULRICE-14112JPA Performance of Referenced Entity (Child Data Objects) - KIM
      KULRICE-3455Possible issues with remoting of KIM Type Services and attributes
      KULRICE-3010Handle encrypted external identifiers in KIM
      KULRICE-513Referenced attributes are not validated against when dd file is loaded and can result in NP
    • Rice Module:
      KIM
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      This issue was discovered in KULRICE-12021 and while the fix Jeremy reported for the issue will fix the bug they're experiencing it does not really address the underlying problem. I think that fix should be adopted if it can be tested thoroughly, but it doesn't really correct the underlying problem. Right now KIM attributes get passed around by name but that is not a unique identifier for an attribute. It seems to me like one of two things should be done to correct the problem:

      1. Add a unique constraint on the nm field in the attribute definition table. This is not really desirable because the combination of namespace code and name should be unique (and should be enforced with a DB constraint if it is not).
      2. Modify all of the places where attributes are passed around so they are passed with their fully qualified name (e.g. "{namespaceCode}name").

      Option 2 would fix the underlying issue in a desirable way but will likely cause a new set of problems in the code base. This would be difficult to verify that all of the spots in the code base correctly handle attributes by their fully qualified name, and even if they do the change may not be backwards compatible with older versions of Rice. This may need to be addressed at some point in the future when Rice can break the backwards compatibility. Further, KEW rule attributes and KRMS attributes both use similar concepts so this may be a bigger problem than just in the KIM module.

      I marked this as a critical item because it can cause issues for organizations which implement Rice in several different ways and they may not be able to figure out what is going on without having intricate knowledge of KEW/KIM/KRMS.

        Issue Links

          Activity

          Hide
          Jeremy Hanson added a comment -

          linking with 12021. This would be the "ideal" fix.

          Show
          Jeremy Hanson added a comment - linking with 12021. This would be the "ideal" fix.
          Hide
          Eric Westfall added a comment -

          Moving to version 3.0 as per our discussion at the KTI today.

          Show
          Eric Westfall added a comment - Moving to version 3.0 as per our discussion at the KTI today.
          Hide
          Eric Westfall added a comment -

          This was discussed in KTI meeting today:

          https://wiki.kuali.org/display/KULRICE/Kuali+Technical+Integration+-+March+19%2C+2014

          Decision was as follows:

          • This should be scheduled for 3.0 so that we can make the changes to the services without having to worry about backward compatibility.
          • The general approach will be to use a new "key" for the various hashmaps which take an object like "AttributeName" which consists of namespace code and name (we have the pairing of namespace code + name all over the code base, perhaps an object that's part of the core API and more general would make more sense then we could use it consistently everwhere?)
          • We would then modify the various places that take Map<String, String> for qualifications, details, and the like to use this new object as the key.
          • We likely also need to update the various KIM ui's to make sure the parameter names used for the various attribute fields are unique as well.

          One thing I would mention though is that we probably want to rexamine this approach once we get to 3.0. The typing mechanism in KIM, KRMS, KEW, etc. is very cumbersome. I don't really like it, but obviously it has it's purpose. I would like to spend some effort thinking if there is a simpler solution which provides the same functional benefits. It would probably serve us all well in the long run to do that.

          Show
          Eric Westfall added a comment - This was discussed in KTI meeting today: https://wiki.kuali.org/display/KULRICE/Kuali+Technical+Integration+-+March+19%2C+2014 Decision was as follows: This should be scheduled for 3.0 so that we can make the changes to the services without having to worry about backward compatibility. The general approach will be to use a new "key" for the various hashmaps which take an object like "AttributeName" which consists of namespace code and name (we have the pairing of namespace code + name all over the code base, perhaps an object that's part of the core API and more general would make more sense then we could use it consistently everwhere?) We would then modify the various places that take Map<String, String> for qualifications, details, and the like to use this new object as the key. We likely also need to update the various KIM ui's to make sure the parameter names used for the various attribute fields are unique as well. One thing I would mention though is that we probably want to rexamine this approach once we get to 3.0. The typing mechanism in KIM, KRMS, KEW, etc. is very cumbersome. I don't really like it, but obviously it has it's purpose. I would like to spend some effort thinking if there is a simpler solution which provides the same functional benefits. It would probably serve us all well in the long run to do that.

            People

            • Assignee:
              Unassigned
              Reporter:
              James Bennett
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel