Uploaded image for project: '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
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • 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.

        Attachments

          Issue Links

            Activity

            Hide
            jksmith 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
            jksmith 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
            jkeller 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
            jkeller 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
            jkeller Jonathan Keller added a comment -

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

            Show
            jkeller Jonathan Keller added a comment - Travis - and also the removal of principalInactivated() from the RoleTypeService interface. (Which I assume was related.)
            Hide
            jksmith 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
            jksmith 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
            jksmith 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
            jksmith 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:
                jksmith James Smith
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: