I've been tasked with creating a course request system for our college that will allow us to get a better hold on requests than the current email requests setup we have now. I've looked at the Course Request form, but it doesn't have some of the fields that we want such as start date and category, plus we'd like to be able to support copying a previous course as well as allowing the requester to assign other instructors to be in the course.
Before I go off an build a whole new system, I'd like to know if I can customize the built in course request form and work within that system so that it could be more easily dropped in to another Moodle system with out breaking too far from the Moodle code base.
I didn't see anything listed in the downloads section, but I may have missed something. I'd appreciate any feedback or pointers.
Thanks,
Nate Baxley
First make sure you have a recent Moodle 1.9. Petr and I did some work on the course request system just before the 1.9.4 release.
Next, there are really two ways this could go:
Anyway, basically I am encouraging you to follow the first stages of Development:Overview#Major_Development.
Next, there are really two ways this could go:
- If your changes make the course request system more useful and flexible for most people, without increasing the complexity too much, then we probably want it integrated into Moodle core.
- If, to meet your particular requirements, your system will be a lot more complex and not generally useful, then we would rather you kept it as a separate plugin (I suggest a block, or possibly an admin report.)
Anyway, basically I am encouraging you to follow the first stages of Development:Overview#Major_Development.
Thanks Tim. I will put something together and post back to the forums
Just an update since I got an email asking about my progress. Unfortunately, I didn't get time to go through spec reviews with the Moodle community, but we are now rolling out a version at the College of Education of University of Illinois. There are still a few things that are very specific to our environment, but I hope to be able to work all of these into configuration settings. Spring 2010 should be our test time and I will post back with updates as they happen.
OK, after going to the iMoot conference, I was inspired to try and work our Course Request system into a block instead of using a patch. I've got the request portion in, no problem. But we made some changes to the approval process as well, including having an "Approve" button that approves the course as is, and an "Edit" button that allows the administrator to make changes to the new course before approving it. To do this, I needed to change the course form to redirect back to the approval list after saving the changes. We added in a parameter that redirects the course form if it's set, but I'd rather not make changes to the main course edit form. Does anyone one have suggestions on how to change the edit form so that it redirects elsewhere after a save?
My current thinking is to do something with frames and javascript, but that sounds overly complicated. I'd like to make this change as easily portable as possible, but I also have to have this functionality. Any help would be great!
Nate
P.S. I promise to release what we have once this is more portable.
My current thinking is to do something with frames and javascript, but that sounds overly complicated. I'd like to make this change as easily portable as possible, but I also have to have this functionality. Any help would be great!
Nate
P.S. I promise to release what we have once this is more portable.
I think the only way to do this is to patch course/edit.php to take an optional returnurl parameter, preserve it using a hidden form field, and then redirect back to it after the form is saved.
Since a new optional field like that would not break backwards compatibility, we might be prepared to add it to core if you made a patch. It would probably be beneficial for other customisations too.
Since a new optional field like that would not break backwards compatibility, we might be prepared to add it to core if you made a patch. It would probably be beneficial for other customisations too.
Tim,
That's basically what I did already. Originally, I had set this field in the database, but I ran into issues with that. Would you recommend passing the returnurl on the call to edit.php, or can you suggest another way to pass it in. I will document it and create a patch file. Do I then need to create a ticket and attach the patch?
That's basically what I did already. Originally, I had set this field in the database, but I ran into issues with that. Would you recommend passing the returnurl on the call to edit.php, or can you suggest another way to pass it in. I will document it and create a patch file. Do I then need to create a ticket and attach the patch?
Definitely do it in the URL. Something like
&returnurl=blocks/courserequest/whatever.php
You need to call urlencode the link when you output it from PHP.
&returnurl=blocks/courserequest/whatever.php
You need to call urlencode the link when you output it from PHP.
Super, I'll work that up this week or early next and submit a patch.
Tim,
I went ahead and did the patch today. The tracker link is here (http://tracker.moodle.org/browse/MDL-21724). Let me know what else you need from me.
I went ahead and did the patch today. The tracker link is here (http://tracker.moodle.org/browse/MDL-21724). Let me know what else you need from me.
Basically good, but ...
Please read the Coding style. Specifically, 4 spaces for indent, not tabs. Also, no trailing whitespace at the end of lines. Look at the last change in the patch.
if ( isset($data->returnurl) && strlen($data->returnurl) > 0 ) {
Use if (!empty($data->returnurl)) {
And note, no space after an opening ( in an if statement.
Does this patch apply to Moodle 2.0?
Please read the Coding style. Specifically, 4 spaces for indent, not tabs. Also, no trailing whitespace at the end of lines. Look at the last change in the patch.
if ( isset($data->returnurl) && strlen($data->returnurl) > 0 ) {
Use if (!empty($data->returnurl)) {
And note, no space after an opening ( in an if statement.
Does this patch apply to Moodle 2.0?
Thanks for the guidance Tim. I've gone over the coding standards and made the changes. I've uploaded the new patch to the ticket. I don't have a 2.0 instance running, but I downloaded the current version and tried applying the patch to it and it appears to apply with no issues and looks correct, but I haven't tested it.
Looking good. Now just need an OK from someone at Moodle HQ, and I'll commit it.
Hello,
back to the orginal post " but it doesn't have some of the fields that we want such as start date and category,"... I would like to mention that a proposal of patch to course request system is already pending at http://tracker.moodle.org/browse/MDL-8307 for old Moodle and http://tracker.moodle.org/browse/MDL-20335 for 1.9.x.
This patch add a drop down list of currently available categories to the request form (with the current $CFG->defaultrequestcategory as default) that is processed to affect the requested course when the admin validate the course. Currently in 1.9.7, any requested course fall to $CFG->defaultrequestcategory and should be moved by hand by admin when validating the request or by the teacher at his first access...
This patch also add the optional course idnumber to be proposed by the requester. It is quite important here since idnumbers (of course and students) are used in some places in Moodle for example with bulk enrolments, and admins not necessarly knows the courses naming system.
this requires adding to mdl_course_request table (currently by hand
) but could be automatized by someone that knows something about lib/db/upgrade ...
category int(11) Non 0 Pp categorie ou inserer le cours
idnumber varchar(64) Oui NULL PP code ECTS
I guess that adding the startdate should be trivial along these lines.
Finally the patch add the global course default values to the new course. This part has already been incorporated in core see http://tracker.moodle.org/browse/MDL-20336
Cheers.
back to the orginal post " but it doesn't have some of the fields that we want such as start date and category,"... I would like to mention that a proposal of patch to course request system is already pending at http://tracker.moodle.org/browse/MDL-8307 for old Moodle and http://tracker.moodle.org/browse/MDL-20335 for 1.9.x.
This patch add a drop down list of currently available categories to the request form (with the current $CFG->defaultrequestcategory as default) that is processed to affect the requested course when the admin validate the course. Currently in 1.9.7, any requested course fall to $CFG->defaultrequestcategory and should be moved by hand by admin when validating the request or by the teacher at his first access...
This patch also add the optional course idnumber to be proposed by the requester. It is quite important here since idnumbers (of course and students) are used in some places in Moodle for example with bulk enrolments, and admins not necessarly knows the courses naming system.
this requires adding to mdl_course_request table (currently by hand
) but could be automatized by someone that knows something about lib/db/upgrade ...
category int(11) Non 0 Pp categorie ou inserer le cours
idnumber varchar(64) Oui NULL PP code ECTS
I guess that adding the startdate should be trivial along these lines.
Finally the patch add the global course default values to the new course. This part has already been incorporated in core see http://tracker.moodle.org/browse/MDL-20336
Cheers.
Thanks for the links Patrick, but I needed more functionality than that. For one I wanted to be able to track the requests, such as how long it took us to respond to them, how far in advance of the start date they were made, plus we wanted to give the option of copying setup and material from a previous course. We're also pulling course information from our LDAP server and from an XML course catalog. I also wanted to be able to enforce a naming structure, without relying on the instructor to get it right ;) I've tried to make all of these things variable, and now by using a block, those variables can be easily edited, but I fear that the end result will be too specific to our University. I'll submit it anyway, and maybe it can be a help to others. Hope to have it done in a couple of weeks, if only I could make the other things stop intruding 