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

Determine if we need to do some work on the KimTypeService interface to make return types more consistent

    Details

    • Rice Module:
      KIM

      Description

      Ailish sent the following to the Rice dev list in response to a question about the purpose of these different methods, notice her concern on the differences in return types for these:

      validateAttributes: make sure the values are the right size and shape and if there is a reference table that they exist and are active

      validateUniqueAttributes: make sure the principal doesn't have another assignment with the same values for these unique attributes

      validateAttributesAgainstExisting: seems like this is just giving the opportunity to provide a good error for validateUniqueAttributes, given the different return vals and the fact that the example i see in kfs... they are being used in conjunction with one another? location of the method at the end of kim type service base also leads me to believe this was an afterthought, and perhaps refatoring should have been done to make all validate methods return an attribute set instead of a boolean?

      validateUnmodifiableAttributes: make sure the values on the assignment that are considered keys are not changed during an edit... for example for accounting organization hierarchy... chart, org, and doc type cannot change during an edit... but from and to amount and override code can

      fwiw - i worry about the variation in which methods return List<String> vs. AttributeSet vs. boolean here

      not sure if you're looking at kfs code, but the best reference implementations would be there.

        Attachments

          Activity

          No work has yet been logged on this issue.

            People

            • Assignee:
              tschneeb Travis Schneeberger
              Reporter:
              ewestfal Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 2 days
                2d
                Logged:
                Time Spent - Not Specified
                Not Specified