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

UIDocumentService.loadRoleMemberQualifiers - is there a way to load qualifiers not associated with the role type

    Details

    • Similar issues:
      KULRICE-7082KIM role document not handling missing qualifiers on role members
      KULRICE-4416Need a way to view a person, group or roles permissions and responsibilities and their sources
      KULRICE-12836Role qualifiers lost on role maintenance document
      KULRICE-10640BusinessObjectAuthorizationServiceImpl unmask methods do not consult authorizers for role qualifiers
      KULRICE-8490Recall Routing permissions do not work with KC role qualifiers
      KULRICE-4178Some role qualifiers displaying incorrectly
      KULRICE-2225Create interfaces for the Role Type and Attributes
      KULRICE-10304Using empty role qualifiers causes "cannot be modified" validation error when adding delegates for associated member
      KULRICE-9165Person document not displaying role qualifiers
      KULRICE-4581Update KIM role type service API for detection of invalid nesting
    • Rice Module:
      KIM
    • Application Requirement:
      KC

      Description

      This was discussed at the KTI on 2/24: https://test.kuali.org/confluence/x/GIDZAQ

      Here's the issue as described by Chitra:

      --------------------------------------------------------------------
      Hi All,

      KRACOEUS-3283 is in the KTI agenda queue from KC team. And I just wanted to give an overview of the problem.

      We basically need UIDocumentService's loadRoleMemberQualifiers method changed slightly.

      Issue Description:
      All the KC Kim Roles are basically of type Unit or Unit Hierarchy - which are qualified by a Unit Number / by a combination of Unit Number and Descend Flag depending on which one of the 2 types they belong to. In KC, we can grant Role Memberships using 2 mechanisms -
      a) Using the Person / Role Management screens.

      b) Some of the KC roles are document scoped. These Role Memberships can also be granted from within a Transactional Document and such memberships are effective only within that document.

      For the Document scoped Roles, even when a membership is granted at the Unit Hierarchy level thru the KIM screens, it is treated like a template.
      So, that membership record (qualified by the Unit Number or Unit Number / Descend Flag combo) by itself does not grant any permissions to the user. Only when the Transactional documents are created under the applicable Unit Hierarchy, the templates are referred and actual Role memberships (qualified by the Document Key) are created, which are again effective only within that document.

      Now, the issue is when we attempt to edit any of these document scoped Roles thru the Role Management screen. All the associated Role Members are displayed - which includes unit Number qualified template records as well as document Key qualified membership records.
      And it becomes a issue because the required attribute validation fails for those records qualified by the document Key.
      But they are valid role-memberships for that Role.

      So, we want to check if we can modify the behavior of UIDocumentService's loadRoleMemberQualifiers method - so that it returns all Role Member qualifications that are present rather than filtering only applicable qualifiers based on the Role type.

      This way, we can override the validateAttributes method within our Role type services and customize the validations as necessary.

      Note:
      We just need this method to be reverted back to 6432 revision (in essence). The change was made with a non jira comment and we would like to know if this could be reverted back to the old implementation. This would help solve our KIM issue.
      ---------------------------------------------------------------------------------------------------------

      The question that was brought up at the KTI was whether the UI would be able to support this behavior. Resolution was that a Rice dev would work with Chitra to investigate and come up with a solution if possible.

        Activity

        Hide
        Daniel Seibert (Inactive) added a comment -

        Hi Daniel,

        Pls find my response inline to your points.

        Regards,
        Chitra

        From: Seibert, Daniel dseibert@ucsd.edu
        Sent: Friday, March 19, 2010 7:36 PM
        To: Chandran, Chitraprabha
        Subject: FW: UIDocumentService

        Hi Chitra,

        So, if I understand your comments on the testing, there were three side effects caused by the change:

        1. Null Ptrs in IdentityManagementRoleDocumentRule.figureOutUniqueQualificationSet()
        This one seems straight forward, just check for a null ptr, before attempting to add to the uniqueAttributeIds set. (Don't add any of the qualifiers without attributes)

        n Similar Null check also need to be included in IdentityManagementPersonDocumentRule.findUniqueQualificationAttributes

        2. Null Ptrs in KimDocumentRoleMember.getQualifierAsAttributeSet()
        I don't fully understand this one. Is the problem that we are attempting to include the "empty" qualifiers (those without attributes) in the attribute set, or is it with the qualifiers with the new attributes (that have yet to be persisited)? - it is the second case.

        n This Null pointer occurred only when creating a new Role (upon submission of the new Role document). So, the un-materialized attribute reference was for the new Qualifier getting added. This would be the mapped attribute since we get to add only mapped attributes in a Role document.

        3. Person Maintenance screen / UIDocumentService.populateDocRoleQualifier.
        I think not populating the empty records may have other side effects.
        I looked at the revision history, and it appears that code to add the empty qualifiers was added to address KFSMI-2452 where the Person Document JSP was not getting rendered properly.

        n Regd this one, I went thru the KFSMI-2452 jira comments and I understand the issue they have described here. But in my opinion, it is logically different from what we are trying to fix. The scenario described there, I think, applies for a case where if a RoleType is tied to 3 attributes (for e.g. Role User is tied to Namespace, Organization Code and Chart code) and if one of them does not have any value for a membership. In this case, it is being stated that an empty string be displayed for it . I am not sure if this should apply to a case where the membership is qualified by a different set of qualifiers. Is it possible to not populate those empty qualifiers at least in the second case?

        I really should try to recreate this scenario in my Rice standalone server so I can fully understand what's going on, and what the potential side effects are.
        (Pls let me know if you need anything from me to duplicate this on your side.)

        Show
        Daniel Seibert (Inactive) added a comment - Hi Daniel, Pls find my response inline to your points. Regards, Chitra From: Seibert, Daniel dseibert@ucsd.edu Sent: Friday, March 19, 2010 7:36 PM To: Chandran, Chitraprabha Subject: FW: UIDocumentService Hi Chitra, So, if I understand your comments on the testing, there were three side effects caused by the change: 1. Null Ptrs in IdentityManagementRoleDocumentRule.figureOutUniqueQualificationSet() This one seems straight forward, just check for a null ptr, before attempting to add to the uniqueAttributeIds set. (Don't add any of the qualifiers without attributes) n Similar Null check also need to be included in IdentityManagementPersonDocumentRule.findUniqueQualificationAttributes 2. Null Ptrs in KimDocumentRoleMember.getQualifierAsAttributeSet() I don't fully understand this one. Is the problem that we are attempting to include the "empty" qualifiers (those without attributes) in the attribute set, or is it with the qualifiers with the new attributes (that have yet to be persisited)? - it is the second case. n This Null pointer occurred only when creating a new Role (upon submission of the new Role document). So, the un-materialized attribute reference was for the new Qualifier getting added. This would be the mapped attribute since we get to add only mapped attributes in a Role document. 3. Person Maintenance screen / UIDocumentService.populateDocRoleQualifier. I think not populating the empty records may have other side effects. I looked at the revision history, and it appears that code to add the empty qualifiers was added to address KFSMI-2452 where the Person Document JSP was not getting rendered properly. n Regd this one, I went thru the KFSMI-2452 jira comments and I understand the issue they have described here. But in my opinion, it is logically different from what we are trying to fix. The scenario described there, I think, applies for a case where if a RoleType is tied to 3 attributes (for e.g. Role User is tied to Namespace, Organization Code and Chart code) and if one of them does not have any value for a membership. In this case, it is being stated that an empty string be displayed for it . I am not sure if this should apply to a case where the membership is qualified by a different set of qualifiers. Is it possible to not populate those empty qualifiers at least in the second case? I really should try to recreate this scenario in my Rice standalone server so I can fully understand what's going on, and what the potential side effects are. (Pls let me know if you need anything from me to duplicate this on your side.)
        Hide
        Daniel Seibert (Inactive) added a comment -

        Modifed UIDocumentServiceImpl.populateDocRoleQualifier() to return an empty list if all of the qualifier attribute values are empty. This will prevent dynamic qualifiers from being displayed in the Role Membership tab on the Person Maintenance screen.

        Thank you Chitra for all of your help. It was invaluable!!

        Show
        Daniel Seibert (Inactive) added a comment - Modifed UIDocumentServiceImpl.populateDocRoleQualifier() to return an empty list if all of the qualifier attribute values are empty. This will prevent dynamic qualifiers from being displayed in the Role Membership tab on the Person Maintenance screen. Thank you Chitra for all of your help. It was invaluable!!
        Hide
        Kuali RIce Hudson (Inactive) added a comment -

        Integrated in UT-1.0-kc-oracle #14 (See http://ci.rice.kuali.org/job/UT-1.0-kc-oracle/14/)
        KULRICE-3989 modified populateDocRoleQualifier() to return an empty list if all of the qualifiers are empty. This is to prevent dynamic qualifiers from being displayed in the Role Membership tab in the Person Maintenance screen.

        Show
        Kuali RIce Hudson (Inactive) added a comment - Integrated in UT-1.0-kc-oracle #14 (See http://ci.rice.kuali.org/job/UT-1.0-kc-oracle/14/ ) KULRICE-3989 modified populateDocRoleQualifier() to return an empty list if all of the qualifiers are empty. This is to prevent dynamic qualifiers from being displayed in the Role Membership tab in the Person Maintenance screen.
        Hide
        Kuali RIce Hudson (Inactive) added a comment -

        Integrated in UT-1.0-kc-oracle #28 (See http://ci.rice.kuali.org/job/UT-1.0-kc-oracle/28/)
        KULRICE-3989

        Show
        Kuali RIce Hudson (Inactive) added a comment - Integrated in UT-1.0-kc-oracle #28 (See http://ci.rice.kuali.org/job/UT-1.0-kc-oracle/28/ ) KULRICE-3989
        Hide
        Kuali RIce Hudson (Inactive) added a comment -

        Integrated in UT-1.0-kc-mysql #46 (See http://ci.rice.kuali.org/job/UT-1.0-kc-mysql/46/)
        KULRICE-3989

        Show
        Kuali RIce Hudson (Inactive) added a comment - Integrated in UT-1.0-kc-mysql #46 (See http://ci.rice.kuali.org/job/UT-1.0-kc-mysql/46/ ) KULRICE-3989

          People

          • Assignee:
            Daniel Seibert (Inactive)
            Reporter:
            Geoff McGregor
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel