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

Form and WorkflowDocument no longer being persisted to session after disabling the SessionDocumentService

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.5, 2.2.3
    • Fix Version/s: 2.1.6, 2.2.4
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-9380refactor DocumentHeader so that we can remove special logic for stashing the WorkflowDocument in the UserSession
      KULRICE-8634Overriding session document service prevents any transactional document from being saved.
      KULRICE-9148Disable SessionDocumentService in the KNS
      KULRICE-7007Add flags to view to disable storing of form in session
      KULRICE-12914The documentHeaderService is not repopulating the workflowDocument
      KULRICE-7012Limit the size of form storage in session
      KULRICE-6307Incident report form does not get added to the session causing the submit report to fail
      KULRICE-9151Document in the guide on clustering that session failover should be implemented for full reliability
      KULRICE-4760Buttons on forms no longer have tabindex values
      KULRICE-8126Collection control does not honor disable if disable is disabled by an expression for collection refresh
    • Rice Module:
      KNS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      There were some behaviors that the SessionDocumentService was responsible for besides storing the document to the database, and since we replaced it with a NoOp version, we noticed a couple of side effects: the form and the WorkflowDocument are no longer being kept in the session between requests. While things seem to be pretty much working with this behavior change, it is probably too risky for our patch version.

      The plan is to restore this behavior, hopefully without depending on the SessionDocumentService for it.

        Issue Links

          Activity

          Hide
          Peter Giles (Inactive) added a comment -

          At the KTI today we agreed to preserve the stashing of WorkflowDocuments in the UserSession. To minimize the impact in 2.1.6, the fix there will be done in the minimally invasive way. In 2.3 we'll plan to address this by making the workflow document field on the document header non-transient, and remove all specific logic for storing and fetching the workflow document from the session since the form (which contains the document with its header) is stored in the session as well.

          Show
          Peter Giles (Inactive) added a comment - At the KTI today we agreed to preserve the stashing of WorkflowDocuments in the UserSession. To minimize the impact in 2.1.6, the fix there will be done in the minimally invasive way. In 2.3 we'll plan to address this by making the workflow document field on the document header non-transient, and remove all specific logic for storing and fetching the workflow document from the session since the form (which contains the document with its header) is stored in the session as well.
          Hide
          Peter Giles (Inactive) added a comment -

          Debugging what was going on in the UserSession today, the I found that the form was in fact being held in session, it just wasn't being done by the SessionDocumentService. I also chatted with Jonathan about what UC Davis did with their SessionDocumentService override, and it turns out that their implementation looked just like our NoOpSessionDocumentServiceImpl.

          Bearing that in mind, I think I will take the approach of restoring the behavior of keeping the WorkflowDocument in session as well without restoring the old SessionDocumentServiceImpl. We'll see how that goes anyway.

          Show
          Peter Giles (Inactive) added a comment - Debugging what was going on in the UserSession today, the I found that the form was in fact being held in session, it just wasn't being done by the SessionDocumentService. I also chatted with Jonathan about what UC Davis did with their SessionDocumentService override, and it turns out that their implementation looked just like our NoOpSessionDocumentServiceImpl. Bearing that in mind, I think I will take the approach of restoring the behavior of keeping the WorkflowDocument in session as well without restoring the old SessionDocumentServiceImpl. We'll see how that goes anyway.

            People

            • Assignee:
              Peter Giles (Inactive)
              Reporter:
              Peter Giles (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel