Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-4303

Document initiator check fails when KIM is run in remote mode

    Details

    • 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

            Activity

            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            Increasing to critical as this is significantly impacting our KFS implementation project.

            Show
            ahamid Aaron Hamid (Inactive) added a comment - Increasing to critical as this is significantly impacting our KFS implementation project.
            Hide
            ewestfal Eric Westfall added a comment -

            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.

            Show
            ewestfal Eric Westfall added a comment - 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.
            Hide
            ewestfal Eric Westfall added a comment -

            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.

            Show
            ewestfal Eric Westfall added a comment - 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.
            Hide
            ewestfal Eric Westfall added a comment -

            I think this is going to be too much to chew for 1.0.3. Moving to 1.1

            Show
            ewestfal Eric Westfall added a comment - I think this is going to be too much to chew for 1.0.3. Moving to 1.1
            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            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.

            Show
            ahamid Aaron Hamid (Inactive) added a comment - 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                ahamid Aaron Hamid (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: