Details
-
Type:
Bug Fix
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.0.1.1
-
Fix Version/s: Backlog
-
Component/s: Development, Version Compatibility
-
Labels:
-
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)){
isUserInRouteLog =
principalId.equals(workflowInfo.getDocumentInitiatorPrincipalId(documentNumberLong));
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).
Attachments
Issue Links
- relates to
-
-
- Closed
-
- Trackbacks
-
![[Confluence: Kuali Environment Management]](/images/icons/generic_link_16.png "[Confluence: Kuali Environment Management]")
KFS 3.0.1 and Rice integration issues
Summary Cornell has an existing production Rice installation (Cynergy). Since initial implementation,...
Activity
| Field | Original Value | New Value |
|---|---|---|
| Summary | Document initiator check fails with KIM is run in remote mode | Document initiator check fails when KIM is run in remote mode |
| Priority | Major [ 3 ] | Critical [ 2 ] |
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.
| Assignee | Eric Westfall [ ewestfal ] | |
| Fix Version/s | 1.0.3 [ 15646 ] |
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.
I think this is going to be too much to chew for 1.0.3. Moving to 1.1
| Fix Version/s | 1.1 [ 14190 ] | |
| Fix Version/s | 1.0.3 [ 15646 ] |
| Link |
This issue relates to |
| Fix Version/s | 1.1? [ 15811 ] | |
| Fix Version/s | 1.1 [ 14190 ] |
| Fix Version/s | 1.1? [ 15811 ] |
| Fix Version/s | 1.1 [ 14190 ] |
| Component/s | Version Compatibility [ 13202 ] |
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.
| Fix Version/s | 2.x [ 15811 ] | |
| Fix Version/s | 2.0 [ 14190 ] |
| Start Date | ||
| Fix Date | [ set to sprint end date ] |
| Assignee | Eric Westfall [ ewestfal ] |
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Workflow | custom [ 84649 ] | Copy of custom for rice [ 206903 ] |
| Workflow | Copy of custom for rice [ 206903 ] | custom [ 216651 ] |
| Workflow | custom [ 216651 ] | Rice Workflow [ 226399 ] |
| Fix Version/s | Middleware Backlog [ 17860 ] | |
| Fix Version/s | Backlog [ 15811 ] |
| Fix Version/s | Backlog [ 15811 ] | |
| Fix Version/s | Middleware Backlog [ 17860 ] |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Labels | Old |
Increasing to critical as this is significantly impacting our KFS implementation project.