Moodle Plugins directory: Temporary enrolments | Moodle.org
Temporary enrolments
Andrew Zito[RETIRED] This plugin is no longer maintained and there will be no further releases.
Often a student or other user needs to be given access to a course site -- in order to read the syllabus, complete homework, etc. -- but is not officially enrolled in the course (i.e., through the registrar.) They may be waitlisted, not have turned in their registration form, or be waiting for their registration to process. A potential and easy solution is to allow teachers/professors to enrol users in their Moodle courses. When a student requires access but has not been granted it through the usual process, due to not being registered, they can ask the teacher and the teacher can give them access to the course website by enrolling them in Moodle.
However, this is not the ideal solution. It is inelegant in that it draws no separation in the Moodle context between a registered course member and someone who is merely being granted course website access. The connection between Moodle 'enrolment' and actual, registrar-verified course enrolment becomes tenuous and messy. Even more importantly, this confusion can spread to the site user experience. Students may mistakenly believe that they are offically enrolled in a course because they have Moodle access, when in fact their enrolment has not been processed by the registrar. This can lead to serious problems if the student does not officially register by the add/drop deadline.
This plugin is intended as a solution to the above problem. It provides a way for teachers to enrol students on an enforced temporary basis; i.e., the enrolment is automatically terminated after a period of time. While Moodle's built-in manual enrolment method *does* provide the ability to limit the length of those manual enrolments, it does *not* provide a way to make that length different per user -- meaning that *all* manual enrolments would become temporary, which is not the desired behavior. Rather than creating another enrolment method, this plugin utilizes a more lightweight solution -- it provides all of its functionality by keying off of a specific role. For more information on the functionality of the plugin, read on.
Useful links
Screenshots
Contributors
I have not used this plugin yet... but I found it very interesting.
Useful for new users to test a course without being officially enrolled. Trials
Could it have an expiration for the testing of the course by a number of activities or lessons?
Thanks.. excellent work..
Do you mean an enrolment that expires when the student has completed a certain number of activities?
We have implemented the plugin on a 3.6 and it seems to work, however we have identified, we believe, a bug that could impact your users even if the plugin "onoff" is set to off.
With "existing_assignments" checked and if we change the marker role ("roleid") and click "Save" the adhoc_task is run, regardless of whether the "onoff" value is set or not.
This, certainly for us, and with the accidental selection of an existing role, has sent the initial emails out to *all* our existing editing teachers (approx 23,000 emails in total) and caused unnecessary panic. It has also created the 23,000 records in the custom table of all the marked roles assigned in our courses (we have lots).
We understand the plugin is "off", so the actual removal of the roles is unlikely to succeed, however the sending of the emails is just as bad as removing the roles.
This is a warning to future users of the plugin, and the fact we can't raise bug tracks for existing versions, that the use of the plugin should be very cautious and to read the documentation carefully.
I'm sorry to hear that this happened. Unfortunately, as stated on this page and elsewhere, I've had to retire this plugin from active maintenance due to time constraints and a lack of usage/engagement. Additionally, the plugin was written before some significant changes to Moodle's enrolment API, and would need a fair bit of refactoring to get into a reasonable place.
In regards to this specific issue, the adhoc task is wrapped in a conditional that checks the onoff setting. Perhaps there was some configuration caching that caused the task to get a 'true' from that config check, even though the current setting was false?
Unfortunately I do not currently have the resources to reopen maintenance of this plugin and refactor it into a reasonable state. That said, if you're interested in taking over ownership of the plugin, I'd certainly be happy to talk about that.
Regards,
Andrew Zito