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

Remove all membership mappings from GroupBo and RoleBo

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-7517Improve performance of RoleService by not loading membership information for the RoleBo for nearly every method call
      KULRICE-10107Remove array and map initializing from component constructors
      KULRICE-1996Remove lockCode from DocumentRouteHeaderValue
      KULRICE-11468Add ability to remove mappings from superclass with JPA
      KULRICE-2703Remove all the old Action List code/jsps from the codebase and struts mappings
      KULRICE-4387Remove all deprecated code
      KULRICE-5045Change to Role membership from the Role document causes the affected enroute document to re-queue, while role membership changes from person doc does not
      KULRICE-4897Removal of toStringMapper, toStringBuilder, from BusinessObjectBase
      KULRICE-3453Remove encryptedProperties from PojoFormBase and htmlControlAttribute
      KULRICE-4575IM Person doc should only allow editing of direct group memberships
    • Rice Module:
      KIM
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      3

      Description

      The KIM group and role BOs both have memberships mapped with JPA annotations so the membership information is fetched whenever one of those BOs is retrieved using JPA. This is a significant performance problem when the group or role becomes large. At IU we have a few roles which have tens of thousands of users so whenever one of those role BOs is retrieved it causes a significant performance hit. It would be better if unbounded collections like these were not mapped up directly and instead went through a new API to explicitly fetch the role membership which is needed at any given point in the code. This will likely be a major refactor since the membership seems to be referenced in many different places in the code.

      A while back IU contributed a performance improvement which includes the RoleBoLite class. I'd think that you could do away with that since it would be exactly the same as RoleBo once the membership mapping is removed.

      Analysis: Review changes from RoleBoLite; Provide details on refactoring; Review for any impact for other projects

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            James Bennett
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel