Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-2415

implement KR-WKFLW permission and responsibility checks

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-8759CONTRIB: Make sure (KR-WKFLW "Ad Hoc Review Document") set up for Adhoc routing for completion
      KULRICE-4327unable to find parameter: KR-WKFLW / CONFG / FROM_ADDRESS
      KULRICE-3984Cancel Document permission does not work
      KULRICE-4219Improvements to Permission and Responsibility maintenance
      KULRICE-7000Permission and Responsibility NamespaceCode+Name must be unique but the maintenance documents do not check this
      KULRICE-2414double check the permissions and responsibilities ailish created for rice modules
      KULRICE-8300problems with implementation of super user tab
      KULRICE-12705IT Failure DerivedComponentTest There should be some components for the KR-WKFLW namespace
      KULRICE-7074Restore Permission/Role/Responsibility logging
      KULRICE-2416all rice actions should extend KualiAction, so these permissions are enforced - they replace any existing app constants or configuration related to rice authz - please double check for any i missed
    • Rice Module:
      Rice Core, KSB, KNS, KEW, KEN, KCB, KIM, KOM
    • Application Requirement:
      KFS, KC, KS, Rice

      Description

      1. workflow should accept a KIM responsibility with template KR-WKFLW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type

      2. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
      format is template (attributes) - notes
      KR-WKFLW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
      KR-WKFLW Administer Routing for Document (Document Type) - this is super use permission
      KR-WKFLW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
      KR-WKFLW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
      KR-WKFLW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
      KR-WKFLW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
      KR-WKFLW Save Document (Document Routing Node & State) - this is an alternate for the policy

        Issue Links

          Activity

          Hide
          Eric Westfall added a comment -

          The only issue is that KEW relies on defaults rather than requiring specification of all document type policies. So, for example, the default for "initiator must route" is "true". However, the person defining the document type doesn't have to specify that (and it doesn't get written to the policy table automatically in any way, the code handles the defaulting if no value is defined). Most documents types would not have explicitly set initiator must route to true. So, if I just went to KIM first, is authorized would always return "false". Then as soon as I put these changes in, no one would be able to route any documents, let alone initiate them (providing the kim permissions weren't defined ahead of time).

          Regarding save, that sounds fine to me. It indicated using the route node name in the description of this jira but it could just be out of sync as you mentioned earlier When I saw that I was thinking you might want to restrict who could save at certain nodes. I can remove the node part of it though. THanks.

          Show
          Eric Westfall added a comment - The only issue is that KEW relies on defaults rather than requiring specification of all document type policies. So, for example, the default for "initiator must route" is "true". However, the person defining the document type doesn't have to specify that (and it doesn't get written to the policy table automatically in any way, the code handles the defaulting if no value is defined). Most documents types would not have explicitly set initiator must route to true. So, if I just went to KIM first, is authorized would always return "false". Then as soon as I put these changes in, no one would be able to route any documents, let alone initiate them (providing the kim permissions weren't defined ahead of time). Regarding save, that sounds fine to me. It indicated using the route node name in the description of this jira but it could just be out of sync as you mentioned earlier When I saw that I was thinking you might want to restrict who could save at certain nodes. I can remove the node part of it though. THanks.
          Hide
          Eric Westfall added a comment -

          After discussion with Ailish, they would like a mechanism which disables the checking if a KIM permission is defined before using KIM. I will define a system parameter with the name KIM_PRIORITY_ON_DOC_TYP_PERMS_IND. If the system parameter does not exist then it will behave as if it's value was set to "N"

          Show
          Eric Westfall added a comment - After discussion with Ailish, they would like a mechanism which disables the checking if a KIM permission is defined before using KIM. I will define a system parameter with the name KIM_PRIORITY_ON_DOC_TYP_PERMS_IND. If the system parameter does not exist then it will behave as if it's value was set to "N"
          Hide
          Eric Westfall added a comment -

          Moved exception routing piece to KULRICE-2456 so I can resolve this particular issue.

          Show
          Eric Westfall added a comment - Moved exception routing piece to KULRICE-2456 so I can resolve this particular issue.
          Hide
          Eric Westfall added a comment -

          Based on a discussion in the KTI today, I changed the default of the system parameter so that it would behave as if it was set to "Y". That way once someone has converted they could completely remove the parameter from the database if they really wanted to (goal was to avoid clutter in this table I believe).

          Show
          Eric Westfall added a comment - Based on a discussion in the KTI today, I changed the default of the system parameter so that it would behave as if it was set to "Y". That way once someone has converted they could completely remove the parameter from the database if they really wanted to (goal was to avoid clutter in this table I believe).
          Hide
          Eric Westfall added a comment -

          Bulk change of all Rice 1.0 issues to closed after public release.

          Show
          Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

            People

            • Assignee:
              Eric Westfall
              Reporter:
              Ailish Byrne
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Structure Helper Panel