Indicate the necessity for this enhancement. What does it accomplish?
When the RoleNode is creating the requests, it seems to include ones with null principals in the group member table. This causes and error as KEW attempts to create the user.
Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.
In general a null principal member ID should not exist, however there may be instances where loading data into KIM results in principals w/null member IDs. If these principals are part of a group, when KEW calls that group at a route node an error is generated. The example error is from KFS...
Two KRIM tables are not setup correctly at the moment and are allowing null values to be inserted, these are the root cause of the error and need to be updated to not allow these null values to prevent KIM from creating bad data. Additionally an informative error message needs to be produced to inform the user that there is bad data being passed in.
Include at least one usage scenario, from the user's task perspective, that might be helpful in understanding the issue:
After loading a large batch of users and groups, an institution inadvertently loaded a user with a null principal member ID. A new document created routed to a workgroup that the user is a member of and the eDoc errors out to exception.
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':
- Update KRIM_GRP_MBR_T to include a non null constraint on MBR_ID, MBR_TYP_CD, and GRP_ID
- Update KRIM_ROLE_MBR_T to include a non null constraint on MBR_ID, MBR_TYP_CD, and ROLE_ID
- There are possible situations where a principal id might fall out of a back-end LDAP implementation or similar in which case this table could have a reference to a principal ID which does not exist (this is a production issue that UC Davis has faced).
- Compromise is as follows:
- Add support for a "rice.kew.ignoreUnknownPrincipalIds" configuration parameter
- This should default to "false" (in common-config-defaults.xml)
- In the places in KEW where we get back a null or unknown principal id (which means if we try to resolve a principal from it, we get back a null id) if this parameter is "true" we essentially "ignore" the bad principal (but we do want to log a message at WARN with detailed information on this situation)
- If this configuration parameter is "false" we throw an exception as previously indicated
- Compromise is as follows:
- There is a class called IdentityHelperService or something like that in KEW which would be a logical place for this logic (or to add additional methods to support the requirements here)
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:
QA or Regression Testing Plan
List steps needed to test the basic functionality of this update, enhancement, bug fix
- load a principal with a blank member ID and load them into a workgroup
Functional Analysis Complete? YES (completed by SME)
Needs Review by KAI? NO (completed by SME)
Technical Analysis Complete? YES (completed by DM)
Needs Review by KTI? YES (completed by DM)
Estimate: 30 hours(completed by DM)
Technical Design: Link Here(completed by DM)
Jira: https://jira.kuali.org/browse/KULRICE-3307 (completed by SME)
Final Documentation: Link Here (completed by DM)
Added to QA: No (completed by SME)