[KULRICE-3319] Determine if we need to do some work on the KimTypeService interface to make return types more consistent Created: 02/Jul/09  Updated: 23/Feb/12  Resolved: 01/Aug/11

Status: Closed
Project: Kuali Rice Development
Component/s: Development, Documentation, Version Compatibility
Affects Version/s: None
Fix Version/s: 2.0.0-m7, 2.0

Type: Improvement Priority: Major
Reporter: Eric Westfall Assignee: Travis Schneeberger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

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.



 Comments   
Comment by Travis Schneeberger [ 18/Jul/11 ]

validateUnmodifiableAttributes() & validateUniqueAttributes() should probably not be on the service interface. Instead this validation checks should just be done by validateAttributesAgainstExisting(). The reasoning behind this is unmodifiable & uniqueness checks are just a type of validation against an existing attribute.

Comment by Rice-CI User (Inactive) [ 21/Jul/11 ]

Integrated in rice-trunk-nightly #126 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/126/)
KULRICE-3319, KULRICE-5404

Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Generated at Tue Apr 13 15:15:46 CDT 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.