a group created with provider id should synchronize with parent site on manually updated member roles
Description
Attachments
depends on
duplicates
is depended on by
is related to
Activity
Neal Caidin June 28, 2014 at 11:29 AM
Anyone watching this ticket would probably be interested in watching KNL-1273.
Hudson CI Server May 29, 2014 at 3:19 PM
Integrated in sakai-trunk-java-1.7 #279 (See http://builds.sakaiproject.org:8080/job/sakai-trunk-java-1.7/279/)
fix from Paul at Western U to resolve an issue where many unnecessary inserts were happening when refreshAuthzGroup was being called. The bug was originally introduced in KNL-800. This patch contains a fair bit of refactoring and has been discussed quite a bit on the Core Team call and core-team list. (Revision 309889)
Result = SUCCESS
Sam Ottenhoff May 27, 2014 at 3:26 PM
Any thoughts from the UMich committers? The bug reported in (caused by the commit here in ) is holding up Sakai 10.0.
Sam Ottenhoff May 13, 2014 at 8:33 PM
Hi committers on KNL-800: can you please take a look at KNL-1250? It looks like this will block Sakai 10 and reversion of may be on the table if we can't figure out the appropriate behavior (right now, we are seeing inserts to the db every time this synchronization occurs).
Zhen Qian July 19, 2012 at 1:55 PM
Diana Perpich helped testing this fix and accepted the changes:
"I just checked a W11 Math site on ctqa and it looks like it's working as intended.
I found an Instructor (hmkadish) who was inheriting his role from ProviderID and changed that person's role on the Site Info page to "Librarian." Indeed, his role changed to Librarian not only in the site realm but in the group realm too. And he is no longer listed as inheriting his role from ProviderID.
I also changed another Instructor into an Observer and the change shows up in both the site realm and in the group realm.
I also changed one of the Instructors (tjferg) into a student. I wanted to be sure that he became a student in GB2, which is a group-aware tool. Things appear as they should. "Become User" didn't appear to revert to his providerID role, and that's a good thing."
Instructors can create three types of groups from 'Manage Groups' inside Site Info tool:
1. Ad-hoc group: where group users are picked individually;
2. Role-based group: where group users are added based on role assignment;
3. Section-based group: where group users are provided with section id.
This ticket only targets to the third-type: Section-based group.
We encountered this problem with CTools 2.7.1 installation, where in section-based group, group member roles always reverts back to the provided role, in spite of site level role changes.
For example, let's assume the following scenario:
1. user U is in section S as 'Instructor'.
2. However, the site owner changed his role to 'Teaching Assistant' in Site Info tool, so that U can no longer view/grade assignment submissions for all groups.
3. A auto group G is created afterward with section id of section S.
4. The instructor finds out that U is now in group G with 'Instructor' role, instead of 'Teaching Assistant'.
Remember that in Sakai, site owners/instructors can override provided user site roles in Site Info tool, however, they cannot do the same at the group level. Hence they would assume that group-level role definition should be the same as that in site-level.
The proposed fix here should address the following two problems:
P1. if there is a role change at the site level, the section-based group should be created with the changed role for user;
P2. if there is a role change at the site level after section-based group creation, the section-based group should sync-up with the current site-level role.