[Building Sakai] Remove ability for instructors to assign instructor role to others

Mon Jun 3 08:10:12 PDT 2013

Hi John,

Thanks for your comments. We discussed it here at Western, and we think that
your point is quite valid. I'll go ahead and redevelop the patch for
site-type specific lists and repost the solution.

Cheers,

Brian Jones
Applications Development
Information Technology Services
Support Services Building, Room 4326
Western University
(519) 661-2111 x86969
bjones86 at uwo.ca

-----Original Message-----
From: John Bush [mailto:john.bush at rsmart.com] 
Sent: Saturday, June 01, 2013 3:36 AM
To: José Mariano Luján
Cc: Brian Jones; dev sakai
Subject: Re: [Building Sakai] Remove ability for instructors to assign
instructor role to others

So I understand your problem with using a permission and in fact I've seen
lots of cases where things like site.upd get overloaded and it gets really
hard to manage.  I'm not so concerned about Jose's first point, because
typically people don't add new roles all that often, that's probably a
limitation we could live with, but I think the 2nd point is worth
considering.

   2- You could have two different types of sites with same role name but
different permissions.

When I reviewed this patch that was my first thought too.  I'm not sure how
often people really re-use the same role names in different site types, but
its definitely a limitation.  How hard would it be to allow for the config
to be based on site type instead, like this:

sitemanage.addParticipants.allowedRoles.course.count=2
sitemanage.addParticipants.allowedRoles.course.1=teaching assistant
sitemanage.addParticipants.allowedRoles.course.2=student

On Fri, May 31, 2013 at 9:50 AM, José Mariano Luján <jmariano at um.es> wrote:
> Hi Brian,
>
> Thanks for the explanation, seams reasonable. I just added my comment 
> to the jira. https://jira.sakaiproject.org/browse/SAK-23257
>
> cheers,
> mariano
>
>
> El 31/05/2013, a las 15:53, Brian Jones escribió:
>
>> Hi Jose,
>>
>> Thanks for your comments. Unfortunately, the paradigm used for 
>> SAK-18462 (using permissions to determine if a role will be 
>> 'restricted' instead of explicitly defining role names that are 
>> 'restricted') won't exactly work for our use cases, and possibly 
>> other institution's as well. This is because although it may work for 
>> some of our restricted roles, there are other roles that may not have 
>> a set, or even a single permission that is restricted in one role, but
not in another role which should be non restricted.
>>
>> For instance, we have a custom role called (example) 'Custom Role 1', 
>> which has essentially the same set of permissions as the 'Teaching
Assistant'
>> role. We want the 'Teaching Assistant' role to be a non-restricted 
>> role, but we need the Custom Role 1' role to be restricted. In this 
>> way, defining permissions to determine the restricted roles is not 
>> sufficient, and we need to explicitly tell the system that the Custom 
>> Role 1' role should be restricted.
>>
>> I'll add this comment to the Jira as well. Cheers,
>>
>> Brian Jones
>> Applications Development
>> Information Technology Services
>> Support Services Building, Room 4326
>> Western University
>> (519) 661-2111 x86969
>> bjones86 at uwo.ca
>>
>> From: JOSE MARIANO LUJáN GONZáLEZ [mailto:jmariano at um.es]
>> Sent: Friday, May 31, 2013 9:00 AM
>> To: Brian Jones
>> Cc: 'dev sakai'
>> Subject: Re: [Building Sakai] Remove ability for instructors to 
>> assign instructor role to others
>>
>> Hi Brian and all,
>>
>> Have you considered doing it the same way as SAK-18462 Ability to 
>> restrict joiner role selection to non-maintainer roles [1] was done.
>>
>> Instead of indicating which roles are allowed restricting a role, 
>> they based their choice in permissions. They indicated the prohibited 
>> permissions. It is pretty much the same solution but choosing this 
>> one will make it more consistent since it has already been done.
>>
>> We see some advantages to choose this approach:
>>    1- If your institution adds a new role, it will pretty much be 
>> added or rejected with out needing to configure the sakai.properties.
>>    2- You could have two different types of sites with same role name 
>> but different permissions.
>>
>> Here is an example of our sakai properties for SAK-18462 where we 
>> even control one of our custom permissions.
>> sakai.properties University Murcia
>> siteinfo.prohibited_permission_for_joiner_role.count=5
>> siteinfo.prohibited_permission_for_joiner_role.1=site.upd
>> siteinfo.prohibited_permission_for_joiner_role.2=section.role.instruc
>> tor siteinfo.prohibited_permission_for_joiner_role.3=section.role.ta
>> siteinfo.prohibited_permission_for_joiner_role.4=site.roleswap
>> siteinfo.prohibited_permission_for_joiner_role.5=umucorrige.VIEW
>>
>> I will add this comment to the jira too. We understand that this 
>> functionality is interesting for the community so +1 from Murcia.
>> cheers,
>> Mariano
>>
>>
>> [1] - https://jira.sakaiproject.org/browse/SAK-18462
>> El 30/05/2013 18:40, Brian Jones escribió:
>> Hello,
>>
>> Our institution required a (configurable) method of restricting what 
>> roles maintainers can assign to existing site members, and for adding 
>> new participants.
>>
>> We have developed this feature and provided a .patch for the community
here:
>> https://jira.sakaiproject.org/browse/SAK-23257
>>
>> It is already committed to trunk, but on the CLE call this morning it 
>> was decided that it should be floated out to the dev list for 
>> analysis, comments, suggestions, etc.
>>
>> The use case (for Western), is that our SIS integration defines all 
>> roster members and roles, and we cannot allow maintainers 
>> (instructors) the ability to assign other people as elevated roles 
>> (i.e. give someone else the instructor role).
>>
>> Our proposed solution to this is to define a set of 'allowed roles' 
>> in sakai.properties, and then both limit the choices on the UI via 
>> this property, and also do a backend check to ensure that the user 
>> role being set is contained in this list of 'allowed roles'.
>>
>> It was brought up on the CLE call that the Course Management API also 
>> supports this sort of feature, although using the CM API is optional, 
>> not required. Therefore there needs to be another, more general way 
>> of accomplishing this without needing to use the CM API.
>>
>> Another option suggested was to make this into a permission, but we 
>> chose not to go down this path because a single permission is more of 
>> an 'all or nothing' approach, rather than being configurable on a 
>> per-role basis (especially in a system where there are likely custom 
>> roles that are not provided out of the box).
>>
>> So, I would like to invite everyone to take a look at this feature/patch.
>> Are there other institutions that would utilize this feature, or have 
>> similar use cases? Is it acceptable as-is? Any comments, suggestions, 
>> etc are welcome. Feel free to chime in!
>>
>> Cheers,
>>
>> Brian Jones
>> Applications Development
>> Information Technology Services
>> Support Services Building, Room 4326
>> Western University
>> (519) 661-2111 x86969
>> bjones86 at uwo.ca
>>
>>
>>
>> _______________________________________________
>> 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"
>>
>>
>> --
>> ******************************************
>> José Mariano Luján González - Aula Virtual Area de Tecnologías de la 
>> Información y las Comunicaciones Aplicadas (ATICA) UNIVERSIDAD DE 
>> MURCIA - http://www.um.es
>>
>
> _______________________________________________
> 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"

--
John Bush
602-490-0470