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

Overriding session document service prevents any transactional document from being saved.

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.1, 2.1.2
    • Fix Version/s: 2.1.3
    • Component/s: Performance
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4443Allow workflow sessions to fail over between nodes to prevent document loss
      KULRICE-7708Open/Closed Tab state not being saved on transactional documents
      KULRICE-9237Restructure sections on clustering and session document service
      KULRICE-8607KNS KualiDocumentFormBase uses the KRAD Session document service instead of the KNS version.
      KULRICE-12696Implement Pessimistic Locking in KRAD Documents
      KULRICE-14098Investigate people flow executor issues with Transactional document
      KULRICE-7965With rice rev. 34214, the blank line(s) on any document is being validated and the document can not be saved/submitted at this point.
      KULRICE-1352form is not restored from session for multipart request
      KULRICE-13726Rework Documentation and Contribution notes from KD sessions
      KULRICE-4001overriding identity service only does not really work
    • Rice Module:
      KNS
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      OVerriding the session document service and emptying the methods removeDocumentFromSession and addDocumentToUserSession prevents any transactional document from being saved. The problem I think is in the following lines in the KualiDocumentFormBase.

       SessionDocumentService sessionDocumentService = KRADServiceLocatorWeb.getSessionDocumentService();
                  	workflowDocument = sessionDocumentService.getDocumentFromSession( GlobalVariables.getUserSession(), getDocument().getDocumentNumber());
               	 	if ( workflowDocument == null)
               	 	{
                          // gets the workflow document from doc service, doc service will also set the workflow document in the
                          // user's session
               	 		Person person = KimApiServiceLocator.getPersonService().getPersonByPrincipalName(KRADConstants.SYSTEM_USER);
               	 		workflowDocument = KRADServiceLocatorWeb.getWorkflowDocumentService().loadWorkflowDocument(getDocument().getDocumentNumber(), person);
               	 	 	sessionDocumentService.addDocumentToUserSession(GlobalVariables.getUserSession(), workflowDocument);
               	 	 	if (workflowDocument == null)
               	 	 	{
               	 	 		throw new WorkflowException("Unable to retrieve workflow document # " + getDocument().getDocumentNumber() + " from workflow document service createWorkflowDocument");
               	 	 	}
               	 	 	else
               	 	 	{
               	 	 	LOG.debug("Retrieved workflow Document ID: " + workflowDocument.getDocumentId());
               	 	 	}
               	 	}
      

      When the document retrieved with the sessionDocumentService is null, this code (I think) makes the assumption that if it cannot find the document in the user session then the workflow user must be the system user 'kr'. So it sends this system user to retrieve the workflow document from the workflow service before trying to save it. While doing so, it sets the principalId field in the workflowDocumentImpl class as 'kr'. So when further down the line, the save method in the workflowDocumentServiceImpl is called (it calls the isValidAction method to make sure "save" is a valid action) it results in the executorInitiatorPolicyCheck method being called which returns false because the principal 'kr' does not match the current user in session who is the initiator of the document. This bubbles up and the validateActionRulesCustom method in SaveActionEvent class returns a "User is not authorized to Save document" message. This causes the document to not be saved and there is no exception or stack trace. It is possible that I am missing something here but it seems to me like the code above should attempt to retrieve the principalId from the user session first before trying to retrieve it as the rice system user? I noticed that this code also resides in Rice 1.0.3.3 so I am not sure how systems using this older version were able to override this method successfully. Perhaps something has changed between the two rice versions that I am not aware of.

        Activity

        Hide
        Gayathri Athreya added a comment -

        Thanks a lot for verifying this Shannon. The only reason I can think of for using the system user to retrieve the document is because of the operations workflow does asynchronously but then again, the way you have done it should not cause a problem I think. But some workflow expert might know the real reason for the original code.

        Show
        Gayathri Athreya added a comment - Thanks a lot for verifying this Shannon. The only reason I can think of for using the system user to retrieve the document is because of the operations workflow does asynchronously but then again, the way you have done it should not cause a problem I think . But some workflow expert might know the real reason for the original code.
        Hide
        Gayathri Athreya added a comment -

        I do have a question related to this though that I hope someone on the rice team can answer. If the user is not authorized as was the case before the code change, why does the "User is not authorized" message not show up as a "Not authorized" error message? It seems like the message is swallowed and never show to the user. The problem with this is, unless a user performs a doc search and notices the missing document, he/she will never realize the document was not saved. The more puzzling fact is that I was able to route the document all the way to final. Once the document was routed, then it showed up in the doc search but even then the "User is not authorized" message kept getting returned every time workflow tried to save the document. Let me know if you think this is a problem and I should create a separate jira for this issue. Thanks for resolving this so quickly though, greatly appreciated.

        Show
        Gayathri Athreya added a comment - I do have a question related to this though that I hope someone on the rice team can answer. If the user is not authorized as was the case before the code change, why does the "User is not authorized" message not show up as a "Not authorized" error message? It seems like the message is swallowed and never show to the user. The problem with this is, unless a user performs a doc search and notices the missing document, he/she will never realize the document was not saved. The more puzzling fact is that I was able to route the document all the way to final. Once the document was routed, then it showed up in the doc search but even then the "User is not authorized" message kept getting returned every time workflow tried to save the document. Let me know if you think this is a problem and I should create a separate jira for this issue. Thanks for resolving this so quickly though, greatly appreciated.
        Hide
        Shannon Hess added a comment -

        I talked to Eric about this a bit and he thinks it makes sense to get the user on the session before falling back and using the System User.

        I tested this replacing the user with someone who actually isn't allowed to save and a "User is not authorized to Save document" stack trace was thrown to the screen. (I had to change the user while debugging because if you don't have permission to save, you also don't have permissions to even create or edit the document.) Since the functionality is working I added a check to make sure it's not the system user before adding the "User is not authorized to Save document" message. So if the kr user does try to save in the future that error will no longer be thrown.

        Show
        Shannon Hess added a comment - I talked to Eric about this a bit and he thinks it makes sense to get the user on the session before falling back and using the System User. I tested this replacing the user with someone who actually isn't allowed to save and a "User is not authorized to Save document" stack trace was thrown to the screen. (I had to change the user while debugging because if you don't have permission to save, you also don't have permissions to even create or edit the document.) Since the functionality is working I added a check to make sure it's not the system user before adding the "User is not authorized to Save document" message. So if the kr user does try to save in the future that error will no longer be thrown.
        Hide
        Gayathri Athreya added a comment -

        Cool, thanks Shannon!

        Show
        Gayathri Athreya added a comment - Cool, thanks Shannon!
        Hide
        Gayathri Athreya added a comment -

        Working now, thanks!

        Show
        Gayathri Athreya added a comment - Working now, thanks!

          People

          • Assignee:
            Shannon Hess
            Reporter:
            Gayathri Athreya
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel