Indicate the necessity for this enhancement. What does it accomplish?
PeopleFlows have their own concept of delegations that are defined on the PeopleFlow. The purpose of this task is to define and implement how delegations are viewed when the member type on the stop or on the stop's delegate is "role".
Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.
Include at least one usage scenario, from the user's task perspective, that might be helpful in understanding the issue:
Mocks and Diagrams
Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue:
If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):
Include links to other confluence pages or external resources that might be helpful for this issue:
List all requirements (individual verifiable statements) that indicate whether the work for this item has been complete. If there are requirements that are not essential to the functionality but would be nice to have if time allows, enter those under 'Non-Essential':
List any functional or technical work that must be completed before work on this item can begin:
List any issues that need to be resolved before work on this item can begin:
We first need to affirm the requirements here:
- If you have a role as a PeopleFlow member, should it route delegate requests to that role's delegates?
- KC A: YES
- If you have a role as a PeopleFlow member, and you have defined a delegate on that role member, how should that situation be handled? Does the people flow delegate member take precedence? The role delegates? Or possibly both?
- KC A: If a PeopleFlow (role) member has delegates defined on the PeopleFlow, the delegates defined on the PeopleFlow take precedence
- In the case of a role PeopleFlow member with a delegate, is it assumed that delegate should be the delegate for all members of the role?
- KC A: YES
- What should happen if you are delegating to a role, should it's delegates be ignored? This is probably what should happen, but is this problematic? KEW can only support delegation one-level deep. Should probably look at how KIM is handling this currently.
- KC A: Ignoring the delegates is fine in the scenario from a Coeus FE perspective. So if this is how you guys think it should work and is what the system supports, it's ok with us (KC).
- PeopleFlowRoutingTest - an integration test which tests various peopleflow routing scenarios
- PeopleFlowRequestGeneratorImpl - a class which handles generation of action requests from people flows
- ActionRequestFactory - a KEW class used to help construct action requests (this factory class is completely insane, by the way, enjoy...)
- Also, see TODO in PeopleFlowRequestGeneratorImpl.generateRequestForRoleMember regarding ignoring of built-in delegates when peopleflow delegates are defined.
QA or Regression Testing Plan
List steps needed to test the basic functionality of this update, enhancement, bug fix
Functional Analysis Complete? No (completed by SME)
Needs Review by KAI? No (completed by SME)
Technical Analysis Complete? No (completed by DM)
Needs Review by KTI? No (completed by DM)
Estimate: 30 hours (completed by DM)
Technical Design: Link Here (completed by DM)
Jira: https://jira.kuali.org/browse/KULRICE-5726 (completed by SME)
Final Documentation: Link Here (completed by DM)
Added to QA: No (completed by SME)