There’s been lots of questions and interest in AutoEnrol ever since Moodle 2.6 came out. I’ve now got some time to put together an updated version and there are a few new functions in Moodle which I want to take advantage of in the next release. My plan is to release an updated version with Moodle 2.7 compatibility in the next few weeks.
As for the longer term picture with AutoEnrol, I originally developed the plugin because I felt cohorts did not offer a flexible enough mechanism for getting users onto a course quickly. Since then cohort functionality and efficiency has improved greatly, and I am wondering whether it would be better to build a mechanism for dynamically populating cohorts so that they can be added to a course.
I’m keen to hear thoughts on this and will probably fire up a discussion on the Moodle forums soon. If you have any thoughts you would like to share now please do leave a comment for me here!
For the last couple of days I have been working on a new plugin called “MIS Enrolment” which allows you to connect to records on an external database and then enrol users onto a Moodle course based upon their participation within that programme. The enrolment method works by allowing teachers to create an abstract “link” between their course on Moodle and their programmes held by MIS.
This creates a many to many relationship between Moodle courses and MIS programmes and will allow teachers to easily enrol both staff and students onto the correct courses based upon the records held by an organisation’s MIS. More information to come on this over the next few weeks!
For now I am revisiting an old problem which I originally dealt with in my first month of developing for Moodle 2. In order to get this enrolment method working effectively we have to create and maintain an internal copy of the data from MIS. Normally you could just truncate (wipe clean) your records and insert them again from source, but in this case I need to compare and check:
What records already exist? Do they need updating?
What records are new? They will need inserting!
What records are missing from MIS? They will need archiving!
And when you are looping through 10,000 records or more this can all result in a great many individual inserts, selects and deletions. So how can you maximise the efficiency of all this? This time round I am making use of delegated transactions in Moodle to handle the bulk of database inserts.
The mechanism effectively defers all the transactions with a database to one large transaction at the end of a process. As a result you can save lots of memory and significantly reduce execution time because your script isn’t constantly waiting on the database to return some data.
For comparison I tried inserting my test participation data of 9483 new records. Using the standard DB functions the script took 47 seconds to execute, working at a steady 202 transactions per second. By comparison the delegated transaction took just 10 seconds to handle exactly the same data inserts, an effective rate of 948 inserts per second.
If you are working with large datasets on Moodle I would definitely suggest checking this functionality out as part of your project!
After a couple of months in testing AutoEnrol 1.2 has now been given a stable release at Moodle.org. There are a fair few additional settings to get your teeth into now, but the module works pretty much the same at it’s heart and can be updated from any previous version.
You can download the new version from either of the links below
I’ve had some tremendous support and positive comments from the Moodle community since releasing AutoEnrol over a year ago. It’s clear that people are stretching the plugin and finding some pretty awesome uses for it and as such there have been a few features which seemed to be sorely missing from the plugin.
When I first switched from teaching to development one of my biggest dislikes was having to manually transfer feedback from my Moodle Assessments to the student records on ProMonitor, the E-ILP system used at BSDC.
I’m now looking at the possibility of developing an Advanced Grading Method for Moodle 2.2+ which can be driven by the markbook structure in ProMonitor. My hope is that I can present the tutor with a form which matches up to their gradebook in ProMonitor 100%; something which 9 other colleges in the UK have expressed an interest in!
Today I have been looking at how the grading method will be related to ProMonitor’s database. Initially I was quite optimistic that it would be easy to select a course, followed by a unit, and finally an assessment which you wanted to use for the grading structure. This is a simple workflow which makes sense, but unfortunately it doesn’t reflect the way that people use ProMonitor.
For example, if you have an option of three routes on the second year of a BTEC programme, the probability is that each route will share a large number of units. In this case you will have three ProMonitor courses each containing the same unit.
Unfortunately ProMonitor’s approach to solving this is to allow tutors to clone assessment units in the database. In order to allow tweaks and changes to be made to one and not the other these clones are duplicated in the database with no common identifier shared between them. Even if there was a common identifier it would not be sensible to assume the structure was remained identical on each unit. In other words we have to accept that the unit within each course unique.
The easy solution is to make my new grading method refer to one “course” only and expect our Moodle users to create separate assessment activities for each path of the course where they might not have done before. This is not ideal but at least gives us a safe fallback position.
One option may be to write a method of finding duplicated assessment structures and “undoing” the duplication within the database. The worry with this is that an assessment structure may change after the grading method has been added to the assessment which would lead to problems when trying to synchronise with ProMonitor.
The better solution may be to alter my workflow allowing tutors to add multiple courses/unit/assessments to the grading method and then dynamically switching to the correct one for each student. However, this raises the prospect that a student may have more than one applicable assignment, in which case we would need to ask the tutor which they would like to grade. Alternatively the student might not be enrolled on any of the assessments, in which case we would have to present the tutor with an error message.
Fingers crossed I can come up with something that works well for everyone!
There is a tendancy to over-engineer solutions in the Moodle community sometimes, and this tends to lead to confusing interfaces or even worse something that doesn’t work as it should.
I’ve spent most of the last few months writing local plugins for Moodle; the kind that have eight tables in the database and make your mind melt as you work on them. So when I found a bit of time I decided to create a simple straw poll block which would “just work”.
A straw poll is a simple thing, and because it is in a block we know that there should be a limited number of questions. Equally I felt it was overkill to support the exporting of complex spreadsheets to show the results. A total and a percentage should be enough for any straw poll, and if you want more than that there is the wonderful Choice activity!
So I decided that the Questions and the Responses could all be held directly in the block configuration meaning the only table that would needed in the database would be for responses. This is more efficient since block configuration is already loaded and it cuts down the number of DB queries Moodle needs to do.
The configuration for the block is very simple, with one text box for the question, six text boxes for possible options, and a few extra options to control how the user will interact with the block. The empty options are simply ignored by the block and responses cannot be submitted for them.
I will be submitting a Beta of this block to Moodle.org soon, but if you would like to try it out now you can download it from my GitHub repository.
Back in June last year I had the idea of developing a Moodle plugin which could be used to add information to a page allowing users to learn how to use Moodle “on the fly”. I came up with the slightly goofy name of Page Annotationsand posted a new discussion over on Moodle.org receiving some quite positive feedback.
After that it all went quiet (sorry about that!), but you will be glad to hear I didn’t forget about page annotations. In actual fact I have been running an early version of the plugin on BSDC‘s Moodle site since September and have been looking for ways to improve it since then. Now called Page Hints, I have been working with the advice of Andy Nicols to improve the efficiency and compatibility of the plugin.
Once you have the plugin installed you need to look under Site Administration > Plugins > Local Plugins for the admin panel.
The management screen is basically just a table showing all your instances which can be edited, cloned, disabled or deleted at any time. You can also create a new instance by clicking on the “New Hint” button in the bottom right.
The editing screen is a form which auto-updates a hint on the screen as you make changes. Make sure you read the help information on the last “page filters” section as this is what determines where the hint will appear.
I can see a lot of room for enhancements to this plugin; making it easier for admins to add hints to any page and making it possible for teachers to add hints to their courses are high on my priority before this is submitted to Moodle.org’s plugin repository. That said the plugin is now quite mature, running on several production servers.
If you would like to take a Page Hints for a spin on your Moodle you can get a copy from my GitHub Repository. I’d love to hear your thoughts on what I have so far as well as any suggestions for the future.