[Deploying Sakai] [Using Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)

Neal Caidin neal.caidin at duke.edu
Tue Jan 10 04:39:48 PST 2012

Hi Diego,

That's an interesting approach. That requires an administrator to make the change to the site.visit permission, correct? But once made, the permission will stick to the student role in the site? How do you manage the change in enrollment from semester-to-semester? Do you have to change the provider id of the shared site to capture the new enrollments and remove the old enrollments (by removing the old provider id)?


From: sakai-user-bounces at collab.sakaiproject.org [mailto:sakai-user-bounces at collab.sakaiproject.org] On Behalf Of Diego del Blanco Orobitg
Sent: Tuesday, January 10, 2012 7:23 AM
To: 'Beith, Linda'; sakai-user at collab.sakaiproject.org; production at collab.sakaiproject.org
Subject: Re: [Using Sakai] [Deploying Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)

Hi everyone:

A variant to the Andrew's 1st option that we have used in one of our customers is to create that repository course but enroll the students with a modified role without the site.visit permission but with content.view permission. So you don't need to have the contents public, because only enrolled users will have access to the contents. And they don't notice that they are enrolled in that site.

The problem (depending of the flexibility of your SIS more or less complex) here is to enroll the users in both sites, the normal site and the repository site.

Diego del Blanco Orobitg
Director de operaciones
diego.delblanco at samoo.es<mailto:diego.delblanco at samoo.es>
Tlf Oficina: 673 80 32 69
Tlf Móvil: 653 683 489

De: sakai-user-bounces at collab.sakaiproject.org<mailto:sakai-user-bounces at collab.sakaiproject.org> [mailto:sakai-user-bounces at collab.sakaiproject.org]<mailto:[mailto:sakai-user-bounces at collab.sakaiproject.org]> En nombre de Beith, Linda
Enviado el: lunes, 09 de enero de 2012 23:41
Para: sakai-user at collab.sakaiproject.org<mailto:sakai-user at collab.sakaiproject.org>; production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
Asunto: Re: [Using Sakai] [Deploying Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)

Hi everyone,
I did send a response to Andy but thought I'd also share our solution with everyone else as well.

Our initial migration process was to copy all Blackboard content into each faculty member's My Workspace Resources site (except of course tests and quizzes which had to be reformatted using Respondus). We then walked the faculty through making each course content folder publicly viewable (moving out anything they did not want students to see). So a typical faculty My Workspace Resources folder looks like this:

[Description: cid:image001.png at 01CCCC6B.EF034E40]

Currently we have an SIS integration with our Datatel administrative system that automatically creates our course shells, connects the instructor accounts (which are external AD accounts) and updates the rosters on a nightly basis.  For the initial course development we walked faculty through the process of copying their URLs to their course content stored in My Workspace Resources that they had made publicly viewable and then pasting the links to the folders as web links in their new Fall course Resources folder. Now when they do an Import from Site into their Spring courses, they are rolling over just the links to their content that is stored in My Workspace, which are absolute links. This way they don't duplicate the content from semester to semester taking up unnecessary server space and also don't have any problems with links. This also accounts for the occasional removal of old courses from the server (which we haven't figured out a schedule for yet!) so that they don't mistakenly lose their original content stored in an old course. So a typical Fall or Spring course Resources folder would look like this:

[Description: cid:image002.png at 01CCCC6C.5ECF25F0]

This conceptually is a sound practice however here are a couple of challenges that we have had with it:

·        Faculty have a difficult time understanding the difference between putting things in My Workspace Resources and then linking back to them from their course Resources

·        Faculty forget that they have "linked" to a folder in My Workspace Resources and when they want to add to a folder or remove documents in their course they can't find the original source location
One issue we've run into with the way we are creating courses is that we can't take advantage of the Section option which would be attractive to many of our lab/lecture type of courses where the preference would be to populate a parent course and then link to the content from the child sections.

Another issue is because we've integrated the course shell, instructor and student roster we've hampered the ability of our faculty to combine rosters or to add non-registered students (for example those making up an Incomplete from a prior semester). When faculty try to combine multiple sections of the same course into a single course shell, or those who are team-teaching or cross-listing courses want to combine their students into a single location, all the students are moved back each night when the update runs. As you can imagine this is very frustrating. Since we haven't had the opportunity to change our SIS integration process yet, what we've done as a workaround is create a separate Student role that contains all the same permissions and access but is named MStudent (for manually created student). So when faculty combine rosters they have to go in and change the role for all the blended students to MStudent in order to keep them in the course while providing full access to all the tools. It's time consuming initially but it lets them do what they want for the duration of the semester since the update process only recognizes and verifies against the Student role.

We were thinking of the course creation model that University of Rhode Island is using that connects the rosters only to the faculty accounts but then relies on the faculty member to go in each semester and create each of their course shells, attaching the rosters according to their preferences during the creation process. Our only concern is that this is expecting a lot of our faculty who up until now expect that we will do all of this for them :)

Providence College is planning on doing a modified approach where they automatically create the courses each semester and attach the faculty members. However they will not integrate the rosters into the shells. The faculty who want to use Sakai will have to go in at the beginning of the semester and attach their own rosters. This way the rosters will still be updated daily and will only be available to the specific faculty, but there is no automated connection to the actual course shell so they can mix and match rosters at will. I don't believe they've put this in place yet but I know that this is the plan. If they can pull this off, we'll probably adopt that process since it seems to be the most flexible while still automating most of it.

Sorry for the long-winded answer. Hope this helps.

From: production-bounces at collab.sakaiproject.org<mailto:production-bounces at collab.sakaiproject.org> [mailto:production-bounces at collab.sakaiproject.org]<mailto:[mailto:production-bounces at collab.sakaiproject.org]> On Behalf Of Valenti, Andrew P.
Sent: Friday, January 06, 2012 2:30 PM
To: sakai-user at collab.sakaiproject.org<mailto:sakai-user at collab.sakaiproject.org>; production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
Subject: [Deploying Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)

Hi Sakai Colleagues!

Happy New Year!

I am writing to solicit ideas, suggestions, and solutions to problems that occur when links to tools & content in one course site are created using the Import from Site tool to bring content into a new course site.

The Problem
In the Tufts instance of rSmart Sakai CLE 2.7 (which we call Trunk), we do not use Sakai Course Management.  A new course is created each semester, automatically triggered by the appropriate SIS information; under our course management process, course shells are not reused from semester to semester.  In some schools, it is a common practice that instructors create a syllabus using an HTML page in which they insert links to their course materials using the FCK editor and these links will be "absolute" meaning they point to the resources contained in the original course site.  The first time the course is created there's no problem as the instructor/site owner has permission to access them.   Let's suppose that in a subsequent semester a new instance of the course is created and the instructor decides to populate it  using the Import from Site tool.  If the instructor selects the check box for importing Resources (along with whatever else is needed), the tool will bring in the syllabus and the course materials.  If no further action is taken to modify the links that are in the copied syllabus, the following will happen.

To the instructor clicking on a link in the copied syllabus, the instructor is able to access the content and everything appears to be working.  To a student, confronted by an HTTP access error message, the links appear "broken";  what has happened?  The "absolute" link in the copied syllabus points to the course material in the instructor's original course site for which the student does not have permission to access.  Thus, the instructor can see it but not the student.  Interestingly, the course material copied from the original site is "orphaned" with no links pointing to it.  Emerging from discussions with our internal support team and our Sakai vendor, rSmart, were three alternatives:

Option 1 - Use a non-production site as a Sakai "content repository"

a.      Create a root site that serves as a content repository and make the content "public".
b.      In the original course design, ensure that the syllabus uses links pointing to the desired content in the repository site
c.      When the course is copied over, the links in the syllabus will work because they correctly point to content that has been made public. Since no actual course material has been copied to the new course site, there is no "orphaned" content.


  *   Instructors don't have to be aware of "relative" vs. "absolute" addressing
  *   Maintains single copy of course materials in a repository


  *   Requires thinking though an "information architecture" design for content stored in Sakai in order to oversee and maintain protection of copyrighted information
  *   Difficult to prevent multiple repository sites from proliferating which adds to content management woes
·        Ultimately, we'd like content to be stored in a repository outside of Sakai which will allow us to provide more sophisticated content management services such as, access control, capacity planning, and more sophisticated search capabilities

Option 2 - Copy content/fix addressing

  1.  Change the FCK editor so that the instructor creates "relative" links to course material when initially creating the syllabus.
  2.  When the course is copied using the Import from Site tool, the relative links correctly point to the course material copied into the new site.


  *   Material is kept in course sites which simplifies the management of copyrighted information
  *   Doesn't require instructors to be too aware of "relative" vs. "absolute" address and doesn't require them to set up a non-production repository site.


  *   Changing a pervasive tool such as the FCK editor can have unintended consequences which even thorough testing may not surface.  It also creates a fork in the application code tree that we'd have to maintain.
  *   Course material is duplicated from site to site, gradually consuming file storage
  *   Moving to an external content repository will be require scooping up information from individual sites

Option 3 - Use Duplicate Site tool


  *   The tool maintains the proper link addressing and might be the simplest solution.


  *   In our current design, the duplicates sites would not be automatically populated from our feed.  We'd have to undertake a manual process to populate them with the roster.
  *   Currently instructors don't have access to this tool. We'd need to think through this workflow.
  *   Continues the duplication of course material.

Why we need your help
Each solution has advantages and disadvantages which might be balanced differently based on an institution's LMS strategy and course management process.  Since the course duplication seems like it would be a fairly common process across the higher education Sakai community, we'd like to know what approach your institution has taken to populate new instances of a course and how you've overcome the aforementioned problems.  If there are additional options that we've not identified, we'd certainly like to hear about them!

Thanks in advance for the time you've taken to help a fellow peer institution!



Andy Valenti, MSc., PMP
LMS Project Manager
Educational & Scholarly Technology Services
University Information Technology (UIT)
Tufts University
108 Bromfield Road
Somerville, MA 02144

Tel 617.627.3814
Email andrew.valenti at tufts.edu<mailto:andrew.valenti at tufts.edu>


No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com<http://www.avg.com>
Versión: 10.0.1416 / Base de datos de virus: 2109/4132 - Fecha de publicación: 01/09/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20120110/16ec5c52/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 42709 bytes
Desc: image001.png
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/16ec5c52/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 35639 bytes
Desc: image002.png
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/16ec5c52/attachment-0003.png 

More information about the production mailing list