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

[Brian Jones]

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