Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-5931

Recall from Routing Enhancement for KNS / KEW

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: 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
    • 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

        Attachments

          Issue Links

            Activity

            Hide
            ahamid 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
            ahamid 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
            abyrne 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
            abyrne 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
            abyrne 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
            abyrne 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
            gilesp 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
            gilesp 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
            masargen Matt Sargent added a comment -

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

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

              People

              • Assignee:
                masargen Matt Sargent
                Reporter:
                masargen 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