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

KFS would like a callback when a principal has been inactivated

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-13150KRAD Inactivation Blocking error message references Struts
      KULRICE-7749Unable to inactivate Role Assignment from a Person record when the qualifier data does not validate
      KULRICE-7566Should consider if a principal should be allowed to have a null principal name
      KULRICE-10397Allow for callback methods for quickfinder (lookup) returns
      KULRICE-5784Group, Role, and Principal update methods need to call "inactivate" methods when their "active" status is changed to inactive
      KULRICE-3977bad application behavior when logging in as inactive principal
      KULRICE-6863KEW - The order of arguments for WorkflowDocument.returnToPreviousNode method has been reversed in 2.0
      KULRICE-971Callback is not called when store and forward is used.
      KULRICE-1343Question framework doesn't always return to where the user would want after the user has answered the question
      KULRICE-11848Inactivation Blocking doesn't work in KNS
    • Epic Link:
    • Rice Module:
      KIM
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      To solve some of the issues seen in KFSMI-12647, KFS would like to be called when a principal is inactivated. KFS could then inactivate derived role records and the like (for instance, the principal's tem profile) for that principal.

        Issue Links

          Activity

          Hide
          James Smith added a comment -

          Added Travis as a watcher, even though I know he's extremely busy with KC 6 right now and, considering the age of the change, may not have more than a vague memory of relevant details.

          Travis, we're wondering why RoleInternalServiceImpl#inactivateApplicationRoleMemberships doesn't do anything. Should it be calling the role type service somehow to have the client applications handle the inactivation of principals? Any help you could offer would be greatly appreciated, though - I'm well aware of the provisos I've listed above. Thank you Travis!

          And thank you, Jonathan, for tracking this down.

          Show
          James Smith added a comment - Added Travis as a watcher, even though I know he's extremely busy with KC 6 right now and, considering the age of the change, may not have more than a vague memory of relevant details. Travis, we're wondering why RoleInternalServiceImpl#inactivateApplicationRoleMemberships doesn't do anything. Should it be calling the role type service somehow to have the client applications handle the inactivation of principals? Any help you could offer would be greatly appreciated, though - I'm well aware of the provisos I've listed above. Thank you Travis! And thank you, Jonathan, for tracking this down.
          Hide
          Jonathan Keller added a comment -

          Regarding the performance issues:

          Here is what happens when role membership is changed.

          1) Workflow is notified upon the role member change as long as it is made though the KIM APIs. (So derived roles are not handled this way.)
          2) Workflow obtains all the KIM responsibility records attached to that role.
          3) Workflow pulls all documents for that document type (and hierarchy) and route node on the responsibility and refreshes their routing. This can be thousands of documents. Further, each role update triggers the full refresh. So, if a number come through all at once, you could have tens of thousands of updates queued up.
          4) This queuing may happen on the Rice server - not KFS. So, it's sending all these messages to the KFS servers. (It depends on whether the KIM screens or KIM API are in use. KIM runs embedded - so API updates run from the server that made the changes.)

          This is an inherent problem with workflow as there is no way to tell which documents will be affected by any given role change.

          UCD has made two mitigations:

          1) The requeue was refreshing PROCESSED and FINAL documents. (FYI and ACK) We decided that was unnecessary and changed it to only ENROUTE documents. This reduced the load by about 75%. (8000 documents, only 2000 ENROUTE)

          2) We added a deduplicator to the queue. As the documents are being added to the queue to be processed, we first check that the document is not already there. That reduced the amount of reloading when there were multiple approvals of the KFS org review document in a short period of time. (BTW - we are talking a couple hours to process through all those enrollee documents.)

          Show
          Jonathan Keller added a comment - Regarding the performance issues: Here is what happens when role membership is changed. 1) Workflow is notified upon the role member change as long as it is made though the KIM APIs. (So derived roles are not handled this way.) 2) Workflow obtains all the KIM responsibility records attached to that role. 3) Workflow pulls all documents for that document type (and hierarchy) and route node on the responsibility and refreshes their routing. This can be thousands of documents. Further, each role update triggers the full refresh. So, if a number come through all at once, you could have tens of thousands of updates queued up. 4) This queuing may happen on the Rice server - not KFS. So, it's sending all these messages to the KFS servers. (It depends on whether the KIM screens or KIM API are in use. KIM runs embedded - so API updates run from the server that made the changes.) This is an inherent problem with workflow as there is no way to tell which documents will be affected by any given role change. UCD has made two mitigations: 1) The requeue was refreshing PROCESSED and FINAL documents. (FYI and ACK) We decided that was unnecessary and changed it to only ENROUTE documents. This reduced the load by about 75%. (8000 documents, only 2000 ENROUTE) 2) We added a deduplicator to the queue. As the documents are being added to the queue to be processed, we first check that the document is not already there. That reduced the amount of reloading when there were multiple approvals of the KFS org review document in a short period of time. (BTW - we are talking a couple hours to process through all those enrollee documents.)
          Hide
          Jonathan Keller added a comment -

          Travis - and also the removal of principalInactivated() from the RoleTypeService interface. (Which I assume was related.)

          Show
          Jonathan Keller added a comment - Travis - and also the removal of principalInactivated() from the RoleTypeService interface. (Which I assume was related.)
          Hide
          James Smith added a comment -

          Those issues I remember and having those performance mitigation solutions sound really helpful. The other thing we really need, though, is the ability to inactivate records on the KFS side related to derived roles (inactivate is probably too specific; if an FO inactivated, I'm guessing that in addition to rerouting docs, we'd need to e-mail people, maybe fail all of those documents...curious how institutions handle this; I'll check back on our side about that.)

          Show
          James Smith added a comment - Those issues I remember and having those performance mitigation solutions sound really helpful. The other thing we really need, though, is the ability to inactivate records on the KFS side related to derived roles (inactivate is probably too specific; if an FO inactivated, I'm guessing that in addition to rerouting docs, we'd need to e-mail people, maybe fail all of those documents...curious how institutions handle this; I'll check back on our side about that.)
          Hide
          James Smith added a comment -

          Though...regardless of research on the KFS side...it's still fairly obvious that we need some kind of hook.

          Show
          James Smith added a comment - Though...regardless of research on the KFS side...it's still fairly obvious that we need some kind of hook.

            People

            • Assignee:
              Unassigned
              Reporter:
              James Smith
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel