Year Roll Over

Coordinator
Aug 20, 2008 at 3:41 PM
Hi All,

I was just wondering what you were all doing about year roll over and existing class sites. I've been working with my customers about this and have come up with various scenarios/options, but wondered if anyone else had any other 'best' practise.

There's a copy of it at http://www.salamandersoft.co.uk/sharepointlearningkitrollover.html, for those who want to read it with prettier formatting.

Introduction

In order to assign work to learners, SharePoint Learning Kit (SLK) uses sites and permissions provisioned within SharePoint itself. Typically, there is a site per class/teaching group with the appropriate learner and instructor permissions set, preferably pulled directly from your MIS system (Sims.Net, Facility CMIS etc). You may also have created SharePoint (or Active Directory) groups containing the learners and instructors for each class.

Problem

The two core problems with the new year rollover are:

  1. Re-use of class names. This affects sites and groups and then when you provision this year's classes, if you do not do anything to cope with it, the user's permissions will change to the latest year's learners.
  2. Last year's classes still in view. It is not user-friendly to display last year's and this year's classes together by default.

Possible solutions

There are a number of possible solutions to the problem, which is best ultimately depends how you want to use it in your school.

Site solutions

Site Option 1: Delete last year's class sites and groups

This will certainly remove the problem. However, you will lose any documents and data stored in the site.

This won't delete any SLK grade information for assignments, and the grades are accessible through the SLK web part. However, in the web part the site is labelled "Unknown Site x" which isn't very helpful.

Site Option 2: Move last year's class sites to an archive site

For example move them to http://root/Classes/Archive/2007. If you don't give permissions on the archive parent site (http://root/Classes/Archive), then your users won't accidently navigate there.

This solution has the advantage of keeping all your data available if required. The SLK web part automatically handles the fact that the site has moved

Site Option 3: From the start put different years in different parent sites

Instead of putting all your class sites in http://root/Classes, you would put them in http://root/Classes/2007, http://root/Classes/2008 etc. You then point the My Classes webpart at the relevant year's parent site. There shouldn't be any need for most users to go to the year sites so you don't need to visibly include them in your site navigation.

This is similar to Site Option 2, but without the need to move the sites at the year end so is a bit cleaner and simpler.

Site Option 4: Keep Existing sites as they are

For classes which are present last year and this year, permissions on the sites can either get overwritten or added to.

This will be very messy and confusing as you will have sites for

  • Last year's classes who don't have classes of the same name this year
  • A single site for a class which was present last year and this year
  • This year's classes which weren't present last year

Group solutions

Group Option 1: Delete last year's groups and recreate as needed

This will remove the user's permissions from the class sites. So they will no longer be able to access any of the information on the sites.

The SLK grades are still accessible through the SLK web part, However, in the web part the site is labelled "Unknown Site x" which isn't very helpful.

Group Option 2: Have different groups for each year

So for last year you would have a group called "7Ma/A Students 2007" and this year another one called "7Ma/A Students 2008".

Although this would simply solve the problem, it would lead to a massive proliferation of groups.

Group Option 3: Copy the groups' permissions onto the site and then remove the permissions of the groups

For the last year's sites the users would then have explicit permissions on the site, allowing them to access it and the SLK web part to work effectively. As the group permissions are removed, it can then be reused for this year.

For the SLK web part to display the site name all it requires is read, so that's the minimum set of permissions you need to copy to keep the web part running smoothly.

Group Option 4: Copy the groups' permissions onto the site and delete the group

This is similar to option 3, but cleans up all unused groups. This year's groups will be automatically recreated.

User Web List for SLK

This is the list of sites which are displayed when you choose "E-Learning Actions". You will probably want to remove last year's class sites from this list.

I'm still working on this one. The simplest workaround at the moment is to delete all the lists for everyone. The SLK API doesn't seem to have this feature, so to do it on a site by site basis, I'll either have to add one or resort to direct database access.

My Preferred Solution

Although Salamander will handle all these options, my personal preferred solution is:

  1. Use Site Option 3 so years are always segregated. If your current set up isn't like this, go for Site Option 2 now, and moving forward use option 3.
  2. Unless you want to use Groups elsewhere in SharePoint, I would assign permissions directly to the users on the site to avoid the rollover issue with group.
  3. If you want to use groups, or have an existing set up with groups I would go for Group Option 4 if the groups are not used elsewhere, or Option 3 if you are re-using them elsewhere in your site.

Regards,
Richard

SalamanderSoft Limited
http://www.salamandersoft.co.uk
Active Directory & SharePoint provisioning