blocks/cmanager/: Difference between revisions

From MoodleDocs
m (→‎System Requirements: clean up, typos fixed: Github → GitHub)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Course Request Manager for Moodle 2 ==
== Course Request Manager for Moodle 2 ==


 
== Introduction ==
== '''Introduction''' ==
 


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.
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.


== System Requirements ==


 
The Course Request manager block requires Moodle 2.3 and above. A Moodle 1.9 version (unsupported) can also be downloaded from GitHub.
== '''System Requirements''' ==
 
The Course Request manager block requires Moodle 2.3 and above. A Moodle 1.9 version (unsupported) can also be downloaded from github.
[https://github.com/Kylegoslin/Course-Request-Manager GITHUB]
[https://github.com/Kylegoslin/Course-Request-Manager GITHUB]


== Screencasts (new) ==
== Screencasts (new) ==
Line 20: Line 14:
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
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


[http://www.screenr.com/q6L8 Installation and Setup]
* [http://www.screenr.com/q6L8 Installation and Setup]: A quick overview of the installation and setup of the course request manager block for moodle.
A quick overview of the installation and setup of the course request manager block for moodle.
* [http://www.screenr.com/56L8 Initial Configuration]: Setting the initial configuration options for the course request manager block for moodle 2.
 
* [http://www.screenr.com/I6L8 Setting up the request form - page 1]: Setting the configuration options for the first page of the course request form.
[http://www.screenr.com/56L8 Initial Configuration]
* [http://www.screenr.com/2JL8 Setting up the request form - page 2]: Setting the configuration options for the second page of the course request form.
Setting the initial configuration options for the course request manager block for moodle 2.
* [http://www.screenr.com/4JL8 Making Requests - User Perspective]: An overview of the request process from an end user perspective.
 
* [http://www.screenr.com/FJL8 Managing Requests - Admin Perspective]: An overview of the request management process from an administrator perspective.
[http://www.screenr.com/I6L8 Setting up the request form - page 1]
Setting the configuration options for the first page of the course request form.
 
[http://www.screenr.com/2JL8 Setting up the request form - page 2]
Setting the configuration options for the second page of the course request form.
 
[http://www.screenr.com/4JL8 Making Requests - User Perspective]
An overview of the request process from an end user perspective.  


[http://www.screenr.com/FJL8 Managing Requests - Admin Perspective]
== Installation of Course Request Manager ==
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).
The Course Request Manager block is added like other blocks (How to install a block).
Line 46: Line 29:
[[Image:crm43_1.png|frame|center|Add the Block]]
[[Image:crm43_1.png|frame|center|Add the Block]]


== '''Accessing configuration settings''' ==
== Accessing configuration settings ==
 


It is recommended that administrators configure the course request manager before first use.
It is recommended that administrators configure the course request manager before first use.
Line 54: Line 36:


[[Image:crm43_2.png|frame|center|The Block]]
[[Image:crm43_2.png|frame|center|The Block]]


Click on the Configuration link to begin configuring the request manager.
Click on the Configuration link to begin configuring the request manager.


You will be presented with four options
You will be presented with four options


*Admin 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.  
: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 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.
*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.
We will look at each of these in turn. Let's start by looking at the Configure Course Request Manager Settings option.
 
== '''Configure Course Request Manager Settings – Configuring Email Settings''' ==


== 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 Configure Course Request Manager screen allows the administrator to configure communication emails as well as some of the course naming conventions etc.
Line 91: Line 58:
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.
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.


*'''New Course Approved User E-Mail '''
Each of the emails has already been initialized 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)
: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)


[[Image:crm43_4.png|frame|center|eMail template with tags]]
[[Image:crm43_4.png|frame|center|eMail template with tags]]


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
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 code:''' [course_code]
*'''Course name:''' [course_name]
* '''Course name:''' [course_name]
*'''Enrolment key:''' [e_key]
* '''Enrolment key:''' [e_key]
*'''Full URL to new course:''' [full_link]
* '''Full URL to new course:''' [full_link]
*'''Full Course Request Manager request summary link:''' [req_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.
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.
'''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==
== Configure Course Request Manager Settings – Configuring Admin Settings==
Line 151: Line 91:


[[Image:crm43_5.png|frame|center|Other Settings]]
[[Image:crm43_5.png|frame|center|Other Settings]]


On this page, administrators may change several options which are explained below
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


'''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
* Short name – Full name
* Full Name (Short Name)
* Full Name (Short Name)
   
   
'''Short Name Format '''
'''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.  
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.
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.


'''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’


'''Communications Email Address'''
'''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.
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 noreply@mymoodleserver.domain


'''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 an 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 no-reply type mail is recommended
e.g. noreply@mymoodleserver.domain


'''Start Date'''
'''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)
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 ==
== 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.
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.
Line 198: Line 120:
[[Image:crm43_30.png|frame|center|Config Menu]]
[[Image:crm43_30.png|frame|center|Config Menu]]


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 course request form is actually split 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 organization. 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 the help text that is associated with each field.


[[Image:crm43_7.png|frame|center|Edit form page 1]]
[[Image:crm43_7.png|frame|center|Edit form page 1]]


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.
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 add/delete modes.


[[Image:crm43_8.png|frame|center|Setting the mode]]
[[Image:crm43_8.png|frame|center|Setting the mode]]


Scroll down and click on the save changed button to apply any changes.
Scroll down and click on the save changed button to apply any changes.
Line 213: Line 134:
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.  
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.  
 
'''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.  


[[Image:crm43_9.png|frame|center|Form page 2]]
[[Image:crm43_9.png|frame|center|Form page 2]]
Line 225: Line 142:
Here you can add, delete and preview new forms.  
Here you can add, delete and preview new forms.  


*To delete a form simply click on the delete link.   
* To delete a form simply click on the delete link.   
*To preview a form, simply click on the preview link.  
* To preview a form, simply click on the preview link.  
*To edit a form, simply click on the edit 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.
To create a new form, simply enter the form name and click on the ‘Create a new form’ button.


[[Image:crm43_10.png|frame|center|Create a new form]]
[[Image:crm43_10.png|frame|center|Create a new form]]


In the example below, I have added a new form called ‘test’. To begin editing the form, click on the edit link
In the example below, I have added a new form called ‘test’. To begin editing the form, click on the edit link
Line 245: Line 159:


[[Image:crm43_11.png|frame|center|Form editing page]]
[[Image:crm43_11.png|frame|center|Form editing page]]


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.
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.


[[Image:crm43_12.png|frame|center|Adding Elements]]
[[Image:crm43_12.png|frame|center|Adding Elements]]


In the example below, I have chosen to add a new ‘Text Field’. The following will be displayed
In the example below, I have chosen to add a new ‘Text Field’. The following will be displayed


[[Image:crm43_13.png|frame|center|New text field]]
[[Image:crm43_13.png|frame|center|New text field]]


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.
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.
Line 264: Line 174:
[[Image:crm43_14.png|frame|center|Form Preview]]
[[Image:crm43_14.png|frame|center|Form Preview]]


Click on the back button to return to the editing screen.


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.  
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
Remember, when you are finished adding and editing your new form, you must select the form to use for requests


[[Image:crm43_15.png|frame|center|Setting the default form]]
[[Image:crm43_15.png|frame|center|Setting the default form]]


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.
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.
Line 281: Line 189:


[[Image:crm43_19.png|frame|center|Block]]
[[Image:crm43_19.png|frame|center|Block]]


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
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


[[Image:crm43_17.png|frame|center|New course request page 1]]
[[Image:crm43_17.png|frame|center|New course request page 1]]


In the example above, I am entering a new request for a course called ‘Computers’.
In the example above, I am entering a new request for a course called ‘Computers’.
Line 292: Line 198:
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.
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!)
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 have waited a long time to say that!)
 


[[Image:crm43_18.png|frame|center|Sample form]]
[[Image:crm43_18.png|frame|center|Sample form]]


 
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.
 
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
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


[[Image:crm43_20.png|frame|center|User request summary]]
[[Image:crm43_20.png|frame|center|User request summary]]


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.
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) ==
== Managing Your Requests (user perspective) ==
Users can manage their requests by selecting on the ‘Manage your Requests’ link (show below).
Users can manage their requests by selecting on the ‘Manage your Requests’ link (show below).


Line 318: Line 220:
[[Image:crm43_21.png|frame|center|Manage Requests]]
[[Image:crm43_21.png|frame|center|Manage 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 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 Edit link will return the user to editing mode and the request details can be entered.
* 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 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.


[[Image:crm43_22.png|frame|center|View/Add Comments]]
[[Image:crm43_22.png|frame|center|View/Add Comments]]


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.
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.
Line 342: Line 239:
[[Image:crm43_24.png|frame|center|Active Requests]]
[[Image:crm43_24.png|frame|center|Active Requests]]


You can see from the screenshot above, that an administrator can approve, deny, edit, delete or add/view comments for a given request.


You can see from the screenshot above, that a administrator can approve, deny, edit, delete or add/view comments for a given request.
Let's work through an approval process.
 
Lets work through an aproval process


== Approve a Request==
== Approve a Request==


The administrator has two options
The administrator has two options
*Quick Approve
*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.
* Quick Approve
* 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.  
Clicking on the approve link will display a summary of the request.  


[[Image:cmanager26.png|frame|center|Request Summary]]
[[Image:crm43_25.png|frame|center|Request Summary]]


You will notice two links at the bottom of the request summary:


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.


*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.
Clicking on the open details link will display a pop-up window similar to the one shown below


*Approve Request – This commences the approval process.
[[Image:crm43_26.png|frame|center|View/Summary in Pop-Up]]


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.


Clicking on the open details link will display a pop up window similar to the one shown below
If enabled, a confirmation mail will be sent to the request originator.


== Deny A Request==


[[Image:cmanager27.png|frame|center|View/Summary in Pop Up]]
To deny a request, simply select the Deny link. A confirm screen will be displayed prompting you to enter a reason for the denial.  
 
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.


[[Image:crm43_27.png|frame|center|View/Confirm Deny Request]]


If enabled, a confirmation mail will be sent to the request originator.
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 a request has been denied, it cannot be reopened.


== Deny A Request==
== Other request processing functions ==


To deny a request, simply select the Deny link. A confirm screen will be displayed prompting you to enter a reason for the denial.
Administrators can also


[[Image:cmanager28.png|frame|center|View/Confim Deny Request]]
* 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 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.


== User Permissions ==


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.
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, user's 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)


== Other request processing functions ==
There are two approaches:


Administrators can also
Allocate users who you want to be able to request courses the ‘Teacher’ role at the site level *some sites do this - we do not*


*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.
OR


*Edit a Request: This allows an administrator to edit any of the entered details for the request.
Most sites will:


*Delete a request: This allows the administrator to delete the request
1. Create a new site role called “Course Requestor” e.g. Site Administration >> Users >> Permissions >> Define Roles >> Add new role


*Add / View Comments: As with the user function, this allows an administrator to add or view comments for a request.
2. Base the role on Authenticated User


== User Permissions ==
3. Allow the role to be assigned at System level (or block level)
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


[[Image:cmanager3.png|frame|center|View/Block]]
4. Grant the following permissions for Block: Course Request Manager


* Add comment (block/cmanager:addcomment)
* Add Record (block/cmanager:addrecord)
* Delete Record (block/cmanager:deleterecord)
* Edit Record (block/cmanager:editrecord)
* View Record (block/cmanager:viewrecord)


However non administrators will only have access to the make and manage request functions
5. Assign some users to this new role.


[[Image:cmanager29.png|frame|center|Non-Admin view]]
That is it. You should be good to go.


You can also remove or add permissions to the manager and course creator roles using define permissions.


In many cases, you may need to set permissions to the block. For more information on setting permission, check moodle documentation. In the example below, the block has the following permissions
The course request manager block will display different options depending on the role of the user. Administrators will have access to all the block functions.


[[Image:cmanager30.png|frame|center|Alter Permissions]]
[[Image:crm43_23.png|frame|center|View/Block]]


However non administrators will only have access to the make and manage request functions


I am going to alter the permissions so only the teacher role will have access to the View Block capability. I have also removed the ability for them to edit the blocks settings (we don’t want teachers playing with the block!)
[[Image:crm43_16.png|frame|center|Non-Admin view]]


By dong this, I will need to ensure that any teachers on my site are given a front page teacher role.
== Block Visibility ==


[[Image:cmanager31.png|frame|center|Adjust Roles]]
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:


The advantage of this is that I can now prevent student users and other authenticated users from accessing the block.
# Turn editing on in the course.
# Click the Assign roles icon (a face and mask) in the header of the block.
# 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).
# Now click the 'permissions' link on the administration block.
# Remove the view permission from any unwanted user groups (or add them to the prohibit list).

Latest revision as of 15:08, 2 June 2022

Course Request Manager for Moodle 2

Introduction

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.

System Requirements

The Course Request manager block requires Moodle 2.3 and above. A Moodle 1.9 version (unsupported) can also be downloaded from GitHub. GITHUB

Screencasts (new)

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 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.

Add the Block

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

The Block

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 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. Let's 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.

Configuration

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 (youremail@domain.com), 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 initialized 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)

eMail template with tags

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

Other Settings

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’

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 an 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 no-reply type mail is recommended e.g. noreply@mymoodleserver.domain

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.

Config Menu

The course request form is actually split 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 organization. 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 the help text that is associated with each field.

Edit form page 1

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 add/delete modes.

Setting the mode

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.

Form page 2

Manage Forms

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.

Create a new form

In the example below, I have added a new form called ‘test’. To begin editing the form, click on the edit link

Sample form

Editing your form

After clicking on your new form link, you will be shown the following

Form editing page

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.

Adding Elements

In the example below, I have chosen to add a new ‘Text Field’. The following will be displayed

New text field

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

Form Preview

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

Setting the default form

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

New course request page 1

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 have waited a long time to say that!)

Sample form

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

User request summary

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).

Block

They are then show a list of active and archived requests.

Manage 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.
View/Add Comments

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.

Block

Once clicked, a list of active course requests will be displayed

Active Requests

You can see from the screenshot above, that an administrator can approve, deny, edit, delete or add/view comments for a given request.

Let's work through an approval process.

Approve a Request

The administrator has two options

  • Quick Approve
  • 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.

Request Summary

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

View/Summary in Pop-Up

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.

View/Confirm Deny Request

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 a 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 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.

User Permissions

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, user's 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 do not*

OR

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 (block/cmanager:addrecord)
  • Delete Record (block/cmanager:deleterecord)
  • Edit Record (block/cmanager:editrecord)
  • View Record (block/cmanager:viewrecord)

5. Assign some users to this new role.

That is 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 the block functions.

View/Block

However non administrators will only have access to the make and manage request functions

Non-Admin view

Block Visibility

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).