Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0-m2, 2.1
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-7039Add info on Recall from Routing to User's Guide
      KULRICE-8647Kew Recall Tests fail with user permission errors
      KULRICE-7798Recall from Routing - Remaining Configuration Requirements
      KULRICE-2250Consolidate KEW and KNS Notes and Attachments framework
      KULRICE-7855NOTIFY_PENDING_ON_RETURN Policy (related to Recall from routing functionality) doesn't appear to be inherited
      KULRICE-5932Skip Routing for KEW
      KULRICE-9729KRMS Screens Don't allow for Recall or Superuser Tab
      KULRICE-2260Convert KEW Routing Report screen to use KNS
      KULRICE-1410Consolidate Notes and Attachments systems from KNS and KEW
      KULRICE-2243Replace references in WorkflowAttribute and it's subclasses from KEW lookup to KNS lookup classes
    • Rice Module:
      KEW
    • Application Requirement:
      KFS, KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Review Completed

      Description

      A document aggregator (a document scoped role that grants edit/view permissions to the whole doc) should be able to recall a document from workflow routing. This is to allow him to remove a document from the approval chain if there are any corrections to be made. Also this feature should be flexible enough to be customized by Document Type, current node name, application status code and/or document workflow status. We need this action to generate notifications to all the approvers and specified role members ( in this case, all the document aggregators). If at the time of recall, a document is found to be in the last route node, the user is informed of this and no action is taken (not sure if this part needs to be customizable by Document Type).

      All the general stuff that goes with this kind of action are needed as well -> Confirmation Dialog, Reason for recall (comments) etc...

      We considered the existing returnToPreviousNode functionality but that doesn't allow a document to be pushed back to Saved status and also, it can only be performed by someone who has a pending action request (considering the fact that document aggregators may not be superusers and hence cannot use superUserReturntoPreviosuNode). And, subsequent request for completion appears as an 'approve' request (and this is related to the document continuing in Enroute status). So, instead of trying to make this work, we would like this to be an out-of-the-box functionality from KEW.

      See related KC Jira with functional spec attached. Also, KC preference is to have a 'Recall' button included in the Document Controls section.

      Needed for KCFE.
      see https://wiki.kuali.org/display/KRACOEUS/Rice+Workflow+Enhancements

        Issue Links

          Activity

          Hide
          Aaron Hamid (Inactive) added a comment -

          Ailish, implementing that specific behavior in Rice would seem to conflict with KC requirements which imply a doc can be recalled at any point.

          Also this feature should be flexible enough to be customized by Document Type, current node name, application status code and/or document workflow status. We need this action to generate notifications to all the approvers and specified role members ( in this case, all the document aggregators). If at the time of recall, a document is found to be in the last route node, the user is informed of this and no action is taken (not sure if this part needs to be customizable by Document Type).

          A regression test was supplied to assert this: "Recall as initiator after a single approval"

          Regarding the first bullet, while there is not an explicit check for this, as RECALL is only valid on ENROUTE docs (and not PROCESSED or FINAL), as long as the doc goes PROCESSED or FINAL by that virtue, it will not be RECALLable. (although there is always a brief window of time when the UI is not updated due to async routing).

          KC/KFS - what should be done here?

          Show
          Aaron Hamid (Inactive) added a comment - Ailish, implementing that specific behavior in Rice would seem to conflict with KC requirements which imply a doc can be recalled at any point. Also this feature should be flexible enough to be customized by Document Type, current node name, application status code and/or document workflow status. We need this action to generate notifications to all the approvers and specified role members ( in this case, all the document aggregators). If at the time of recall, a document is found to be in the last route node, the user is informed of this and no action is taken (not sure if this part needs to be customizable by Document Type). A regression test was supplied to assert this: "Recall as initiator after a single approval" Regarding the first bullet, while there is not an explicit check for this, as RECALL is only valid on ENROUTE docs (and not PROCESSED or FINAL), as long as the doc goes PROCESSED or FINAL by that virtue, it will not be RECALLable. (although there is always a brief window of time when the UI is not updated due to async routing). KC/KFS - what should be done here?
          Hide
          Ailish Byrne added a comment -
          • No actions have been taken on the document since it was routed.
            Right, I assumed when the doc could be recalled would be configurable, since both requirements were in the specs. Couldn't that be implemented in a variety of ways... document type policy, permission template, system parameter, etc.?
          • There are pending action requests for the document.
            I think if this were instead implemented by checking to see whether there was a pending action request for the document, that would eliminate the issue with documents that have no routing and go straight to final (related to the asynchronous nature of workflow).

          Thanks, Aaron

          Show
          Ailish Byrne added a comment - No actions have been taken on the document since it was routed. Right, I assumed when the doc could be recalled would be configurable, since both requirements were in the specs. Couldn't that be implemented in a variety of ways... document type policy, permission template, system parameter, etc.? There are pending action requests for the document. I think if this were instead implemented by checking to see whether there was a pending action request for the document, that would eliminate the issue with documents that have no routing and go straight to final (related to the asynchronous nature of workflow). Thanks, Aaron
          Hide
          Ailish Byrne added a comment -

          Just thinking more about this... I wonder, since the specifications were reviewed and approved by the KAI-WG, if it would make sense for Matt to revisit with them at next week's meeting and see if they feel that these requirements are KFS-specific or generally useful. If the only place this client code will end up going is KFS, I definitely don't feel the need to pursue this. My only concerns at this point are...
          1. Making this feature as useful as it can be to all the Rice client apps
          2. Making is as easy as possible to customize for implementers (many from KFS intend to deviate from the base spec agreed upon for the delivered application)
          ... both with minimal code and especially minimal code duplication.

          Show
          Ailish Byrne added a comment - Just thinking more about this... I wonder, since the specifications were reviewed and approved by the KAI-WG, if it would make sense for Matt to revisit with them at next week's meeting and see if they feel that these requirements are KFS-specific or generally useful. If the only place this client code will end up going is KFS, I definitely don't feel the need to pursue this. My only concerns at this point are... 1. Making this feature as useful as it can be to all the Rice client apps 2. Making is as easy as possible to customize for implementers (many from KFS intend to deviate from the base spec agreed upon for the delivered application) ... both with minimal code and especially minimal code duplication.
          Hide
          Peter Giles (Inactive) added a comment -

          Hi Matt, given your history with this issue I'm going to assign it to you to work out what needs to happen next. Thanks

          Show
          Peter Giles (Inactive) added a comment - Hi Matt, given your history with this issue I'm going to assign it to you to work out what needs to happen next. Thanks
          Hide
          Matt Sargent added a comment -

          KULRICE-7798 has been created for the remaining requirements needed.

          Show
          Matt Sargent added a comment - KULRICE-7798 has been created for the remaining requirements needed.

            People

            • Assignee:
              Matt Sargent
              Reporter:
              Matt Sargent
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week, 1 day, 2 hours
                1w 1d 2h
                Remaining:
                Time Spent - 1 week, 30 minutes Remaining Estimate - 1 day, 1 hour, 30 minutes
                1d 1h 30m
                Logged:
                Time Spent - 1 week, 30 minutes Remaining Estimate - 1 day, 1 hour, 30 minutes
                1w 30m

                  Structure Helper Panel