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

The Rice jsp/tag files for KIM throw errors when a KIM Type is using the KimNonDataDictionaryAttributeDefinition class

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None

      Description

      For KS we tried to set up some simple role routing and we had a new KIM type that was trying to use the 'KimNonDataDictionaryAttributeDefinition' class. I believe it was the roleAssignees.tag file that threw errors because it assumed all instances of the AttributeDefinition implementation classes used by KIM would have the attribute 'lookupBoClass' but the 'KimNonDataDictionaryAttributeDefinition' class does not.

      If the base AttributeDefinition class had some sort of 'hasLookupBoDefinition' method that the jsp/tag files could use then that would seem to solve the issue here though i don't know that the only tag file referencing this value is roleAssignees.tag. Other files would have to be verified to see which use the 'lookupBoClass'.

      We have seen one other error related to the 'KimNonDataDictionaryAttributeDefinition' class but we'll submit a separate Jira issue for it once we've isolated it.

        Attachments

          Activity

          Hide
          ewestfal Eric Westfall added a comment -

          Assigned to Jeremy and added Ailish as a watcher.

          Ailish, if we need any clarification on the code surrounding this, can you point us to the resource who worked on this code? Thanks!

          Show
          ewestfal Eric Westfall added a comment - Assigned to Jeremy and added Ailish as a watcher. Ailish, if we need any clarification on the code surrounding this, can you point us to the resource who worked on this code? Thanks!
          Hide
          abyrne Ailish Byrne added a comment -

          try me since the first person i assigned this no longer works on rice and the person who did a bunch of work is out of town for the next month

          Show
          abyrne Ailish Byrne added a comment - try me since the first person i assigned this no longer works on rice and the person who did a bunch of work is out of town for the next month
          Hide
          jjhanso Jeremy Hanson added a comment -

          Would it make sense to have the lookupBoClass in the KimNonDataDictionaryAttributeDefinition?

          Show
          jjhanso Jeremy Hanson added a comment - Would it make sense to have the lookupBoClass in the KimNonDataDictionaryAttributeDefinition?
          Hide
          abyrne Ailish Byrne added a comment -

          i'll let david comment... just i think the non dd attr defn needs to operate solely on url based info and stuff. lookupBoClass is kind of inherently a dd concept.

          Show
          abyrne Ailish Byrne added a comment - i'll let david comment... just i think the non dd attr defn needs to operate solely on url based info and stuff. lookupBoClass is kind of inherently a dd concept.
          Hide
          delyea David Elyea added a comment -

          I think ultimately it would be nice to have some sort of url based lookup kinda stuff but at this point for 1.0 it might just be enough to fix it so the screen will display. I think it depends on timing and what we think can get done? For the time being we've switched back to the KNS method using the KimDataDictionaryAttributeDefinition but i entered the Jira anyway since someone in the community might run into the bug and it was basically preventing viewing of the KIM objects.

          I would think to do the URL method the source app (in this case KS) would need to provide a URL for the lookup on the KRIM_ATTR_DEFN_T and then in the system you'd have to pass request parameters to the source app which would be at least the return url (since i would think we'd need stuff like docFormId or other KNS parameters) as well as something similar to the 'field translation' stuff where the source app can say... ok return the data element X as request parameter Y to the return url. Sorry if that's confusing... it's all off the top of my head.

          Show
          delyea David Elyea added a comment - I think ultimately it would be nice to have some sort of url based lookup kinda stuff but at this point for 1.0 it might just be enough to fix it so the screen will display. I think it depends on timing and what we think can get done? For the time being we've switched back to the KNS method using the KimDataDictionaryAttributeDefinition but i entered the Jira anyway since someone in the community might run into the bug and it was basically preventing viewing of the KIM objects. I would think to do the URL method the source app (in this case KS) would need to provide a URL for the lookup on the KRIM_ATTR_DEFN_T and then in the system you'd have to pass request parameters to the source app which would be at least the return url (since i would think we'd need stuff like docFormId or other KNS parameters) as well as something similar to the 'field translation' stuff where the source app can say... ok return the data element X as request parameter Y to the return url. Sorry if that's confusing... it's all off the top of my head.
          Hide
          jjhanso Jeremy Hanson added a comment -

          I created a class KimAttributeDefinition and put a isHasLookupBoDefinition() class in it. Then changed KimNonDataDictionaryAttributeDefinition and KimDataDictionaryAttributeDefinition to extend from it.

          The tag files have been updated to check this boolean before trying to call the lookupBoClass variable.

          Show
          jjhanso Jeremy Hanson added a comment - I created a class KimAttributeDefinition and put a isHasLookupBoDefinition() class in it. Then changed KimNonDataDictionaryAttributeDefinition and KimDataDictionaryAttributeDefinition to extend from it. The tag files have been updated to check this boolean before trying to call the lookupBoClass variable.
          Hide
          ewestfal Eric Westfall added a comment -

          Bulk change of all Rice 1.0 issues to closed after public release.

          Show
          ewestfal Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

            People

            • Assignee:
              jjhanso Jeremy Hanson
              Reporter:
              delyea David Elyea
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: