[KULRICE-12849] Able to create a TravelAccount with a fiscal officer that does not exist, even if a defaultExistenceChecks exists for it. Created: 19/Jun/14 Updated: 24/Sep/14 Resolved: 07/Aug/14
|Project:||Kuali Rice Development|
|Component/s:||Development, KNS Equivalency|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||Shannon Hess||Assignee:||Steve Edgar (Inactive)|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Sprint:||Core 2.5.0-m6 Sprint 1|
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
|Code Review Status:||Not Required|
|Include in Release Notes?:||
Links to test locally:
Code in DictionaryValidationServiceImpl (comments are a bit confusing in this method):
|Comment by Steve Edgar (Inactive) [ 04/Aug/14 ]|
This is an interesting case. TraveAccount.getFiscalOfficer() also acts as a setter. And, the line ...
fiscalOfficer = KimApiServiceLocator.getPersonService().updatePersonIfNecessary(foId, fiscalOfficer);
... will return a PersomImpl, with most of the fields either null or empty, if the foid does not exist in KIM.
This means an "early read" on that field, via pre/post "bind", before the Controller is invoked, will cause that field to be non-null.
This is in contrast to how accountType works. Reads on that field do not set anything, and a "reference check" fails if an "invalid code" is looked up, leaving accountType null. This allows the validation to kick in on the form, and highlight that field.
I think the best change, which does not affect "other code", is to only allow TraveAccount.getFiscalOfficer() to fill in fiscalOfficer if the PersonImpl returned contains a principalId.
I have a commit ready for this, but first, a few questions ...
The validation already in place on the form will highlight the Travel Account Type Code field, if an invalid code is entered. However, no error headings appear, as they do with client side validation. (This is a situation not related to this case.) The same will now be true with the Fiscal Officer User ID field.
However, if the one clicks on the highlighted field, a "hint" appears over the field. Are error headings desired? If so, I'm assuming that would be another case, as it appears to be a "feature addition" to the way things currently work.
Should there be an AFT for this case, and if so would QA do that, or would I?
Should there be a code review for this case, and if so, who should review?
(Adding Claus as a Watcher.)
|Comment by Steve Edgar (Inactive) [ 07/Aug/14 ]|
Have received no further feedback on this case, and so am resolving.