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

[José Mariano Luján]

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.instructor
> 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
>