Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39385

refreshAuthzGroup should be done only if GroupProvider determines that provided group has changes

    Details

    • Type: Feature Request
    • Status: CLOSED
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 10.4, 11.0
    • Fix Version/s: None
    • Component/s: Kernel
    • Labels:
    • Previous Issue Keys:
      KNL-1331

      Description

      The addition of KNL-1183 and the later improvement in KNL-1325 makes that refreshAuthGroup is called automatically. It causes two situation to those that have Group Providers and CM implementations:

      1.- In case that you update CM or GroupProvider membership in a specific period (every night, week), automatic refresh causes unnecessary work that could be avoided. The improve in KNL-1325 really slows down the impact, but still generates unnecessary load at servers in these cases.

      2.- This is more particular of UdL instance case. We have two kinds of provided sites. Some with a regular CM implementation and others that have another approximation. The realms provided by CM would be fine with KNL-1325 and KNL-1183 but the others not.

      Those other realms must be NEVER refreshed. People when access to Sakai are automatically joined to the realm but if you refresh the realm you empty the list. Is something like the sample provider implementation. Those providers uses our user types and other LDAP attributes to determine if they must be in a site or not, but we don't extract the inverse query (who must be in this site). We use them to get big sites like intranet sites, faculty, etc.

      So, we really need that refreshAuthGroup don't be automatically launched, just when admin wants.

      Adding a method on GroupProvider like hasChanges ... that could be asked in provided sites to check if has to be updated or not should avoid these problems. It would be necessary to include hasChanged in CM too in order to relay responsibility to refresh to the CM implementation in case of using one. IMO we can return true by default in sample implementations, but we open a door to those that have custom implementations to implement this method and choose if they want to determine that value.

      Opinions, thoughts?

        Gliffy Diagrams

          Zeplin

            Attachments

              Issue Links

                Activity

                  People

                  Assignee:
                  k1team KERNEL TEAM (Inactive)
                  Reporter:
                  alex@asic.udl.es Alexandre Ballesté
                  Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                    Dates

                    Created:
                    Updated:
                    Resolved:

                      Git Integration