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.