Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-12914

The documentHeaderService is not repopulating the workflowDocument

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Critical
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      2

      Description

      In the past, when Rice was using OJB, the documentHeader service had the workflowDocument field populated in the documentHeader when one called
      getDocumentHeaderById. While migrating to JPA, this field was made transient in documentHeader which means after persisting, this field becomes null and needs to be manually re-populated. Rice needs to populate this field in order to keep with previous behaviour.

        Attachments

          Activity

          Hide
          jkeller Jonathan Keller added a comment -

          No - It's not there as far back as I can see, in either the DH Service or the DH business object itself. I'm uncomfortable with adding it as that would definitely be additional logic (possibly a service call) running when it may not be needed or expected.

          Show
          jkeller Jonathan Keller added a comment - No - It's not there as far back as I can see, in either the DH Service or the DH business object itself. I'm uncomfortable with adding it as that would definitely be additional logic (possibly a service call) running when it may not be needed or expected.
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment -

          Jonathan Keller, the workflow document was never eagerly loaded in OJB? Gayathri Athreya, how did you guys do this in OJB? With the BOS?

          I can see Jonathan's point now that in all other cases, we restore the workflow document from the passed in document. I'm still wondering if there's an alternate solution to have KC avoid using this specialized call.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - Jonathan Keller , the workflow document was never eagerly loaded in OJB? Gayathri Athreya , how did you guys do this in OJB? With the BOS? I can see Jonathan's point now that in all other cases, we restore the workflow document from the passed in document. I'm still wondering if there's an alternate solution to have KC avoid using this specialized call.
          Hide
          jkeller Jonathan Keller added a comment -

          No - ever since Rice 0.9.x, that has been populated from a call since they were trying to design it so that workflow could be remote. WorkflowDocument is not a database object. (Like Person - it's assembled from internal KEW tables.)

          Show
          jkeller Jonathan Keller added a comment - No - ever since Rice 0.9.x, that has been populated from a call since they were trying to design it so that workflow could be remote. WorkflowDocument is not a database object. (Like Person - it's assembled from internal KEW tables.)
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment -

          I went back to Rice 2.3. I first noticed that the @Transient was added in the initial 0.9.3 attempt at JPA, so it would have gone live as soon as people started switching to JPA. This seems to verify Jonathan Keller's comment that the workflow document "has been populated from a call since they were trying to design it so that workflow could be remote". In addition, even when using OJB in Rice 2.3 I noticed that the restoring of the workflow document is inconsistent between calls. Here is what I did:

          1) Edited our Travel Account maintenance document
          2) Executed a Save
          3) Put a break point in DocumentBase.setDocumentHeader and watched as the calls came in from MaintenanceDocumentBase.postLoad where this method is called.

          Sometimes it would return a workflow document, sometimes it wouldn't. I remember similar problems with workflow documents back when I was working on KC, where sometimes we would get a stack trace saying that the workflow document was null, and I don't know if the issue was ever addressed by Rice. I would conclude from this evidence that the automatic fetching of the workflow document from this service call is unreliable even in OJB and should not be expected as standard behavior. This is a direct database load and since the workflow document is not a database object, it should not be populated in that manner.

          That being said, it sounds like KC does have a use case where they need to save their document without running rules against it, and adding Rice support for that would be beneficial. So while my opinion is that this is not a bug, it does potentially qualify as a feature request.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - I went back to Rice 2.3. I first noticed that the @Transient was added in the initial 0.9.3 attempt at JPA, so it would have gone live as soon as people started switching to JPA. This seems to verify Jonathan Keller 's comment that the workflow document "has been populated from a call since they were trying to design it so that workflow could be remote". In addition, even when using OJB in Rice 2.3 I noticed that the restoring of the workflow document is inconsistent between calls. Here is what I did: 1) Edited our Travel Account maintenance document 2) Executed a Save 3) Put a break point in DocumentBase.setDocumentHeader and watched as the calls came in from MaintenanceDocumentBase.postLoad where this method is called. Sometimes it would return a workflow document, sometimes it wouldn't. I remember similar problems with workflow documents back when I was working on KC, where sometimes we would get a stack trace saying that the workflow document was null, and I don't know if the issue was ever addressed by Rice. I would conclude from this evidence that the automatic fetching of the workflow document from this service call is unreliable even in OJB and should not be expected as standard behavior. This is a direct database load and since the workflow document is not a database object, it should not be populated in that manner. That being said, it sounds like KC does have a use case where they need to save their document without running rules against it, and adding Rice support for that would be beneficial. So while my opinion is that this is not a bug, it does potentially qualify as a feature request.
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment -

          Met with the leads today. We decided that because of the analysis, we should not fix this. You should be able to add a few lines to your code to grab the workflow document. We do see that you may have a new feature for saving documents without running rules, so please submit this as a separate request for 2.6.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - Met with the leads today. We decided that because of the analysis, we should not fix this. You should be able to add a few lines to your code to grab the workflow document. We do see that you may have a new feature for saving documents without running rules, so please submit this as a separate request for 2.6.

            People

            • Assignee:
              jkeller Jonathan Keller
              Reporter:
              gathreya Gayathri Athreya
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: