Note: You are currently viewing documentation for Moodle 2.9. Up-to-date documentation for the latest stable version of Moodle may be available here: blocks/cmanager/.
- 1 Course Request Manager for Moodle 2
- 2 Introduction
- 3 System Requirements
- 4 Screencasts (new)
- 5 Installation of Course Request Manager
- 6 Accessing configuration settings
- 7 Configure Course Request Manager Settings – Configuring Email Settings
- 8 Configure Course Request Manager Settings – Configuring Admin Settings
- 9 Configure Request Form - Page 1
- 10 Configure Request Form - Page 2
- 11 Manage Forms
- 12 Editing your form
- 13 How to make a request (user perspective)
- 14 Managing Your Requests (user perspective)
- 15 Admin functions - Processing the request queue
- 16 Approve a Request
- 17 Deny A Request
- 18 Other request processing functions
- 19 User Permissions
- 20 Block Visibility
Course Request Manager for Moodle 2
This guide is aimed at a Moodle administrator who would like to start using the Course Request Manager(CRM) block for Moodle to help improve their user course request process.
The Course Request manager block requires Moodle 2.3 and above. A Moodle 1.9 version (unsupported) can also be downloaded from github. GITHUB
A series of short screencasts on the setup and use of course request manager for moodle. These screencasts are only for version 2.4 of the plugin. New screencasts for version 3.0 of the plugin ate due shortly
Installation and Setup A quick overview of the installation and setup of the course request manager block for moodle.
Initial Configuration Setting the initial configuration options for the course request manager block for moodle 2.
Setting up the request form - page 1 Setting the configuration options for the first page of the course request form.
Setting up the request form - page 2 Setting the configuration options for the second page of the course request form.
Making Requests - User Perspective An overview of the request process from an end user perspective.
Managing Requests - Admin Perspective An overview of the request management process from an administrator perspective.
Installation of Course Request Manager
The Course Request Manager block is added like other blocks (How to install a block).
Once the Course Request Manager block is installed, it is recommended that you add the block to the front page.
Accessing configuration settings
It is recommended that administrators configure the course request manager before first use.
Once the block has been added to the frontpage, you should see the new course request manager block as shown below
Click on the Configuration link to begin configuring the request manager.
You will be presented with four options
- Admin Options
- Here you can set the course naming conventions, enrollment key options, clear history, category selection settings and communications email addresses. You can also set a start date for the courses that may differ from default start dates.
- Configure E-Mail Settings
- Course Request Manager settings allows you to set administrator emails for communication and set default emails for when courses are approved, received, rejected etc.
- Configure Request Form - Page 1
- The request form is split over two pages. Page one will prompt the user for the shortname and long name of the course to be created. This link will allow you to name those fields and also enable an optional course mode setting.
- Configure Request Form - Page 2
- This allows you to configure the 2nd page of the request. On this page you can create form elements that must be completed by the user as part of the request process. While this information is not used by Course Request Manager, it will allow administrators to gather structured information on the request and aid in the decision making process.
We will look at each of these in turn. Lets start by looking at the Configure Course Request Manager Settings option.
Configure Course Request Manager Settings – Configuring Email Settings
The Configure Course Request Manager screen allows the administrator to configure communication emails as well as some of the course naming conventions etc.
The first recommended step involves adding at least one email address of an administrator who will handle course requests. The system has been set up with a dummy email address (firstname.lastname@example.org), which should be deleted. To enter a new email, simply enter the email address and click on the ‘Add E-Mail’ button.
In this section you can also configure the default emails that are sent at the various stages of a course request. There are 11 possible emails that may be sent by the request manager.
- New Course Approved User E-Mail
- This email is sent to the user when a course request has been approved by the administrator.
- New Course Approved - Admin E-Mail
- A copy of the above email sent to the listed admin emails.
- Request New Course - User E-Mail
- This email is sent to the user as confirmation that a course request has been logged with the system.
- Request New Course - Admin E-Mail
- A copy of the above email sent to the listed admin emails.
- Comment Notification E-Mail - User E-Mail
- An email is sent to the requestor when a comment is added to a course request.
- Comment Notification E-Mail - Admin E-Mail
- An email is sent to the listed administrators when a comment is added to a course request.
- Request Denied E-Mail - User E-Mail
- This email is sent to the requestor when a course request is denied.
- Request Denied E-Mail - Admin E-Mail
- This email is sent to the listed administrators when a course request is denied.
- Handover Request - Current Owner E-Mail
- If a user puts in a course request for a course that already exists on the moodle server, then a course handover process may commence. In this case, an email is sent to the current listed owner(s) of the module requesting that control or access is granted to the requestor (this may be denied).
- Handover Request - User E-Mail
- A copy of the above email which is sent to the requestor.
- Handover Request - Admin E-Mail
- A copy of the above email which is sent to the listed administrators.
Each of the emails has already been initialised with default text. To change an email, simply update the contents in the relevant text area and click on the associated save changes button. (shown below)
In the above image, you can see that the text also contains a number of ‘tags’ that can be inserted into the mail. These can include
- Course code: [course_code]
- Course name: [course_name]
- Enrolment key: [e_key]
- Full URL to new course: [full_link]
- Full Course Request Manager request summary link: [req_link]
When a tag is included, the relevant information will be included in the sent email.
IMPORTANT: To disable an email, simply delete the contents of the text area for that email (including any spaces etc) and click on Save.
Configure Course Request Manager Settings – Configuring Admin Settings
Clicking on the ‘Other Settings’ tab will show the following page
On this page, administrators may change several options which are explained below
Course Naming Convention This option allows you to set a naming convention to courses when they are created as a result of an approved request. By default the course naming convention is full name only. Other options include
- Short name – Full name
- Full Name (Short Name)
Short Name Format The short name format may be altered to include a course mode. The course mode is an optional setting which will be discussed later in the document.
This is useful where two version of the same course may exist on moodle that are delivered in different modes (part time vs full time). The Short Name format may be altered to include this. Enrolment Key By default the enrolment key is automatically generated when the course is created. The CRM block will generate a random 4 number code which will be sent to the user (assuming email is enabled). If you would like to allow users to specify their own enrolment keys during a request, please change the setting to ‘Prompt user for key’
Enrollment Key Course Request Manager can generate an automatic enrolment key or you may choose to prompt the user for an enrolment key of their choice. Automatically generated enrollment keys are in the form of a random four digit number.
Clear History This feature allows the administrator to delete all records of approved courses and course approval activity. Useful when older course request archives are no longer of practical use.
Allow User to Select Category When enabled, the user will be prompted to select a location in the Moodle catalogue to place their course. This is best suited to sites which have logical, easy to understand course categories. A request may be assigned a different category at the approval stage in the event that a user selects a inappropriate location within the category structure.
Communications Email Address Simply enter an email address here which will appear as the sender email address in all communication mails sent from the block. A noreply type mail is recommended e.g email@example.com
Start Date Here you can set the default start date for newly created courses. This may be useful when newly created courses should have a common start date (e.g. the start date for an academic term)
Configure Request Form - Page 1
Now that you have configured the email and naming conventions, it is time to configure the request form for your users. Back on the main config page, select the Configure Request Form - Page 1 link.
The course request form is actually broken into two pages. The first page of the request form is used to accept values from the user for the course short name and the course full name as required by moodle. These may be described differently by your orgaisation. For example you may use a course code (shortname) and a course name (full name) to describe your courses. For each of the two fields below, you may change the name of the field as it appears to the user and also the help text that is associated with each field.
The second part of this form allows you to add an optional ‘mode’ dropdown to the course request. In many educational institutions, the same course or module may be delivered in different modes (part-time, full-time, online etc). By default this option is disabled (hidden from form) but it may be enabled. You may rename the mode field name which will be displayed to the user and also add/delete modes.
Scroll down and click on the save changed button to apply any changes.
Configure Request Form - Page 2
The second page of the request form is where you can configure the additional fields that will allow users to enter/select the required data which is used to help you make a decision when handling a course request.
Setting the current active form
The current active form needs to be set. By default the current active form is the Default form. The Default form is a single text area which prompts the user for more information. This form may be used but it is suggested that you add a new form and configure its form elements.
Here you can add, delete and preview new forms.
- To delete a form simply click on the delete link.
- To preview a form, simply click on the preview link.
- To edit a form, simply click on the edit link.
To create a new form, simply enter the form name and click on the ‘Create a new form’ button.
In the example below, I have added a new form called ‘test’. To begin editing the form, click on the edit link
Editing your form
After clicking on your new form link, you will be shown the following
Here you can start to add form elements (fields) which the users will be asked to complete during a course request. To add a form element, simply select the element type from the ‘Add new field’ drop down. You may add text fields, text areas, drop downs or radio button groups.
In the example below, I have chosen to add a new ‘Text Field’. The following will be displayed
Simply enter a name for the text field (which will be displayed to the user) and click on the ‘Save’ button. We must also decide if the field is to be a required or optional field. In the example below, I am creating a field called programme code.
When I click on the Preview Form link, I can see that page 2 of my form looks as follows
Click on the back button to return to the editing screen. You may continue to add form elements in the manner, building up your request form. Please note that a maximum of 15 form elements can be added to any form.
Remember, when you are finished adding and editing your new form, you must select the form to use for requests
When you are happy that you have created your form and activated it, return to the moodle frontpage or to the location of the course request manager block.
How to make a request (user perspective)
From the moodle frontpage, authenticated users can see the course manager request block. To start a new request, simply click on the ‘Make a request’ link
The first page (of 2) of the request form will now load. This will prompt the user for the shortname and fullname of the course to be requested. You may have renamed these during the earlier config. In the example below, you can see that I have also enabled the ‘prompt for enrolment key’ option so a user will be asked to set a key
In the example above, I am entering a new request for a course called ‘Computers’.
When the user clicks on Continue, the block will check for any potential name clashes with existing courses. In the event that no clash is found, page 2 of the form will be loaded. This page is the one that we created earlier and set as our default form.
The default form (unedited) will simply show a text area for more information (similar to the core moodle request form). Shown below is a form that I created to gather data from my moodle users. Its one I prepared earlier (I’ve waited a long time to say that!)
You can see that on this form, I have added some text fields, a drop down list and a text area. In this way I can get my users to be more specific when entering in course requests and force them to structure the information that will assist in the processing of a request.
Once a user fills out the form and selects the continue button, a summary of the information will be shown on screen. In the example below I have entered some details for my request and this is the summary of those
At this point, a user can submit the request, alter it or simply cancel the request process. Once submitted, the user is redirected to the ‘Manage requests page’. Here a user can view the request, edit the request, cancel the request or add comments to the request.
Managing Your Requests (user perspective)
Users can manage their requests by selecting on the ‘Manage your Requests’ link (show below).
They are then show a list of active and archived requests.
- The view link will simply show a summary of the request and any comments that have been recorded by the user or the admin
- The Edit link will return the user to editing mode and the request details can be entered.
- The Cancel link will delete the request. The user will be asked to confirm cancellation of a request
- The Add / View Comments link will allow the user to attach comments to a request. This may be further clarification or a response to an admin comment etc.
The comments page will show the date and time of the comment, the contents of the comment and the username of the author of the comment.
Admin functions - Processing the request queue
The Request queue link will allow administrators to manage course requests and view archived requests.
Once clicked, a list of active course requests will be displayed
You can see from the screenshot above, that a administrator can approve, deny, edit, delete or add/view comments for a given request.
Lets work through an aproval process
Approve a Request
The administrator has two options
- Quick Approve
The main difference between the two is that the quick approve will process the request as is. It will not enter any confirmation screens or load the newly created course settings page for the admin to tweak. If you wish to change some of the settings for a course after approval (e.g number of weeks of format) then the approve link should be selected.
Clicking on the approve link will display a summary of the request.
You will notice two links at the bottom of the request summary
- Open Details – this will open the request details in a pop up window. We added this feature as sometimes you may wish to remind yourself of some of the request details during the approval process.
- Approve Request – This commences the approval process.
Clicking on the open details link will display a pop up window similar to the one shown below
Clicking on the approve link will create the new moodle course and bring you to the course edit screen. We direct to the edit screen at this point in case you need to alter some course details and/or set the location of the new course in the catalog.
If enabled, a confirmation mail will be sent to the request originator.
Deny A Request
To deny a request, simply select the Deny link. A confirm screen will be displayed prompting you to enter a reason for the denial.
Once you click on the Deny Request button, the request will be marked as denied, a mail will be sent to the user (if enabled) and the request will be moved to the archived requests tag. Once request has been denied, it cannot be reopened.
Other request processing functions
Administrators can also
- Bulk Approve: This will simply approve any selected courses. Its pretty neat and a real time saver when you have a large queue to be processed. Note that the category needs be be selected for courses before they can be approved.
- Edit a Request: This allows an administrator to edit any of the entered details for the request.
- Delete a request: This allows the administrator to delete the request
- Add / View Comments: As with the user function, this allows an administrator to add or view comments for a request.
Course Request Manager makes use of the Moodle permissions system. The block assumes that the following user roles are in existence
teacher coursecreator editingteacher manager student guest
When the bock is installed, users groups have the following permissions
Admin: Complete control over the block including config and managing of requests etc Manager: Managing of requests - cannot update the config of the block Course Creator: Managing of requests - cannot update the config of the block Teacher: Those with a site level Teacher role can request courses. By default the teacher role is not a system role. Student: Can view the block but cannot access any functions (this may be disabled in the block permissions) Guest: Can view the block but cannot access any functions (this may be disabled in the block permissions)
There are two approaches
Allocate users who you want to be able to request courses the ‘Teacher’ role at the site level *some sites do this - we dont*
Most sites will 1. Create a new site role called “Course Requestor” e.g. Site Administration >> Users >> Permissions >> Define Roles >> Add new role 2. Base the role on Authenticated User 3. Allow the role to be assigned at System level (or block level) 4. Grant the following permissions for Block: Course Request Manager Add comment (block/cmanager:addcomment) Add Record (Add Record) Delete Record (block/cmanager:deleterecord) Edit Record (block/cmanager:editrecord) View Record (block/cmanager:viewrecord) 5. Assign some users to this new role.
Thats it. You should be good to go.
You can also remove or add permissions to the manager and course creator roles using define permissions.
The course request manager block will display different options depending on the role of the user. Administrators will have access to all of the block functions
However non administrators will only have access to the make and manage request functions
I sometimes get asked about how to hide the block from certain user groups. Again this can be done by making the block invisible to some user roles. The procedure differs across different versions of moodle. In 2.5+ do the following 1.Turn editing on in the course 2. Click the Assign roles icon (a face and mask) in the header of the block 3. In the administration block, go to Block administration > Permissions (ignore the message 'You are not able to assign any roles here', which is to be expected, since roles are not generally assigned in the block context) 4. Now click the 'permissions' link on the administration block 5. Remove the view permission from any unwanted user groups (or add them to the prohibit list)