 I would like to talk about a sort of approach we took to automating enrolment of students into middle with plug-ins. I should probably say at this point this is possibly more of a development talk than an administration talk but I'm sure I might have put it into the wrong category here but I hope it's useful to everyone anyway. What I would like to talk about is how we used to do enrolment automation many years ago, five years ago. Some of the problems we encountered with that and how the new-ish enrolment plug-in architecture helped to improve that. How we do it now and some of the lessons we learned, so basically a standard presentation. The old way we used to do enrolment automation is we have an in-house student record system so we basically developed a database view on that and just used the standard middle database enrolment plug-in to essentially enrol students on it. The way that all the enrolment plug-ins work in middle, the batch ones like LDAP and database and things like that, is essentially you have a data structure on one side and the plug-in kind of goes and replicates that into middle. The data structure is the important part of that. If someone is on CS101 they get put into a course called CS101, if somebody is on CS202 they get put into a course called CS202 so it's very much a very tightly structured method of doing that. Most of these plug-ins have been like that since middle 1.9, they're set up at a server level and that's how they work. So that was how we did it and it worked pretty well for two or three years. We've been using middle for maybe six or seven years now and that was how we did enrolment for two or three years and it's okay, it works okay. But there were various problems with that that we found. The main one is, which is possibly more to do with the way our university works than actually a problem with middle, but Strathclyde is a very decentralized university so you find that there's no one's forced to run their course in any specific way so there are loads of strange and wonderful ways that things are run. One of the main things is you'll get multiple class codes that are taught together so CS101 might be Computer Science for Geologists and then you get CS102 which is Computer Science for Neurobiologists or something like that but essentially they're the same students sitting in the same room in the same lecture hall, they do the same tutorials, they do the same thing all the time but the way that the database plug-in works essentially, those people are stuck into different middle courses, whether you like it or not. So there's no collaboration between the two class codes. If anybody's as unlucky as me to have worked in WebCT for years, this is a cross-listing that was called WebCT. That was a problem, we ended up with these people in separate courses. There were things like departments and faculty sites, people wanted to have a design management engineering department site and that just wasn't possible with the plug-in unless we went and messed around with the data that was feeding into it, we would have had to edit the oracle view. So things like that were problematic. Cohorts from multiple academic sessions was another thing. We found that there were some courses where you'd actually have people from two different academic sessions sitting in the same, or that were being taught together. Our MBA was a bit like that, there was sort of different ways of doing it. Some people would come into it and they had two years to complete certain courses and things like that so you'd actually find that there was people from the 14-15 session and the 15-16 session all working together in the same course and again we couldn't do that with the Moodle enrolment plug-in that we were using. So essentially the main problem with it was that the external database, what was actually fed in from the external student record system just dictated the Moodle structure so there was one-to-one relationship between courses and Moodle courses essentially so that was quite problematic. Also every time we rolled over to the next academic session we needed to create a new database for you that just had the users from that academic session and pulled them into Moodle so there were all sorts of problems with it. When Moodle 2.0 came in we realised that the enrolment plug-in architecture had changed so actually it changed quite nicely that rather than just configuring an enrolment plug-in at the server level and that just dictating how things went you could actually have enrolment instances as everybody probably knows. You can have enrolment instances and you can configure them each one separately so a course in Moodle can have maybe 10 enrolment instances that are all doing different things like manual enrolment, open access, guest enrolment, that kind of stuff. When we looked into that we discovered that the enrolment plug-ins can essentially do what they want with the data that they're given when they're configured so there's a lot of scope in there for creating something pretty useful. So what we did, we moved away from just using the external database enrolment plug-in to using these more granular plug-ins which we developed. There's only really four, I think there's technically eight of them but they fall into four main categories and they all work quite nicely together so we have a class enrolment plug-in, a program enrolment plug-in, a class for us is like a module as a part of a degree course, a program is a degree course it's the whole thing. User profile and criteria which I'll get to later which is probably quite a specific Strathclyde thing. So the main one that we use, we've got a class enrolment plug-in so we can now add an enrolment instance to a class and say this is for this class code so pull all the students from this class code into this middle course. We can also select a session so we have one server per academic session which I'm hoping to move away from at some point but that's how we work it so each server has a specific session that it's attached to so we can say pull the students from this class course on this academic session into this course and when we copy that course for the next session that will just automatically start bringing in the users from the next session so that kind of handles rollover from your tier and we can select what role people go into. The program enrolment one is essentially the same, we can give a program code we can either say all years if it's just somebody is looking for a site or a middle course for a specific program we can pull everybody in but if they want to pull in for example people that are on first year in a program for possibly an induction course or something like that we can say pull in the people from this program, pull in only first years and again it's the session and the roles so that kind of works. Profile based enrolment is slightly different, it's not actually talking to the external database but the reason for that is that when we create users we pull quite a lot of stuff into their user profile so we've got the program that they're on, whether they're undergraduate or postgraduate what department the program is run by, all sorts of things like that so rather than if we want to get for example everybody, location is another thing so if we want to get all the students from Oman or something like that we can actually set this up, we just say profile field is location, value is Oman again that pulls everyone into a course. Criteria is a very very strathclyde specific thing but essentially there's an in-house student records system that's built on top of a massive oracle database and there's this user friendly interface for creating queries against that to get a list of people it's used for creating things like mailing lists and all that kind of stuff so we decided that if there's this thing that's already there for creating mailing lists and whatever creating lists of people, why can't we just pull those people into Moodle courses so we've got this thing, so actually you set up a criteria in this system it'll pull people into Moodle, you just select one and again you select the role and you can set up a group name, all of these plugins create a group for the specific people so if you've got CS101, CS 102 students in the same course you get a group so you can make materials available to people depending on what class they're enrolled in so the newbie that we have, I say newbie, it's about three years old now but the newbie is essentially that rather than the corporate database defining the structure of your Moodle site, the corporate database is just a resource that Moodle can draw on to pull in different lists of people so it makes it much more of a flexible approach to pulling people in so in the left hand side there you can see we can easily do the cross listing things we just stick to enrolment plugins and saying pull in CS101 and CS 102 and you don't have to mess around with anything like meta courses and all that kind of nonsense so it essentially can fix all the problems that I mentioned before so it's very much the database as the resource and Moodle is using that rather than the database being the truth and the structure about how that works so we learned a lot, I don't know why I've got these three specific things that I pulled in because we learned probably a lot more than this but essentially we learned that the enrolment plugin architecture in Moodle is incredibly flexible if you have some kind of idea about how you want to enrol students on courses you can probably do it using the enrolment plugin architecture it allows you to create forms to, I think there's about 16 fields or something like that you can have in the data for an enrolment plugin so you can actually define really clearly who you want to be pulled in and whatever you have to do on the back end to pull those people in is doable it's a fantastic system so that was probably the main thing I don't know why I've got academics being constrained by technology because that was something we actually knew before if you tell someone that you're teaching these two class codes together but we've created two Moodle courses for you they're not going to be very happy and it's completely reasonable so we can strive really hard to make sure that academics aren't annoyed by the technical constraints that they have and we've been very much changing Moodle to support the existing business practices rather than doing any enforcement of enrolment and this is how your course in Moodle must be because that's how our database plugin works and we can now say that whatever you want to do we can probably accommodate it now with Moodle so that's essentially what we've done so I hope that's some interest and that's me thanks very much