Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-12914

The documentHeaderService is not repopulating the workflowDocument

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical 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
    • Similar issues:
      KULRICE-12233workflowDocument should not be a field on the DocumentHeader
      KULRICE-5325Get rid of KualiWorkflowDocument, replace with standard WorkflowDocument KEW api
      KULRICE-9380refactor DocumentHeader so that we can remove special logic for stashing the WorkflowDocument in the UserSession
      KULRICE-5937Add javadocs to WorkflowDocument and WorkflowDocumentFactory
      KULRICE-2614Repopulate the GL_INPUT_TYP_T table in KFS from the KNS Document Type table
      KULRICE-5093repopulating group attributes does not occur after a lookup search for a given group
      KULRICE-9358Form and WorkflowDocument no longer being persisted to session after disabling the SessionDocumentService
      KULRICE-2176Move GlobalResourceLoader, WorkflowDocument and WorkflowInfo to api module
      KULRICE-4864remove the dependencies UserSession has on EditablePropertiesHolder, ConfigService, & WorkflowDocument
      KULRICE-2374Make sure that all KEW super user actions are available on WorkflowDocument
    • 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.

        Activity

        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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:
            Jonathan Keller
            Reporter:
            Gayathri Athreya
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel