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

Role qualifier validation being ignored when assigning a role as a member

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.1.2
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4899Cannot add member to role because qualifiers are not being checked for uniqueness
      KULRICE-12836Role qualifiers lost on role maintenance document
      KULRICE-4830Duplicate Emails are sent out when Role Member changes for Roles with Qualifiers. Also, route log shows duplicate member listings.
      KULRICE-10304Using empty role qualifiers causes "cannot be modified" validation error when adding delegates for associated member
      KULRICE-7749Unable to inactivate Role Assignment from a Person record when the qualifier data does not validate
      KULRICE-3989UIDocumentService.loadRoleMemberQualifiers - is there a way to load qualifiers not associated with the role type
      KULRICE-10640BusinessObjectAuthorizationServiceImpl unmask methods do not consult authorizers for role qualifiers
      KULRICE-7689Performance issue with KRIM Document Qualified Roles
      KULRICE-12397Role document UI allows a role to be assigned to itself.
      KULRICE-6565Fix qualifiers on role for Person and Role Documents
    • Rice Module:
      KIM
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      So, one of our users discovered that, when you add a role to another role, the qualifiers are not being validated. The code is pretty clear:

              if ( kimTypeService != null && !newMember.isRole()) {
          		List<RemotableAttributeError> localErrors = kimTypeService.validateAttributes( document.getKimType().getId(), attributeValidationHelper.convertQualifiersToMap( newMember.getQualifiers() ) );
      

      I'm assuming we did this because we often have roles nested in other roles and want to be able to leave off the qualifiers so they can be evaluated by the "downstream" role.

      However, this is allowing invalid data to be entered. I'm not sure of the best solution for this. It seems that we should still validate any data which was entered, but not enforce the "required" nature of the attributes.

      So, the decision is to where the responsibility for this validation should be. Should this be a standard part of the KIM documents? Or, should it be with the role type service?

      The problem with the latter (at present) is that the validateAttributes() method does not know what type of member it is validating for. We would need to add a new API method to the RoleTypeService which took the member type, member ID, and start/end dates (may as well be complete) which would be called if present. (It would just call the existing method for now.)

      The other API option would be another boolean: shouldValidateQualifiersForMemberType( MemberType )

      I'm not sure what is best from the API standpoint. I'm sure the 2nd is easier and I don't really have any use cases for the complexity of the first one.

        Issue Links

          Activity

          Hide
          Jonathan Keller added a comment -

          Part of the original problem was that we could not edit roles which had a mix of persons and nested roles. The document was insisting that we add qualifiers to the role member.

          Show
          Jonathan Keller added a comment - Part of the original problem was that we could not edit roles which had a mix of persons and nested roles. The document was insisting that we add qualifiers to the role member.
          Hide
          Steve Manning (Inactive) added a comment -

          I touched base with Bryan H. for validation, it looks like everything is working as needed now.

          Show
          Steve Manning (Inactive) added a comment - I touched base with Bryan H. for validation, it looks like everything is working as needed now.
          Hide
          Eric Westfall added a comment -

          The commit done on this issue has broken version compatibility. Please follow the guidelines for evolving callback services as described here:

          https://wiki.kuali.org/display/KULRICE/Maintaining+Version+Compatibility+in+Kuali+Rice

          Show
          Eric Westfall added a comment - The commit done on this issue has broken version compatibility. Please follow the guidelines for evolving callback services as described here: https://wiki.kuali.org/display/KULRICE/Maintaining+Version+Compatibility+in+Kuali+Rice
          Hide
          Steve Manning (Inactive) added a comment -

          Resolving as backwards compatibility should no longer be an issue

          Show
          Steve Manning (Inactive) added a comment - Resolving as backwards compatibility should no longer be an issue
          Hide
          Jessica Coltrin (Inactive) added a comment -

          closing all 2.1.2 Jiras

          Show
          Jessica Coltrin (Inactive) added a comment - closing all 2.1.2 Jiras

            People

            • Assignee:
              Steve Manning (Inactive)
              Reporter:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

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

                  Structure Helper Panel