[Building Sakai] Sections and Project Sites

[Oliver Heyer]

Raad,

Please see

https://source.sakaiproject.org/svn//sections/trunk/xdocs/README.txt

Here is one relevant excerpt:

Sections use a "marker" authorization function to determine which
sakai role contains the list of members.  Only one role per section 
can contain the marker function. If more than one role
contains the marker function, SectionAwareness will fail quickly.
Since there is no UI exposed to the user for editing section authzGroups,
this kind of misconfiguration shouldn't occur.
			
Students:  Find the role that contains the 'section.role.student'
authorization function.	 The members in this section's role
are considered students in the section.
				
TAs:  Find the role that contains the 'section.role.ta'
authorization function.	 The members in this section's role
are considered TAs.
				
Instructors:  Find the role that contains the 'section.role.instructor'
authorization function.	 The members in this section's role
are considered instructors.

We must insist that only one section role have any particular marker
in a site because, when adding a user to a section, we need to find
the one (and only one) role to use when adding the user.  If two roles
with the same marker function existed in the section's authzGroup,
it would be impossible to know which roles to use when determining
the section's membership.


Oliver

Raad Al-Rawi wrote:
> On 13-Oct-09 20:06, Qu, Yuanhua wrote:
>   
>> Ours also work fine. We did run into similar issue before and we found
>> that in group realm, permission like section.role.student is only
>> allowed to assign to one and only role in that group realm. Same rule
>> for section.role.ta and section.role.instructor.
>>
>> If you happen to have more than one roles be assigned with same
>> section.role.* , make sure only assigned to one role that really need
>> that section.role.* will probably fix the issue.
>>
>> -Qu
>>     
>
> Bingo!
>
> We have a custom role in our project sites that has section.role.student 
> selected - the same as the access role.
> Never knew this was an issue, thanks Qu!
>
> Shame it can't be overridden by fixing up in !site.helper, as it's a 
> permission removal not addition. Still, we know what to do now.
>
> Thanks everyone - are there any other "gotchas" like this one?
> It would seem worthwhile collecting them together so they might at least 
> become searchable via Google etc. as they aren't necessarily in JIRA (I 
> couldn't find this glitch in bugs.sakai).
>
> Best regards
>
> Raad
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>   

-- 
Oliver Heyer
Manager, Learning Systems Group
Educational Technology Services
U.C. Berkeley
(510) 529-5177