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

Sat Jun 1 00:35:39 PDT 2013

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