Date Aug 31, 2006 3:54 PM EDT From Josh Holtzman < Subject CM Integration w/ Sakai... adding convenience methods to CM (This message is primarily for folks tracking the CM project, but it might affect gradebook too, so I've cc'd the assessment group) Although many of us have been dealing with things other than CM lately (Stanford folks are on vacation, Berkeley folks have been temporarily kicked out of our offices, Duffy is swamped with production issues, etc), I thought it would be a good idea to send out another status report on CM and let everybody know where we are, and what I think our next steps should be. * Status report:* The CM GroupProvider is in place, and is ready for use. Uncomment the bean definition in /cm-impl/hibernate-pack/src/webapp/WEB-INF/components.xml and you have a CM-enabled Sakai, complete with role resolving at the enrollment set/section, course offering, and course set (e.g. departmental admins) levels. For institutions that don't have (reliable) data at any of these levels, you can simply "unplug" the role resolving for that level in components.xml so you don't take an unneeded performance hit. Rudimentary cross listings are suported, so if a section is mapped to a site, and the section is part of a cross-listed course offering, members of the parent course offering and its equivalents are all members of the site. The group provider also provides for an easily configurable role mapping to convert enterprise roles to Sakai roles. See the components.xml file for details. I'm currently writing integration tests (see /cm-impl/integration-test) to ensure proper behavior of the sakai/CM integration. I'll be focusing on these tests for another week or so, which should lead to more complete and accurate site/group memberships for some of the more complex course structures. Look for "Help!" messages from me throughout the week as I come up against any ambiguities What's next? The GroupProvider impl was a good first client for CM, but it isn't really a user-facing tool. Gradebook is an obvious choice for our next client, so I've been thinking about what kinds of methods the gradebook might like to call to get information from CM. Displaying enrollment status is a big requirement, so methods like this might make sense to start with: public SiteEnrollments getSiteEnrollments(String siteContext, Set userEids); where a SiteEnrollments object has a method like: public Enrollment[] getEnrollments(String userEid); [For implementation junkies, this is just a Map of userEid->Enrollment[]... but there's no way we should expose this as a Map and expect clients to parse it!] This way, the gradebook can ask for the enrollments for all of its members, and get an array of Enrollments back for each one. Some users may have no enrollments (they are non-enrolled members of the site, or they are auditing members fed into the site by CM, or something else), while others might have several Enrollments (two sections are mapped to the site, and the user is Enrolled in both). Since this kind of method is specific to sakai and its notion of site context, it doesn't really belong in the CourseManagementService itself. I was thinking we should add a separate service... kind of like the cm-mapping that we just jettisoned (but will bring back when we have something to use from IMS). This way, we can hide the fact that the authz service is currently doing the section->site/group mappings from our clients, since this is expected to change at some point. So when the gradebook wants to list its users, it would: 1) ask Sakai who in the site can be graded (some kind of authz query) 2) ask the new sakai/cm service for the enrollments for each of those gradeable users (aka students) 3) display the users in a table, adding a new column for grading status (pass / fail, etc) and maybe another for credits, etc. Let me know what y'all think of this approach. In the meantime, I'll be integration testing away... Thanks, Josh – Josh Holtzman Educational Technology Services, UC Berkeley |