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

enhance the responsibility document to automate changes to the location of action details

    Details

    • Similar issues:
      KULRICE-6946Responsibility data of the "Responsibility Details" section does not persist
      KULRICE-6906Responsibility Document doesn't save details
      KULRICE-1346Implement changes needed to Document Search and Document Search Helper Classes for KRA enhancements requested
      KULRICE-7738Responsibility Actions not appearing when adding a person to a role with action details defined at role member level
      KULRICE-2868Implement Document Requeue to refresh requets whenever a responsibility is changed in KIM
      KULRICE-4874roles with multiple responsibilities specifying action details at the role member level
      KULRICE-13704Create Automated Functional (Smoke) Tests for Action List: Responsibility
      KULRICE-2210Fix location of document header population
      KULRICE-7458Restore the display of permission/responsibility details on KIM Inquiries
      KULRICE-2802Update the rule QuickLinks page to support KIM responsibilities, roles, and permissions at the document type level
    • Epic Link:
    • Rice Module:
      KIM
    • Application Requirement:
      KFS

      Description

      Add some logic to update the current action records for a responsibility when a responsibility document changes the location of responsibility action details.

      See KFSMI-3131 for original discussion. From one of Jonathan's comments on that JIRA: "we could enhance the responsibility save to re-do the current action records upon a save. That has its own complications, though. Going from non-role-member to role-member assignment is easy, we simply apply the current setting to all members. However, going the other way could be tricky."

        Issue Links

          Activity

          Hide
          Eric Westfall added a comment -

          Garey, can you follow-up with Dan and see what the priority of this issue is? It seems like a possible candidate for deferral to me. Thanks.

          Show
          Eric Westfall added a comment - Garey, can you follow-up with Dan and see what the priority of this issue is? It seems like a possible candidate for deferral to me. Thanks.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          Per email from Dan Lemus, this is needed for 1.0.3.1 and here's more description below. Please speak with Jonathan Keller if there are further questions.

          There is currently a relationship between the Role and Responsibility document to maintain Action Details at a certain level, role member or non-role member. This option is set on the Responsibility document by the field Action Details at Role Member Level, which currently is read-only and should become editable. So as Responsibility are added to a Role, lines are generated for Role-Responsibility based on the how the aforementioned field is set. This works fine, the problem comes into play when the Responsibility document is edited, and the field Action Details at Role Member Level is toggled. Going from non-role member based to role member based is doable, but going the opposite way proves to be tricky as each role member has its own set of data, and when we are dealing with non-role member based responsibilities the other attributes (in the role-responsibility table) most likely needs to be retrieved by asking the user, as there is not a way to derive the values from the existing role member based data.

          What is needed is a way to handle the regeneration of the Role-to-Responsibility data when the Action Details at Role Member Level field is toggled on the Responsibility document.

          Show
          Jessica Coltrin (Inactive) added a comment - Per email from Dan Lemus, this is needed for 1.0.3.1 and here's more description below. Please speak with Jonathan Keller if there are further questions. There is currently a relationship between the Role and Responsibility document to maintain Action Details at a certain level, role member or non-role member. This option is set on the Responsibility document by the field Action Details at Role Member Level, which currently is read-only and should become editable. So as Responsibility are added to a Role, lines are generated for Role-Responsibility based on the how the aforementioned field is set. This works fine, the problem comes into play when the Responsibility document is edited, and the field Action Details at Role Member Level is toggled. Going from non-role member based to role member based is doable, but going the opposite way proves to be tricky as each role member has its own set of data, and when we are dealing with non-role member based responsibilities the other attributes (in the role-responsibility table) most likely needs to be retrieved by asking the user, as there is not a way to derive the values from the existing role member based data. What is needed is a way to handle the regeneration of the Role-to-Responsibility data when the Action Details at Role Member Level field is toggled on the Responsibility document.
          Hide
          Jeremy Hanson added a comment -

          Would it be feasible to get a more detailed description of what should happen when this is toggled each way?

          Show
          Jeremy Hanson added a comment - Would it be feasible to get a more detailed description of what should happen when this is toggled each way?
          Hide
          Jonathan Keller added a comment -

          When moving from false to true:

          There will be a single record in the KRIM_ROLE_RSP_ACTN_T for each permission/role combination. This would need to be exploded into a record per role member in that role using that single record as a model.

          Problem with this: Application roles. We would need to prevent the switch if any of the associated roles are application roles.

          When moving from true to false:

          We will have multiple rows and need to condense them down into one for each role/permission combination. I don't know that we have a spec for how to combine the rows if there are differences. I'd have to look at the table again to see, but probably the most restrictive (APPROVE over FYI, ALL over FIRST, etc...)

          Show
          Jonathan Keller added a comment - When moving from false to true: There will be a single record in the KRIM_ROLE_RSP_ACTN_T for each permission/role combination. This would need to be exploded into a record per role member in that role using that single record as a model. Problem with this: Application roles. We would need to prevent the switch if any of the associated roles are application roles. When moving from true to false: We will have multiple rows and need to condense them down into one for each role/permission combination. I don't know that we have a spec for how to combine the rows if there are differences. I'd have to look at the table again to see, but probably the most restrictive (APPROVE over FYI, ALL over FIRST, etc...)

            People

            • Assignee:
              Unassigned
              Reporter:
              Dan Lemus (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 3 days
                3d
                Remaining:
                Remaining Estimate - 3 days
                3d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel