[Building Sakai] GroupProvider and CourseManagementService too tightly coupled?

[Bristow, Paul]

Maarten,

I think I had the same issue. Some CMS dependencies seem to have been created which assume that you will only use the group provider if you use the CMS. I think I got around it by reversing the changes that put these in but we're only using 2.4.x so your mileage may vary.

IMHO the group provider should not assume use of course management or  section dependencies. I think you will need to change sakai code to fix this.

----------------------------------------------------
Paul Bristow
Applications Architect
Division of Information Technology
Charles Sturt University
Ph: 02 6051 9959
Fax: 02 6051 9919
pbristow at csu.edu.au
www.csu.edu.au
----------------------------------------------------

YOU MUST READ THIS NOTICE

This email has been sent by Charles Sturt University (ABN 83 878 708 551). This email
(and any attachment) is confidential and is intended for the use of the addressee(s)
only. If you are not the intended recipient of this email you must not copy,
distribute, take any action in reliance on it or disclose it to anyone. Any
confidentiality is not waived or lost by reason of mistaken delivery to you. The
views expressed in this email are not necessarily those of Charles Sturt University.
It is very important that before opening any attachments to this email you check them
for viruses and defects. CSU does not accept liability for any corruption or viruses
or any consequence which arise as a result of this email transmission. Email
communications with CSU may be subject to automated email filtering, which could result
in the delay or deletion of a legitimate email before it is read by its intended
recipient at CSU. Please tell us if you have concerns about this automatic filtering.
The Commonwealth Register of Institutions and Courses for Overseas Students (CRICOS)
Provider Number is 00005F (NSW), 025973E (QLD), and 01947G (VIC) for Charles Sturt
University.
----------------------------------------------------
From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Maarten van Hoof
Sent: Friday, 27 November 2009 8:20 PM
To: Sakai Dev
Subject: [Building Sakai] GroupProvider and CourseManagementService too tightly coupled?

Hi all,

I'm sorry for spamming this list twice with the same question, but I'm really hoping to get an answer.

Either I don't understand how GroupProvider and CourseManagementService work, or there are some flaws in how they are implemented in Sakai. The way I understand it, you can implement your own GroupProvider and that implementation needs no knowledge of how the CourseManagementService is implemented. Is that right?

I have developed an implementation of GroupProvider that manages a form of delegated administration: it gives certain users maintain access to a predefined set of sites. The users in question are members of a 'delegated' administration workspace and the set of sites is defined inside that workspace. It works like this: each of the 'managed' sites gets a groupProviderId that is equal to the site id of the delegated administration workspace. When called, my GroupProvider looks up the admin site and gives all members of that site maintain access to the managed site. It works quite well, but I've run into two problems. Please bear with me.


1. In the realms tool, when I set the groupProviderId of a managed site manually (which I wouldn't normally do, but still) I am told that the provider id is invalid. That is because in RealmsAction.java, in the method readRealmForm, the providerId is checked with the CourseManagementService (cms.getSection). I do not understand why this happens. I think it assumes a particular implementation of courseManagementService.

I think I solved this correctly by creating a federated course management service (org.sakaiproject.
coursemanagement.impl.CourseManagementServiceFederatedImpl) that first calls the default course management service and then calls a CourseManagementService of my own design. The latter is a CourseManagementServiceSampleChainImpl which only overwrites the getSection method. The implementation simply checks if the given groupProviderId is valid and if it is, it returns null.

This solves the problem I have with the realms tool, but introduces a new problem.

2. When I place a roster tool on a managed site, it will display a nullpointer exception. I traced that back to org.sakaiproject.tool.roster.StatusRequestCache.init(), which, again, checks the site's groupProviderId with the course management service. In this instance, it iterates over the sections that the cms returns and gets the enrollment sets. But because I solved 1 by returning null (rather than throwing an IdNotFoundException), section.getEnrollmentSets throws a nullpointer.


Thank you for bearing with me.

I have two questions:
- Why does the code assume that a group provider id be linked to a section? Does that not assume a particular implementation of both the group provider and the course management service?
- Is there any way I can solve this without changing Sakai code? If there isn't, am I correct in assuming that I should change the code in RealmsAction? I think the roster tool gets it right: it will ignore an IdNotFoundException.

Thanks,
Maarten van Hoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091130/e0417866/attachment.html