[KULRICE-6595] Problem with Data Dictionary Entry hierarchy for transactional documents Created: 27/Jan/12 Updated: 23/Feb/12 Resolved: 06/Feb/12
|Project:||Kuali Rice Development|
|Fix Version/s:||2.0.0-rc2, 2.0|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||Jonathan Keller||Assignee:||Jerry Neal (Inactive)|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Attachments:||Transactional Document Issue.png|
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
So, at the moment, transactional documents are pretty much non-operational in KFS. The mapping which allows us to use the DD properties from the JSP layer hinges on being able to use the simple class names of the documents as keys into the DD. Unfortunately, the DataDictionaryIndexer is only using the new KRAD TransactionalDocumentEntry class when choosing how to index the classes. This results in the expected entries being absent and causing a host of problems.
Either the indexer needs to recognize the KNS version of the TransactionalDocumentEntry class or the KRAD version needs to be moved as a superclass of the KNS version like all the other entry classes.
|Comment by Eric Westfall [ 27/Jan/12 ]|
This sounds like a rough one, assigning to Jerry.
|Comment by Jerry Neal (Inactive) [ 06/Feb/12 ]|
I made the change to have KNS trans doc entry extend KRAD trans doc entry so it will get picked up by the indexer. Let me know if this fixes the problem. Unfortunately we don't have a KNS trans doc to test with (we will be working on getting something).
Sorry for all the ugliness here!
|Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]|
Closing since these items are now in the release notes.