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

When editing a role, the app allows you to add the same user multiple times in the assignee section.

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.3
    • Fix Version/s: 2.0.2, 2.1.2
    • Component/s: Sample Application
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-7303Able to add assignees to Derived Roles
      KULRICE-8542Person, role & group docs should not allow multiple docs editing the same record to be saved at the same time
      KULRICE-3610can't remove assignees using the Role or Group maintenance pages
      KULRICE-8478Role Maintenance Document: Add ability to search on future or inactive assignees
      KULRICE-8391Screen to edit multiple parameters at the same time
      KULRICE-12079Allow for editing of collection rows via modal
      KULRICE-12397Role document UI allows a role to be assigned to itself.
      KULRICE-4393roles, principals and groups can't be inquired on when in KIM inquiry screens
      KULRICE-7092KIM Role Doc Regression: not auto-looking up principal ID upon role member add line
      KULRICE-8760CONTRIB: Multiple complete adhoc requests should not be allowed on the same document
    • Rice Module:
      KIM
    • Application Requirement:
      KFS, Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      When editing a role, you can add the same user even if they are already assigned and active. You can also add the same user multiple times within a single submit.

        Issue Links

          Activity

          Hide
          Jeff Ruch added a comment -

          It was identified that this fix causes problems with KFS roles. The fix was removed.

          Show
          Jeff Ruch added a comment - It was identified that this fix causes problems with KFS roles. The fix was removed.
          Hide
          Ken Geis added a comment -

          I'm having the same problem in Kuali Coeus. Is there a Rice issue that corresponds to removing this fix? KC 5.0.1 is running Rice 2.1.1, and I'm hoping that I can work around the issue by dropping in Rice 2.1.2, but it's not clear from what I read here.

          Show
          Ken Geis added a comment - I'm having the same problem in Kuali Coeus. Is there a Rice issue that corresponds to removing this fix? KC 5.0.1 is running Rice 2.1.1, and I'm hoping that I can work around the issue by dropping in Rice 2.1.2, but it's not clear from what I read here.
          Hide
          Ken Geis added a comment -

          Why was this marked "Won't Fix?" This is important to fix. The reason the fix causes problems with KFS roles is because the fix was buggy.

          Show
          Ken Geis added a comment - Why was this marked "Won't Fix?" This is important to fix. The reason the fix causes problems with KFS roles is because the fix was buggy.
          Hide
          Jonathan Keller added a comment -

          What's the use case where adding the duplicate causes problems? (besides aesthetic)

          I'm trying to remember the decision now. KFS had the immediate problem that we could not edit our roles so it was just backed out. Part of the problem was that there is question when this validation should be enforced.

          Slowly coming back...I think part of the issue was with inactivated role members. Since we would not want to lose the history of role member changes, we would not use an old role member record just because the qualifiers matched. But, nor would we want to block the creation of the new role member.

          We also had the possibility of the role type services wanting to make that decision rather than KIM itself in some form of literal qualifier matching.

          Short answer: We need to figure out exactly what we want KIM to do before tackling this again.

          Show
          Jonathan Keller added a comment - What's the use case where adding the duplicate causes problems? (besides aesthetic) I'm trying to remember the decision now. KFS had the immediate problem that we could not edit our roles so it was just backed out. Part of the problem was that there is question when this validation should be enforced. Slowly coming back...I think part of the issue was with inactivated role members. Since we would not want to lose the history of role member changes, we would not use an old role member record just because the qualifiers matched. But, nor would we want to block the creation of the new role member. We also had the possibility of the role type services wanting to make that decision rather than KIM itself in some form of literal qualifier matching. Short answer: We need to figure out exactly what we want KIM to do before tackling this again.
          Hide
          Ken Geis added a comment -

          There is a distinction between aesthetic and usability. Aesthetics often improve usability, but this not simply an aesthetic issue. It is an issue of making the data correct and easy to work with. I see a general lack of usability in Kuali software, and I think a lack of appreciation that usability inherently drives value. I am currently unwilling to let some of my top business users work with KIM roles because they have been getting the data entry wrong. This would be a step in helping them get it right and eliminating a key bottleneck at my institution.

          So the fix needed to be backed out because it did not take qualifications into account at all, but also because it did not consult the role type services. Regarding what to do with inactivated role members, where does the decision about what to do happen? Can we discuss it here? I would say that a new role member would default its Active Date to today, and then the duplicate checking would also involve checking for overlapping date ranges. Therefore, if a member was inactivated a month ago, and a new member was created today with the same [type, id, qualification], it would not be a duplicate because the date range would not overlap.

          Can we reopen this issue or another one instead of marking it Won't Fix?

          Show
          Ken Geis added a comment - There is a distinction between aesthetic and usability. Aesthetics often improve usability, but this not simply an aesthetic issue. It is an issue of making the data correct and easy to work with. I see a general lack of usability in Kuali software, and I think a lack of appreciation that usability inherently drives value. I am currently unwilling to let some of my top business users work with KIM roles because they have been getting the data entry wrong. This would be a step in helping them get it right and eliminating a key bottleneck at my institution. So the fix needed to be backed out because it did not take qualifications into account at all, but also because it did not consult the role type services. Regarding what to do with inactivated role members, where does the decision about what to do happen? Can we discuss it here? I would say that a new role member would default its Active Date to today, and then the duplicate checking would also involve checking for overlapping date ranges. Therefore, if a member was inactivated a month ago, and a new member was created today with the same [type, id, qualification] , it would not be a duplicate because the date range would not overlap. Can we reopen this issue or another one instead of marking it Won't Fix?

            People

            • Assignee:
              Jeff Ruch
              Reporter:
              Jeff Ruch
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel