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

Add support for delegates on roles in PeopleFlows as well as using roles as delegates

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.1
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-12940PeopleFlow role delegate issue
      KULRICE-6984Role Delegate APIs are not granular enough
      KULRICE-7479Delegations not showing on Role document
      KULRICE-8373Delegation/Role caches not being updated after role document delegation change
      KULRICE-14235KIM Role: Delegate issues once the member is inactivated
      KULRICE-6935If you access person maintenance or role maintenace and add a delegation with a future Active From Date then you cannot see that delegation exists to verify or edit after submit.
      KULRICE-4762Role: Removed an Assignee who has delegations associated with him and now the Role cannot be updated
      KULRICE-12325RoleService does not properly populate delegates for nested role memberships
      KULRICE-7761Super user approval - the role is showing up in addition to the people in the role. Approving for the Role leaves the Delegator column blank.
      KULRICE-3848Delegation membership check not working for non-qualified roles
    • Rice Module:
      KEW
    • Application Requirement:
      KC, KPME
    • Sprint:
      2.3.1 Sprint 2
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      As part of KULRICE-5684 i implemented pretty much everything except support for roles that have people flow delegate members and support for non-role peopleflow members with roles as delegates.

      The current working, tested, and implemented behavior for roles on peopleflows is as follows, if the KIM role has delegates on it, it will route to those delegate members. Any delegates defined on the peopleflow itself will be ignored. I'm actually not 100% sure what will happen if you try to define a role as a peopleflow delegate.

      We first need to affirm the requirements here:

      1. If you have a role as a PeopleFlow member, should it route delegate requests to that role's delegates?
      2. 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?
      3. 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?
      4. 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.

      The relevant code here is the following:

      1. PeopleFlowRoutingTest - an integration test which tests various peopleflow routing scenarios
      2. PeopleFlowRequestGeneratorImpl - a class which handles generation of action requests from people flows
      3. 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.

        Issue Links

          Activity

          Hide
          Peter Giles (Inactive) added a comment - - edited

          Basic problem: When there is a Role member with requestPolicy=ALL having a a Role delegate with requestPolicy=ALL, the members and the delegates are all being required to approve. I don't think it should work that way, I think only the delegates should have to approve.

          PeopleFlow config:

            Priority 1:
              -> ppfTestRole3 (user1, user2) requestPolicy=A
              ----> ppfTestRole4 (testuser1, testuser2) requestPolicy=A - primary delegate
          

          Action Requests generated:

            (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10120)
              (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user1)
              (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user2)
              (actionRequested=A, forceAction=true, delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121)
                (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1)
                (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2)
          

          Maybe I need to twiddle forceAction to false on the two non-delegate requests (to user1 and user2)?

          Show
          Peter Giles (Inactive) added a comment - - edited Basic problem: When there is a Role member with requestPolicy=ALL having a a Role delegate with requestPolicy=ALL, the members and the delegates are all being required to approve. I don't think it should work that way, I think only the delegates should have to approve. PeopleFlow config: Priority 1: -> ppfTestRole3 (user1, user2) requestPolicy=A ----> ppfTestRole4 (testuser1, testuser2) requestPolicy=A - primary delegate Action Requests generated: (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10120) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user1) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user2) (actionRequested=A, forceAction= true , delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2) Maybe I need to twiddle forceAction to false on the two non-delegate requests (to user1 and user2)?
          Hide
          Peter Giles (Inactive) added a comment -

          Talked to Eric W. and I have an idea how to restructure the action request graph to make it work as expected. Basically, I need separate delegation request for each member of the role, so the graph would instead look something like:

           (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10120)
              (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user1)
                (actionRequested=A, forceAction=true, delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121)
                  (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1)
                  (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2)
              (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user2)
                (actionRequested=A, forceAction=true, delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121)
                  (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1)
                  (actionRequested=A, forceAction=true, nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2)
          

          I was wishfully thinking that I could just hang a single delegation sub-tree off of the parent role request.

          Show
          Peter Giles (Inactive) added a comment - Talked to Eric W. and I have an idea how to restructure the action request graph to make it work as expected. Basically, I need separate delegation request for each member of the role, so the graph would instead look something like: (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10120) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user1) (actionRequested=A, forceAction= true , delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10120, principalId=user2) (actionRequested=A, forceAction= true , delegationType=P nodeName=PeopleFlows, recipientType=R, requestPolicy=A, roleName=10121) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser1) (actionRequested=A, forceAction= true , nodeName=PeopleFlows, recipientType=U, requestPolicy=A, roleName=10121, principalId=testuser2) I was wishfully thinking that I could just hang a single delegation sub-tree off of the parent role request.
          Hide
          Peter Giles (Inactive) added a comment -

          I made another commit last night with fixes and cleanup. The only thing outstanding is the integration test, which should be committed shortly.

          Show
          Peter Giles (Inactive) added a comment - I made another commit last night with fixes and cleanup. The only thing outstanding is the integration test, which should be committed shortly.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          talked with Peter and the work on the feature here is complete and he's finishing up the integration test.

          Show
          Jessica Coltrin (Inactive) added a comment - talked with Peter and the work on the feature here is complete and he's finishing up the integration test.
          Hide
          Peter Giles (Inactive) added a comment -

          Integration test is committed. I am going to resolve, but will create a code review. I'll open a separate jira for any changes that come out of the code review.

          Show
          Peter Giles (Inactive) added a comment - Integration test is committed. I am going to resolve, but will create a code review. I'll open a separate jira for any changes that come out of the code review.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week, 2 days, 4 hours
                1w 2d 4h
                Remaining:
                Time Spent - 2 days, 4 hours Remaining Estimate - 1 week
                1w
                Logged:
                Time Spent - 2 days, 4 hours Remaining Estimate - 1 week
                2d 4h

                  Agile

                    Structure Helper Panel