[KULRICE-9358] Form and WorkflowDocument no longer being persisted to session after disabling the SessionDocumentService Created: 17/Apr/13  Updated: 12/Aug/13  Resolved: 24/Apr/13

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 2.1.5, 2.2.3
Fix Version/s: 2.1.6, 2.2.4
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Critical
Reporter: Peter Giles (Inactive) Assignee: Peter Giles (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to KFSOLD-23383 CAMS - NPE when initiating Asset Manu... Closed
is related to KULRICE-9380 refactor DocumentHeader so that we ca... Open
is related to KULRICE-9148 Disable SessionDocumentService in the... Closed
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:
KAI Review Status: Not Required
KTI Review Status: Not Required
Include in Release Notes?:


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.

Comment by Peter Giles (Inactive) [ 23/Apr/13 ]

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.

Comment by Peter Giles (Inactive) [ 24/Apr/13 ]

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.

Generated at Wed Oct 23 06:19:56 CDT 2019 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.