[Building Sakai] Prevent 'group provider' enrollments from being deleted?

Kevin Pittman kevin.pittman at oit.gatech.edu
Tue Jan 22 08:30:48 PST 2013


On Fri, Jan 18, 2013 at 11:46:43AM -0500, Kevin Pittman wrote:
> I just dicsovered with Sakai 2.8 that while the 'limited to the group
> provider only' setting still prevents the instructor from changing an
> enrolled user into or out of that role, the instructor can now delete
> the user from the worksite.  Obviously, this is not what we want for our
> official academic courses, where student enrollments are controlled by
> our Student Information System, and I've now run into a problem where an
> instructor has tried using this method to turn a student into a teaching
> assistant (which isn't allowed under our school's rules.)

Just to follow up in case anyone finds this later when needing to solve the
same problem, there's a new 'PROVIDED' field in the SAKAI_REALM_RL_GR table
that controls whether or not a user enrollment can be deleted through the
regular SiteInfo GUI interface.  Unfortunately, setting this flag field on
also causes the Course Management stubs to be run, which have a nasty effect
of deleting these users the next time you view the roster in SiteInfo if you
haven't built out any code behind the CM stubs.

The ultimate solution that I found was to just hack the VM file for the main
SiteInfo list page and change the JSP login in the enrollment list display 
code to restore the old functionality.  For the curious, the proper file is:

  tomcat/webapps/sakai-site-manage-tool/vm/sitesetup/chef_site-siteInfo-list.vm

Only one line has to be changed, like so:

526c526
< 								#if ($participant.isRemoveable())
---
>  								#if (!$!isCourseSite || ($hasRestrictedRole == "false"))

Works like a charm :-)

I think an argument might could be made for changing that in the official
code base, since its a little illogical to have one field control whether or 
not user's role can be changed while another field in a different table 
controls whether or not the user can be unenrolled.  But, I'll leave it to 
the Sakai code experts here to take that one up and debate it.

Kevin
Georgia Tech Sakai Application Administrator

-- 
Kevin Pittman                              kevin.pittman at oit.gatech.edu
-----------------------------------------------------------------------
Senior Systems Support Engineer        Office of Information Technology
Academic and Research Technologies      Georgia Institute of Technology


More information about the sakai-dev mailing list