Type: Bug Fix
Resolution: Cannot Reproduce
Affects Version/s: None
Fix Version/s: 2.5
Security Level: Public (Public: Anyone can view)
KULRICE-11295 Unable to change rule action from Validation to Route to Peopleflow / Notify PeopleFlow KULRICE-6313 Copying a routing rule edits the original rather than creating a new rule KULRICE-6003 Make PeopleFlow type service names friendlier to humans KULRICE-6393 PeopleFlow members show up as secondary delegates in the route log KULRICE-11057 Complex Routing in document never gets ingested with no response from server KULRICE-1840 Allow for exception routing group to be different based on document data KULRICE-7337 PeopleFlow: After Routing Doc, fields still editable KULRICE-12389 Notes & Attachment section looks different than Ad-Hoc and Route Log sections KULRICE-6576 PeopleFlow Action Id lookup throws NPE KULRICE-9720 Route Log Icon Missing from Action List
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
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.
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