Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-12100

KIM Attributes are referenced by a non-unique identifier

    Details

    • Type: Bug Fix
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • 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.

        Attachments

          Issue Links

            Activity

            Hide
            jjhanso Jeremy Hanson added a comment -

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

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

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

            Show
            ewestfal Eric Westfall added a comment - Moving to version 3.0 as per our discussion at the KTI today.
            Hide
            ewestfal 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
            ewestfal 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:
                jawbenne James Bennett
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: