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

PeopleFlow Routing Sequence on Reroute different from original route

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Cannot Reproduce
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-11295Unable to change rule action from Validation to Route to Peopleflow / Notify PeopleFlow
      KULRICE-6313Copying a routing rule edits the original rather than creating a new rule
      KULRICE-6003Make PeopleFlow type service names friendlier to humans
      KULRICE-6393PeopleFlow members show up as secondary delegates in the route log
      KULRICE-11057Complex Routing in document never gets ingested with no response from server
      KULRICE-1840Allow for exception routing group to be different based on document data
      KULRICE-7337PeopleFlow: After Routing Doc, fields still editable
      KULRICE-12389Notes & Attachment section looks different than Ad-Hoc and Route Log sections
      KULRICE-6576PeopleFlow Action Id lookup throws NPE
      KULRICE-9720Route Log Icon Missing from Action List
    • Application Requirement:
      KC
    • Sprint:
      Core 2.5.0-m7 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      5

      Description

      In KC – First routing is correct: PI, Unit Stop 1, Unit Stop 2, Deans level.

      After rejection by Dean, and rerouting from DLC, follows different path: PI, Dean. Unit Stop 1 and Unit Stop are completely skipped on reroute after rejection at last stop.

      KC should follow the same default path for routing on reroute after Returned for Revisions as it does on initial routing.

      Geo Thomas discussed with Peter Giles here is the excerpt

      I had a chat w/ Geo about this today:

      [1:19:57 PM] Peter Giles: Hey Geo. This seems like it has to do with how PeopleFlows are routed, rather than KRMS evaluation. I don't think we ever tested what happens with a PeopleFlow after a "return to previous" action.
      [1:20:43 PM] Peter Giles: The important code here is probably in PeopleFlowRouteModule and PeopleFlowRequestGeneratorImpl (and how the KEW engine handles the requests generated by those)
      [1:21:54 PM] Peter Giles: I imagine it wouldn't be too hard to put an integration test together for this basing it on PoepleFlowRoutingTest.test_MultiplePeopleFlow_PriorityParallal()
      [1:41:41 PM] Geo Thomas: ok, thanks Peter
      [1:42:08 PM] Geo Thomas: do you think it would be easy for rice folks to fix this if we put the request in?
      [1:49:21 PM] Peter Giles: I'm not an adept with KEW, so it's hard for me to say, but my guess is that once we get to the bottom of it, we'll be able to tweak it. One worry would be if somewhere out there someone was depending on the current behavior.
      [1:50:38 PM] Geo Thomas: i think, KEW behaves correctly.. i.e., taking the original path... this issues seems to happen only within PPL Flow nodes
      [1:51:25 PM] Peter Giles: It may be something about how those requests are generated. Not sure.
      [1:51:37 PM] Geo Thomas: oh ok
      [1:52:26 PM] Peter Giles: My guess is they are still generated the second time around but for some reason KEW thinks they have already been handled.
      [1:52:42 PM] Geo Thomas: oh ok
      [1:53:49 PM] Geo Thomas: Its not configurable with any parameter right? like, enabling ppl flow to take the original path or something like that...
      [1:54:04 PM] Geo Thomas: i mean, as much as you can tell
      [1:57:43 PM] Peter Giles: Not that I can see

        Activity

        Hide
        Peter Giles (Inactive) added a comment -

        I haven't been able to get the described behavior to manifest, and at this point I'd say that without a test case that can reproduce the issue, I'm blocked

        Show
        Peter Giles (Inactive) added a comment - I haven't been able to get the described behavior to manifest, and at this point I'd say that without a test case that can reproduce the issue, I'm blocked
        Hide
        Amy Holden added a comment -

        Was able to replicate the problem routing sequence on reroute with People Flow approval stops in KC Hulk instance. (builf-21743)

        The dev proposal number is 79, Doc 5974. The same issue came up on second reroute, with the School/Dean level approval stop before the Lead unit approval stops.

        Lead unit: IN-PED
        Two People Flows for created for IN-PED (10004 and 10005)
        Agenda 10014 – two sibling rules, each invoking a different People Flow

        Dean/School approval level: IN-MED
        One People Flow for IN-MED 10006
        Agenda 10015 - two rules: one for initial routing, second, if false, for not initial routing.

        Will upload screenshot with correct and incorrect routing sequences called out from routing log.

        Show
        Amy Holden added a comment - Was able to replicate the problem routing sequence on reroute with People Flow approval stops in KC Hulk instance. (builf-21743) The dev proposal number is 79, Doc 5974. The same issue came up on second reroute, with the School/Dean level approval stop before the Lead unit approval stops. Lead unit: IN-PED Two People Flows for created for IN-PED (10004 and 10005) Agenda 10014 – two sibling rules, each invoking a different People Flow Dean/School approval level: IN-MED One People Flow for IN-MED 10006 Agenda 10015 - two rules: one for initial routing, second, if false, for not initial routing. Will upload screenshot with correct and incorrect routing sequences called out from routing log.
        Hide
        Peter Giles (Inactive) added a comment -

        This is on hold until we can get a scenario which is reproducible in Rice. As per my conversation with Geo yesterday, he's looking into some things on his end that could be contributing.

        Show
        Peter Giles (Inactive) added a comment - This is on hold until we can get a scenario which is reproducible in Rice. As per my conversation with Geo yesterday, he's looking into some things on his end that could be contributing.
        Hide
        Geo Thomas (Inactive) added a comment -

        After discussing with Peter, it found out that we wont be able to depend on the Stop Number of People Flow to define the order of entire Proposal Routing Log. Stop number works only in one people flow, not across the People Flows those attached to different Agendas.
        Since Agenda list is not exposed to client application, there is no way to sort Agenda list from KC side. To execute people flows in a particular order, we would have to depend on unit hierarchy. After analyzing the code with Peter, he had suggested a work around where we apply the Agenda one by one traversing through the hierarchy starting from leaf node ending in root.
        I will also create a separate KULRICE jira for exposing the agenda list for client application so that, we can sort it from our side.

        Show
        Geo Thomas (Inactive) added a comment - After discussing with Peter, it found out that we wont be able to depend on the Stop Number of People Flow to define the order of entire Proposal Routing Log. Stop number works only in one people flow, not across the People Flows those attached to different Agendas. Since Agenda list is not exposed to client application, there is no way to sort Agenda list from KC side. To execute people flows in a particular order, we would have to depend on unit hierarchy. After analyzing the code with Peter, he had suggested a work around where we apply the Agenda one by one traversing through the hierarchy starting from leaf node ending in root. I will also create a separate KULRICE jira for exposing the agenda list for client application so that, we can sort it from our side.
        Hide
        Peter Giles (Inactive) added a comment -

        Thanks Geo. I'm going to go ahead and resolve this one as "Cannot Reproduce". Let me know if there are any questions or concerns about that.

        Show
        Peter Giles (Inactive) added a comment - Thanks Geo. I'm going to go ahead and resolve this one as "Cannot Reproduce". Let me know if there are any questions or concerns about that.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0 minutes
              0m
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 day, 1 hour
              1d 1h

                Agile

                  Structure Helper Panel