Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1.1, KFS Release 3.0.1
    • Fix Version/s: 1.0.2.1, KFS Release 4.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4609Close/Cancel/Save button does not work correctly for Kim maintenance screens
      KULRICE-7257Lightbox close/cancel buttons not working
      KULRICE-12635Cancel of KRAD documens doesn't work
      KULRICE-8125Permission Lookup by Role Name not working
      KULRICE-5707Direct inquiry empty check not working and cancel on lightbox not working
      KULRICE-9214Incident Report page Cancel Button
      KULRICE-11284Partial Unmask Field permission does not work in KRAD
      KULRICE-8490Recall Routing permissions do not work with KC role qualifiers
      KULRICE-13224Hitting cancel after opening KRAD doc from document search throws an error
      KULRICE-4144The SaveActionEvent class returns an invalid error string when KIM Permission says a user can't cancel
    • Rice Module:
      KEW
    • Application Requirement:
      KFS

      Description

      I've found that you can't cancel a document without certain portions of the KFS dataset. You get an incident report every time you try The permission check for Cancel Document fails due to a lack of permission details. This didn't show up in KFS as delivered because of additional permissions that have been created in combination with the behavior of one of the permission type services. As part of our phased implementation, I disabled a large portion of the KFS KIM data until we need it. That's when this started happening.

      Here's what happens:

      When the workflow engine finally gets down to checking whether the user can cancel the document at this point in time, it performs a permission check (KR-WKFLW/Cancel Document) and passes in as details the document type, route node name, and document status. In the default KIM data, this permission is assigned to the document editor role which is a derived role based on the Edit Document permission. The edit document permission is then assigned to two roles, "KR-WKFLW/Initiator" and "KR-WKFLW/Non-Ad Hoc Approve Request Recipient". Both of these roles require a document number (and principal ID) as a role qualifier, as they must inspect the route log. Without a document number, both of those roles immediately return false.

      In KFS' delivered data, the Edit Document permission is assigned to a number of other roles (including KFS-SYS/User) for specific document types. But, since no role qualifiers are passed (at all), the implementation of the permission type service assumes that it applies to all documents. (It skips the document type compare.) This allowed the cancel to work.

      The call with the problem is coming from: DocumentTypePermissionServiceImpl.canCancel() via CancelAction.validateActionRules()

      Below, you can see the KIM calls that proceed the failure. Note how all calls after the first are missing any form of details or qualifiers.

      2010-03-03 14:07:12,637 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.IdentityManagementServiceImpl ::
      Has Perm for Perm Templ: KR-WKFLW/Cancel Document
      Principal: 0000140286 (dshenn)
      Details:
      routeNodeName --> PreRoute
      documentTypeName --> AWRD
      routeStatusCode --> I

      2010-03-03 14:07:12,645 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.RoleManagementServiceImpl ::
      Has Role : [66]
      Name : KR-NS/Document Editor (66)
      Principal : 0000140286 (dshenn)
      Details :
      [null]

      2010-03-03 14:07:12,645 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.IdentityManagementServiceImpl ::
      Has Perm for Perm Templ: KR-NS/Edit Document
      Principal: 0000140286 (dshenn)
      Details:
      [null]

      2010-03-03 14:07:12,674 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.RoleManagementServiceImpl ::
      Has Role : [59, 59, 97, 60]
      Name : KR-WKFLW/Approve Request Recipient (59)
      Name : KR-WKFLW/Approve Request Recipient (59)
      Name : KR-WKFLW/Non-Ad Hoc Approve Request Recipient (97)
      Name : KR-WKFLW/Initiator (60)
      Principal : 0000140286 (dshenn)
      Details :
      [null]

      2010-03-03 14:07:12,692 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.RoleManagementServiceImpl :: Result: false
      2010-03-03 14:07:12,692 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.IdentityManagementServiceImpl :: Result: false
      2010-03-03 14:07:12,695 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.RoleManagementServiceImpl :: Result: false
      2010-03-03 14:07:12,695 [http-8080-Processor22] DEBUG org.kuali.rice.kim.service.impl.IdentityManagementServiceImpl :: Result: false

        Activity

        Hide
        Jonathan Keller added a comment -

        I attach the patch I've used locally. To fix, I had to add the document number to the API for the canCancel call and remove the cache checking which only worked off of document type, route status and route node. Then I could add the needed permission details and role qualifers as done by the canSave() method.

        Show
        Jonathan Keller added a comment - I attach the patch I've used locally. To fix, I had to add the document number to the API for the canCancel call and remove the cache checking which only worked off of document type, route status and route node. Then I could add the needed permission details and role qualifers as done by the canSave() method.

          People

          • Assignee:
            Jonathan Keller
            Reporter:
            Jonathan Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel