[KULRICE-12964] Incorrect JPA mapping for MaintenanceDocumentBase Created: 11/Jul/14  Updated: 24/Sep/14  Resolved: 17/Jul/14

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: 2.5
Security Level: Public (Public: Anyone can view)

Type: Bug Fix Priority: Blocker
Reporter: Jay Hulslander Assignee: Shannon Hess
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours
Original Estimate: 2 days

Attachments: XML File LegacyTravelCompanyKns.xml     Java Source File LegacyTravelCompanyOjb.java     JPEG File submitting doc that extends PersistableAttachment.jpg    
Issue Links:
is related to KULRICE-12246 Identify work to decouple OJB and KNS... Closed
Similar issues:
KULRICE-12804Analysis on why projects are extending MaintenanceDocumentBase
KULRICE-2063Fix JPA references in KNS from the merges
KULRICE-1959Finish annotating entities with JPA annotations
KULRICE-11001Advanced Lookup Demo - ORM mapping for BOs
KULRICE-11490Convert CategoryBo to JPA
KULRICE-9515Document how to convert OJB descriptor mappings to JPA
KULRICE-11468Add ability to remove mappings from superclass with JPA
KULRICE-11496Convert KCB entities from OJB to JPA
KULRICE-11148JPA mapped transactional document fields not linking
KULRICE-2141Add JPA annotations and implement JPA Daos throughout Rice
Rice Module:
Application Requirement:
Sprint: Core 2.5.0-m5 Sprint 2
KAI Review Status: Not Required
KTI Review Status: Not Required
Code Review Status: Not Required
Include in Release Notes?:


MaintenanceDocumentBase should have a @OneToOne not @ManyToOne

@ManyToOne(fetch = FetchType.LAZY,
cascade =

{CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE}

@JoinColumn(name = "DOC_HDR_ID",
insertable = false, updatable = false)
protected DocumentAttachment attachment;

they have the exact same PK so that relationship makes no sense

Comment by Jay Hulslander [ 11/Jul/14 ]

This causing a maintainence document problem in KC, which is documented on KRACOEUS-7543

Comment by Kristina Taylor (Inactive) [ 14/Jul/14 ]

We need to also verify that we have one or write a test for this.

Comment by Shannon Hess [ 17/Jul/14 ]

After fixing the mapping I was still getting the same error that is seen in KRACOEUS-7543.

It turns out that error started happening after the changes were made to org.kuali.rice.krad.maintenance.MaintenanceDocumentBase#refreshAttachment for KULRICE-12246 (Made on 6/6/2014). I added the old refreshAttachment methods to the KNS version of MaintenanceDocumentBase and that fixed the issue.

However, when I was testing I ran into a couple other issues. Both are now fixed and it appears to work correctly when I submit the document (see attached screenshot). However, the info is NOT saved to KRNS_MAINT_DOC_ATT_T and I can't figure out why that is the case. I did commit the changes I've made so far and I believe this will fix the issue seen in KRACOEUS-7543, as they don't use KRNS_MAINT_DOC_ATT_T - It appears they use their own tables to store the attachment.

Comment by Shannon Hess [ 17/Jul/14 ]

I determined that the data IS getting saved to KRNS_MAINT_DOC_ATT_T, but it is getting deleted in MaintenanceDocumentBase.doRouteStatusChange. I verified that the data is in the table before these statements are hit. (For KNS documents). From what I can tell, the KRNS_MAINT_DOC_ATT_T table is used to store the attachment until the document goes to final.

//Attachment should be deleted from Maintenance Document attachment table
// unlock the document when its canceled or disapproved or placed inException status
if (workflowDocument.isCanceled() || workflowDocument.isDisapproved() || 
   workflowDocument.isRecalled() || workflowDocument.isException()) {
     //Attachment should be deleted from Maintenance Document attachment table

For KRAD documents, the KRNS_MAINT_DOC_ATT_T table is not currently used due to populateAttachmentForBO and populateDocumentAttachment not being converted. Currently there is no KNS document that I can test with - I was able to test this issue by modifying LegacyTravelCompanyOjb.java, but I did not make any database changes which would be required to fully test the entire process.

There is a KRAD doc that works as expected - it also stores the file attachment data on its own table (trv_att_sample table).

Links to KRAD documents -
Local - http://localhost:8080/krad-dev/kr-krad/maintenance?methodToCall=start&dataObjectClassName=org.kuali.rice.krad.labs.LabsTravelAttachment
env14 - http://env14.rice.kuali.org/kr-krad/maintenance?methodToCall=start&dataObjectClassName=org.kuali.rice.krad.labs.LabsTravelAttachment

Code which should be implemented??

    public void populateAttachmentForBO() {
        // TODO: need to convert this from using struts form file


    public void populateDocumentAttachment() {
        // TODO: need to convert this from using struts form file
Comment by Kristina Taylor (Inactive) [ 17/Jul/14 ]

There are a few issues to cover this particular code, so don't worry about that piece.

Comment by Shannon Hess [ 17/Jul/14 ]


How would you recommend adding a test for this - the issue in KRACOEUS-7543 is a KNS document which we don't currently have and would require a database change. Is my modified local testing good enough for this issue?


Comment by Kristina Taylor (Inactive) [ 17/Jul/14 ]

I had forgotten there were KRAD tests for this. Having those should be sufficient.

Comment by Shannon Hess [ 17/Jul/14 ]

I was able to reproduce and fix the error seen in KRACOEUS-7543. However, in case this does not fix KRACOEUS-7543 and this issue is re-opened, I'm attaching modified files used for local testing :

  • LegacyTravelCompanyKns.xml
  • LegacyTravelCompanyOjb.java

Link to create doc in rice sampleapp - http://localhost:8080/kr-dev/kr/maintenance.do?businessObjectClassName=org.kuali.rice.legacy.LegacyTravelCompanyOjb&methodToCall=start

Generated at Fri May 29 14:40:52 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.