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

[D. Stuart Freeman]

Sorry, I missed your original message about this. The behavior in our 2.5
was a custom patch as the feature didn't exist in mainline Sakai CLE
until I think the 2.6 release. When I upgraded our codebase to 2.8 I
threw out our patches and just used the now built in functionality. FWIW
the way I solved the issue in 2.5 was the same as what you've done in 2.8
(commenting out the rendering of the UI elements).

On Tue, Jan 22, 2013 at 11:30:48AM -0500, Kevin Pittman wrote:
> 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
> _______________________________________________
> 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"

-- 
D. Stuart Freeman
Georgia Institute of Technology
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130125/44264351/attachment.bin