[Building Sakai] SAK-17260

Zhen Qian zqian at umich.edu
Wed Apr 27 08:35:01 PDT 2011



Chris: 

I've tested on the nightly 2.7.x server, following the same steps and got
same result, where the overridden role is reserved. 

What version of 2.7.x are you using? Any local modifications to Site Info
tool? 

Thanks, 

- Zhen 

On Wed, 27 Apr 2011 15:26:33 +0000, "Maurer, Christopher Wayne"  wrote: 
Would there be any differences between trunk and 2.7.x here?  Chris   From:
Zhen Qian 
 Date: Wed, 27 Apr 2011 11:21:05 -0400
 To: Chris Maurer 
 Cc: 
 Subject: Re: [Building Sakai] SAK-17260  

Hi, Chris: 

I did a quick test on nightly2 trunk Oracle server:
http://nightly2.sakaiproject.org:8082/portal/site/65a68d2b-438d-4bc0-ad99-02034d827a7a
[4] 

I created the "Discussion 1 SMPL 101" site with provider id "Discussion 1
SMPL101" first, and added student0031 as TA role. Later I went to "Edit
Class Rosters" in Site Info and added "Discussion 2 SMPL 101". You can see
now the student0031 is still with TA role, removable, but the provider
information is also shown for him. 

So
maybe the problem you observed is related to local authzgroup impl? 

Thanks, 

- Zhen 

On Wed, 27 Apr 2011 15:13:25 +0000, "Maurer, Christopher Wayne"  wrote: 
Zhen, What you just described is not what I'm experiencing. My user always
comes through as provided (with the provided role) and I have no option to
remove the user. Chris  From: Zhen Qian 
 Date: Wed, 27 Apr 2011 10:39:39 -0400
 To: Chris Maurer 
 Cc: 
 Subject: Re: [Building Sakai] SAK-17260 

Chris: 

It is a general problem and not specific to one AuthzGroup provider
implementation. 

I think it is open to discussion whether the overridden role should be
reserved or not if it is different from that in provider definition. 

SAK-17260 will reserve the current role, but show all the provider
information about the user. The "Remove" column is still enabled for the
user. After removal, the user is still shown with role reverted back to the
provided role. 

KNL-403 removes local role definition for provided user ONLY IF the
local
role == provided role. In order words, it won't do anything if user is
first added as roleA and later provided with roleB. 

Based on the description of SAK-17260, I don't think it conflicts with
KNL-403... 

Thanks, 

- Zhen 

On Wed, 27 Apr 2011 13:57:57 +0000, "Maurer, Christopher Wayne"  wrote: 
https://jira.sakaiproject.org/browse/SAK-17260 [10] This issue was fixed
over a year ago, so perhaps no one really remembers, but I had some
concerns as I see how things are working on our local 2.7 version. I'm not
sure if it's just due to the special provider that we're using here, but
the behavior that I now see is that a user that is an actual member of a
site will have their role overridden by the role coming from the provider.
Is that really what is intended? If so, maybe we should adopt a solution
similar to how the provided role is determined (by an ordered list -
siteRoleResolutionOrder - so that the provided role would be chosen only if
it were higher in the list then the
native site role. Am I way out there
with this requirement? Maybe this isn't an issue with the standard group
providers and is only an issue with the custom one we wrote! Chris  

 

Links:
------
[1] mailto:zqian at umich.edu
[2] mailto:chmaurer at iupui.edu
[3] mailto:sakai-dev at collab.sakaiproject.org
[4]
http://nightly2.sakaiproject.org:8082/portal/site/65a68d2b-438d-4bc0-ad99-02034d827a7a
[5] mailto:chmaurer at iupui.edu
[6] mailto:zqian at umich.edu
[7] mailto:chmaurer at iupui.edu
[8] mailto:sakai-dev at collab.sakaiproject.org
[9] mailto:chmaurer at iupui.edu
[10] https://jira.sakaiproject.org/browse/SAK-17260
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110427/e82c5e9d/attachment.html 


More information about the sakai-dev mailing list