Note: You are currently viewing documentation for Moodle 3.8. Up-to-date documentation for the latest stable version of Moodle may be available here: blocks/cmanager/.

blocks/cmanager/: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 351: Line 351:


[[File:cmanager27.png]]
[[File:cmanager27.png]]
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.
[[File:cmanager28.png]]
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
- 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 ==
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
[[File:cmanager3.png]]
However non administrators will only have access to the make and manage request functions
[[File:cmanager29.png]]
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
[[File:cmanager30.png]]
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!)
By dong this, I will need to ensure that any teachers on my site are given a front page teacher role.
[[File:cmanager31.png]]
The advantage of this is that I can now prevent student users and other authenticated users from accessing the block.

Revision as of 17:36, 25 July 2012

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


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.

cmanager1.png


Once added, the block will run a short configuration script that will initialise course request manager for your moodle installation.

cmanager2.png



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

cmanager3.png


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

You will be presented with three options

- Configure Course Request Manager Settings Course Request Manager settings allows you to set administrator emails for communication, set default emails, set course naming conventions and default course settings such as start date and enrolment key policy.

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

cmanager4.png

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

cmanager5.png


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

Clicking on the ‘Other Settings’ tab will show the following page

cmanager6.png


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’

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

cmanager7.png

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.

cmanager8.png

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.

cmanager9.png


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.

File:File:cmanager10.png


8.2. Manage Forms Here you can add, delete and preview new forms.

To delete a form simply click on the delete icon. To preview a form, simply click on the preview icon. To edit a form, simply click on its name.


To create a new form, simply enter the form name and click on the ‘Create a new form’ button.

cmanager11.png


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

cmanager12.png



Editing your form

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

cmanager13.png

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.

cmanager14.png

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

cmanager15.png


Simply enter a name for the text field (which will be displayed to the user) and click on the ‘Save’ button. I 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

cmanager16.png


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

cmanager17.png

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

cmanager3.png


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

cmanager18.png


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


cmanager19.png


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


cmanager20.png


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’

cmanager21.png

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

cmanager3.png

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

cmanager22.png


The view link will simply show a summary of the request and any comments that have been recorded by the user or the admin

cmanager23.png

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.

cmanager24.png


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.

cmanager3.png

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

cmanager25.png


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

Clicking on the approve link will display a summary of the request.

cmanager26.png


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

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

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


cmanager27.png


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.

cmanager28.png


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


- 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

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

cmanager3.png


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

cmanager29.png


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

cmanager30.png

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

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

cmanager31.png


The advantage of this is that I can now prevent student users and other authenticated users from accessing the block.