[KULRICE-4303] Document initiator check fails when KIM is run in remote mode Created: 07/Jul/10 Updated: 16/Jan/15 |
|
Status: | Open |
Project: | Kuali Rice Development |
Component/s: | Development, Version Compatibility |
Affects Version/s: | 1.0.1.1 |
Fix Version/s: | Backlog |
Type: | Bug Fix | Priority: | Major |
Reporter: | Aaron Hamid (Inactive) | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 0 |
Labels: | Old | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||
Rice Module: |
KNS, KEW, KIM
|
Description |
When an application has configured KIM in "remote" mode, permission checks that cross the service bus and occur in the Rice server and that depend on observing client Rice state (such as the document route header for initiator) will fail because client changes have not yet been committed to the database. For example, RouteLogDerivedRoleTypeServiceImpl.hasApplicationRole: if (INITIATOR_ROLE_NAME.equals(roleName)){ This will always fail for newly initiated documents, and the result will be that all new documents will be read only (because the current user is not seen to be the "initiator") regardless of any other permission setting. This is one such example, but it seems like a general problem and could be more widespread (any other state a client may save and the Rice standalone instance may be requested to operate on). |
Comments |
Comment by Aaron Hamid (Inactive) [ 08/Jul/10 ] |
Increasing to critical as this is significantly impacting our KFS implementation project. |
Comment by Eric Westfall [ 10/Jul/10 ] |
I'm not sure how much this is going to take, but I'm going to set to 1.0.3 for now. If it proves too impacting then i'll push to 1.1. |
Comment by Eric Westfall [ 10/Jul/10 ] |
For documentation purposes, wanted to mention on here that I discussed this with aaron via email, and I think that KIM in embedded mode is the best way for them to proceed in light of these issues as I'm not sure there is an easy solution to this one. I'd like to discuss with the KTI though and see what ideas everyone might have. |
Comment by Eric Westfall [ 24/Aug/10 ] |
I think this is going to be too much to chew for 1.0.3. Moving to 1.1 |
Comment by Aaron Hamid (Inactive) [ 17/Sep/10 ] |
FWIW we decided to switch to a batch feed integration for KIM identity data with KIM (at least identity service) in embedded mode, so this is not a blocker for us at the moment. |