[KULRICE-6595] Problem with Data Dictionary Entry hierarchy for transactional documents Created: 27/Jan/12  Updated: 23/Feb/12  Resolved: 06/Feb/12

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 2.0.0-rc1
Fix Version/s: 2.0.0-rc2, 2.0
Security Level: Public (Public: Anyone can view)

Type: Bug Fix Priority: Blocker
Reporter: Jonathan Keller Assignee: Jerry Neal (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Transactional Document Issue.png    
Issue Links:
is relied upon by KFSOLD-21758 Modify KFS to use Rice 2.0 Closed
Similar issues:
KULRICE-10896KNS transactional documents are unable to mask their fields
KULRICE-12346NPE in role document if required is null in remote data dictionary entry
KULRICE-6745Document the Data Dictionary Validation improvements
KULRICE-12166Two instances of the data dictionary service (and data dictionary) are loaded in Rice context
KULRICE-1460Implement best of breed for maint and transactional doc frameworks
KULRICE-8005DataDictionaryIndexMapper change breaks transactional documents when institutions override business object classes
KULRICE-6217Document the Data Dictionary
KULRICE-10711Data Dictionary Analysis (items DD1 - DD6)
KULRICE-10712Data Dictionary Analysis (items DD7 - DD9)
KULRICE-4721Ability to specify custom actions in data dictionary
Rice Module:
Application Requirement:
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.

Generated at Fri Jun 05 05:16:53 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.