MoodleDocs - User contributions [en]

Update profile

2009-12-29T02:23:15Z

Markstevens:

Location: ''Administration > Users > Accounts > Add a new user'' or ''Browse list of users'', or by choosing the ''Edit profile'' tab from one's own profile.

==Updating Your Profile ==
{{Moodle 1.8}}
The fields are divided into 3 sections - General, Picture & Optional which are all explained below. Note that some settings are 'advanced', so you may need to click the 'Show Advanced' button on the right to see all the settings. The advanced settings are indicated below.

Remember to click 'Update profile' when you have finished.

=== General ===

The first section contains fields that must be completed:

'''First name & Surname'''

These are self-explanatory. These names will identify you everywhere in your Moodle courses.

'''Email address'''

The email address should be an address that you check regularly. It is used for acknowledgements and announcements from Moodle, including messages from Forums that you are subscribed to. It is also the address that is displayed to other users of Moodle, depending on your 'Email display' setting (below).

'''Email display'''

This controls the visibility of your email address to others. The three settings are self-explanatory but please note 'Hide my email address from everyone' only hides it from students. Teaching staff and other staff with editing access will always be able to see your email address.

'''Email activated'''

You can either enable or disable emails being sent to an address. Note that if this is disabled, you will not receive any email whatsoever from the site. This is not recommend, as you may miss important course-related messages.

'''Email format (advanced)'''

There are two formats: "Pretty HTML format" (messages will be formatted) and "Plain text format" (plain text with no formatting).

'''Email digest type (advanced)'''

This setting determines how you receive any posts from Forums to which you are subscribed, allowing you to receive messages individually or on a daily basis.

'''Forum auto-subscribe (advanced)'''

This setting lets you decide if you want email copies of posts that are added to forums. If you set this to subscribe, the system will automatically email you copies of new posts in forums that you post in, unless you manually override it when posting.

'''Forum tracking (advanced)'''

Enabling forum tracking means highlighting the posts you have not read yet, which should improve your forum navigation.

'''When editing text (advanced)'''

This can usually be left on "Use HTML editor (some browsers only)". This allows for text formatting options, but requires newer browsers. If you find your browser is not letting you edit text, change this setting to "Use standard web forms".

'''AJAX and JavaScript (advanced)'''

This determines whether the Moodle interface will use advanced navigation features such as drag-and-drop, that require AJAX and JavaScript to function. These features can cause problems on some browsers so you might prefer to turn them off.

'''Screen Reader (advanced)'''

If you use a screen reader, this setting should be set to 'Yes'. (A screen reader is a form of 'assistive technology' used by blind and partially-sighted users to interpret what is displayed on the screen).

'''City/town & Country'''

Add your location.

'''Timezone'''

This field is used to convert time-related messages on the system (such as assignment deadlines) from the local timezone (the time in London) to the correct time in whichever zone you have selected.

'''Preferred language and theme (advanced)'''

You can view Moodle in several different languages and colour themes, which you can select via these two options. Note: changing the preferred language only affects the Moodle interface, not the course content!

'''Description'''

In this field you can enter some text about yourself, be it information about your studies, hobbies, qualifications or anything else.

=== Picture ===

This section is optional and allows you to choose your own profile picture. Your current picture is shown, if you have already chosen one.

'''New picture'''

The Browse button allows you to choose a new picture for your profile. Your picture is uploaded when you choose the 'Update Profile' at the bottom of the page.

Your picture will be resized by Moodle when you upload it - to 100 pixels by 100 pixels for the larger view (e.g. in your profile) and 35 pixels by 35 pixels for the smaller view (e.g. on the Forums). If the picture you upload is not square, Moodle will automatically crop the image to make it square.

=== Optional ===

There are several optional fields (all advanced) allowing you to add further details to your profile such as contact details and your website.

===Custom Profile Categories===
If any custom user profile categories and fields have been created on your Moodle site, they will be listed at the bottom of the [[User profile fields|Admin >Accounts>User profile fields]]

==Adding a new user==

The add a new user page allows you to manually create a new user account. If you create a test account, you can use a made-up email address.

The required field must be entered before the user will be accepted by Moodle. The required fields in a standard Moodle install are: Username, New password, Surname, Email address, City/town, Select a country.

Validity checks on the required field are performed. For example, usernames can only contain alphabetical letters or numbers. As a result using the underscore character '_' is not permitted; however, using a period is permitted. So a username of joe_smith would not be allowed but joe.smith is permissible. The email address should be in the format of a valid email (for example, joe.smith@myisp.com). If password complexity requirements are enabled by the site administrator, the new password field is also checked to ensure it complies with those requirements. See [[admin/setting/sitepolicies#Password_policy|Password policy]] for more information.

Other fields that are part of a user's profile can also be filled out when the user is created. Some of the profile fields can be revealed by pressing the "Show Advanced" button.

The new user information is saved by pressing the "Update user" button near the bottom of the form.

Note: You can always create new accounts manually, regardless of which [[Authentication|authentication method]] you are using.

==Updating a user profile==

Users with the capability [[Capabilities/moodle/user:update|moodle/user:update]] are able to update another user's profile i.e. in addition to being able to edit the profile, all settings (username, password, authentication method, force new password etc.) may be changed.

==Account disabling==

An account may be disabled by setting the authentication method to "[[No login]]". The account email may not be used to create another account.

[[Category:Administrator]]

[[fr:Modifier le profil]]
[[de:Nutzerprofil aktualisieren]]

Development:Editor file management

2009-08-04T03:09:52Z

Markstevens:

This document is to start a usability discussion about the best way to implement a particular new feature in Moodle 2.0.

HTML texts may have associated embedded media, such as images, videos and sounds. These are added to the HTML file using the HTML editor (which in Moodle 2.0 is a modified version of TinyMCE) and stored in the "file area" associated with the text. This applies to all texts in Moodle 2.0, ranging from simple forum posts to full-blown mini-web sites in the Resource module.

There may be more than one file, and files may change or require deletion, so they need to be managed.

The question we need to solve is: "What is the best interface to manage and browse these files?"

== Conventions ==

[[Image:wordpress2.8-upload-a.png|thumb|Wordpress 2.8]][[Image:wordpress2.8-upload-b.png|thumb|Wordpress 2.8]]
Example 1: Office document (Word, OpenOffice, Google Docs). Once the "Open" dialog is used to bring the media into the page, the only way it can be removed from the document is by deleting it from the document directly. Office applications do not have a way of managing media separately from the document view.

Example 2: Dreamweaver.

Example 3: Box net. Documents can be made and images added, but there is no interface in the document to manage media. However, when looking at the filesystem view one can see the media in a folder and can edit it. Obviously changing names and deleting things will break the links in the HTML.

Example 4: Wordpress: Separate tabs for Uploading from PC, uploading from URL, and selecting an image from Media Library (files already on server). When image is uploaded in first two, there is a list of the files already uploaded. In any of the three tabs, when an image is selected, options for its display are shown, along with an option to delete. See: http://demo.opensourcecms.com/wordpress/wp-admin/page-new.php (user:admin, password:demo123 or see http://php.opensourcecms.com/scripts/details.php?scriptid=88&name=WordPress)

(TODO: more examples)

== Related Moodle 2 features ==

===File picker ===

The file picker is designed to mimic the file open dialog.

As usual, the button/link/menu that initiates the file picker can specify what mime types are being looked for, and the resulting display is limited to those repositories that support those mime types, and only files matching the mime types are shown.

===File manager form element ===

The file manager form element allows any form to have a managed set of files, such as a set of attachments to a forum post. Files can be added (by calling the file picker) or deleted (by pressing a little X next to any file).

[[Image:Filemanagerform.png]]

==Mockups==

Click on this diagram to see the full-sized version:

[[Image:Editor_file_management.png]]

=== Mockup A ===

File manager in the Insert/Edit dialog.

Pros:
* Management is kept separate from the file picker
* Interface is similar to file manager forms element
* No extra icon needed in editor toolbar

Cons:
* Insert/Edit image dialog needs to be modified, and maintained
* harder to deal with many files
* Interface clutter for people who won't use this feature
* Files can be deleted here resulting in missing media from the HTML.

=== Mockup B ===

File manager is implemented as a separate repository inside the filepicker eg "Current files".

Pros:
* Very easy to implement across Moodle, no changes to editors are needed.
* Makes sense when re-choosing images already chosen (eg. to add another copy of the same image).

Cons:
* Breaks the paradigm of the "file picker" because files can be deleted, zips uploaded etc.
* "Current files" difficult to separate logically from the "Local files".
* Files can be deleted here resulting in missing media from the HTML.
* Constantly clutters repository list with an item that many will not use.
* Inconsistent with the filemanager form element (used for attachments etc)
* Either we show all files (ignore mimetype) or only show files matching mimetype (incomplete management)

=== Mockup C ===

File manager is implemented separately from file picking, as a new tinymce plugin.

Pros:
* Functionality is separate from the file picker so file picker paradigm preserved
* People who don't need it don't have to see it (unclutters interface)
* Interface is very similar to the file manager form element

Cons:
* Requires a new tinymce plugin that needs maintenance
* Requires a whole new icon in the editor toolbar.
* Files can be deleted here resulting in missing media from the HTML.

==Some use cases in more detail==

(In progress)

===Add a new image to a post somewhere in Moodle===

* Click on the image button
* Click on the search button
* Select a file from a repository (or upload)
* Add metadata and preferences.
* Insert the image

===Add an image AGAIN to a post somewhere in Moodle===
* Click on the image button
* Click on the search button
* Select the image from the "Recent files" repository
* Add metadata and preferences again
* Insert the image

===Add an attachment to anything===
* Click on "Add" in the file manager form element
* Select a file from a repository (or upload)
* File is added

==Discussion==

So, what is best?

Discussion is here: [http://moodle.org/mod/forum/discuss.php?d=127238 RFC: Editor file management in Moodle 2.0]

Random Short-Answer Matching question type

2009-08-04T02:55:11Z

Markstevens:

{{Questions}}

* From the student perspective, this looks just like a [[Matching question type|Matching question]]. The difference is that the sub-questions are drawn randomly from the [[Short-Answer question type|Short Answer questions]] in the current category.
* After an optional introduction, the respondent is presented with two or more sub-questions, each with a drop-down menu box opposite listing the same number of available answer options.
* The respondent must select an answer option to match each sub-question.
* Each sub-question is equally weighted to contribute towards the grade for the total question.
* The questions and answers are randomly drawn from the pool of short-answer questions in the current category. Each attempt on a quiz will have different questions and answers.
* You must make sure that the category contains enough unused short-answer questions, otherwise the student will get an error message. The more short-answer questions you add to the category, the more likely it is that students will see a new selection on each attempt.
* Note that the answer options are taken from the '''correct''' answers of each contributing short-answer question. Therefore, if the short-answer questions in this category are on different topics, this question type will not be useful, as the correct option will be obvious.
** An example that doesn't work - suppose the category contains 2 short-answer questions, as follows:
1. What is the capital of France?
Correct answer: Paris
Other recognised answers: Lyon, Marseilles, *
2. What vegetable is called 'løk' in Norway?
Correct answer: Onion
Other recognised answers: Leek, *

** The resulting Random Short-Answer Matching question will appear as follows:
What is the capital of France?
- Options: Paris, Onion.
What vegetable is called 'løk' in Norway?
- Options: Paris, Onion.

** An example that does work - the 2 short-answer questions in the category are as follows:
1. What is the capital of France?
Correct answer: Paris
Other recognised answers: Lyon, Marseilles, *
2. In what city is Le Corbusier's "Unite d'Habitation"?
Correct answer: Marseilles
Other recognised answers: Paris, Lyon *

** The resulting Random Short-Answer Matching question will appear as follows:
What is the capital of France?
- Options: Paris, Marseilles.
In what city is Le Corbusier's "Unite d'Habitation"?
- Options: Paris, Marseilles.

==Question set-up==

# Select the question category.
# Give the question a descriptive name - this allows you to identify it in the question bank.
# Enter the question text to tell the students what they are matching, or use the default text.

# Set the 'default question grade' (i.e. the maximum number of marks for this question).
# Set the 'Penalty factor' (see [[Random_Short-Answer_Matching_question_type#Penalty_factor|Penalty factor]] below).
# ''Moodle 1.7+:'' If you wish, add general feedback. This is text that appears to the student after he/she has answered the question.
# Select the number of questions you want to add to the matching question - make sure this is less than or equal to the number of short-answer questions available in this category.
# Click Save changes.

=== Penalty factor ===

The 'penalty factor' only applies when the question is used in a quiz using adaptive mode - i.e. where the student is allowed multiple attempts at a question even within the same attempt at the quiz. If the penalty factor is more than 0, then the student will lose that proportion of the '''maximum''' grade upon each successive attempt. For example, if the default question grade is 10, and the penalty factor is 0.2, then each successive attempt after the first one will incur a penalty of 0.2 x 10 = 2 points.

[[fr:Question à réponses aléatoires]]
[[ca:Tipus_de_pregunta_de_aparellaments_aleatoris_de_resposta_breu]]
[[ja:ランダム記述組み合わせ問題タイプ]]
[[de:Zufällige Kurzantwort-Zuordnung]]

Teaching tips and tricks

2009-08-04T02:50:41Z

Markstevens:

Here are some frequently asked questions about courses by teachers with some tips and tricks. Don't forget there are other pages in MoodleDocs that deal with the details of a course. The teacher category at the bottom of this page has a nice index. Forums also have a wealth of tips and tricks.

==How can I force automatic course enrollment?==

You can link to a course in an HTML block, using the resources drop down or indeed any other method and then use the following URL (where 999 is your course ID):

http://yourmoodlesite.com/moodle/course/enrol.php?id=999&confirm=1

==How can I embed a web page in my course?==

Using an iframe in a label allows external or internal web pages to be displayed in the middle of the Moodle screen (instead of just putting a link to them)

How:
* Create a label
* Display raw HTML code (use the editor button <>
* Insert code like: <iframe width="100%" height="200" align="middle" src="http://www.google.com" border="0"></iframe>

==How can I copy my course or part of it?==
There are several ways. These methods can be used to store any activity as a template. For example, a teacher might want to duplicate an assignment for different groups that will appear under different weeks in the same course. Or take a Lesson in one course and use it in another course.

===Import course data===
*[[Import_course_data]] is probably the most straightforward. It brings in any other courses material by activity group. For example, you can import all of the lessons from one course you have rights to into another, but not just a single lesson.

===Use backup to duplicate or copy===
*Backing up a course. Each version of Moodle has different options for backing up. The basic process in copying a course, is to create a backup and then select "new course" when restoring that backup.
**Understand what options you DO and DO NOT need to backup, so your copy has just what it needs. For example, you may not want to see any student information or files in your new course, so don't back those up.
**Version 1.6 backup process has lots of boxes to check or uncheck next to every activity and resource that is in the course. Version 1.5.3 has a list of activity types to select for inclusion in a backup.
**One of the old tricks in 1.5.3 and earlier version, is to restore the old course to a new course. Then edit down the new course to just the activities you want.
**Want the same activity in 5 courses you already created? Create a backup of a course that only contains the activity you want. Now restore that course by selecting the option "add to existing course, keep data", repeat it for every one of your 5 courses.

Here is the MoodleDoc page [[Course_backup]] that will give you more details.

===Use Import or Sharing Cart to duplicate a single item===
* See [[Duplicating_Activities_and_Resources|Duplicating Activities and Resources]]

==Creating a course on our website takes too long==
Depending upon your connection speed, screen refresh rates can really slow the creation process. As a teacher, you might consider [[Complete_install_packages|adding a complete install package of Moodle]] on your desktop as a localhost. Be sure that you have a method of restoring your desktop localhost backup to your web based Moodle. And of course, your localhost version should be the same version as your web based Moodle.

== My course looked good then something happened==
With the best of software, sometimes strange things just happen. For example, a list of activities does not look right. Or, you can not move things some places. All you really know is that things were working fine and then they only sort of work.
:''Tip:'' Try a [[backup]] of your course and [[restore]] it to a new course to see if that fixes things. If so you might consider restoring the backup to your existing course, deleting data from it first.

==See also==
[[Label]]
[[Category:Teacher]]

[[es:Consejos y Trucos]]
[[eu:Aholkuak_eta_trikimailuak]]
[[fr:Trucs et astuces]]

Development:Unit tests

2009-07-29T08:46:15Z

Markstevens:

{{Moodle 1.7}}Location: ''Administration > Reports > Unit tests''

The purpose of Unit Tests is to evaluate the individual parts of a program (functions, and methods of classes) to make sure that each element individually does the right thing. Unit Tests can be one of the first steps in a quality control process for developing or tweaking Moodle code. The next steps will involve other forms of testing to ensure that these different parts work together properly.

The unit testing framework is based on the [http://www.simpletest.org/ SimpleTest] framework.

== Running the unit tests in Moodle ==

=== Running the basic tests ===

# Log in with an admin account.
# Administration ► Development ► Unit tests (moodle >= 2.0, Administration ► Reports ► Unit tests Moodle <= 1.9)
# Click on the '''Reports''' link near the bottom of the page.
# Click the '''Run tests''' button and wait.

This finds all the tests in Moodle and runs them. You can run a subset of the tests by entering a path (for example question/type) in the 'Only run tests in' box. Similarly, if a test fails, you get some links in the failure message to make it easy to re-run just those tests.

== Writing new tests ==

As an example, suppose we wanted to write some tests for the string_manager class in mod/quiz/editlib.php.

=== Where to put the tests ===

The unit test report finds tests by looking for files called 'test....php' inside folders called 'simpletest'.

So, for our example, we want to create called something like '''mod/quiz/simpletest/testeditlib.php'''. The skeleton of this file should look like:

<code php>
<?php
/**
* Unit tests for (some of) mod/quiz/editlib.php.
*
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
* @package question
*/

if (!defined('MOODLE_INTERNAL')) {
die('Direct access to this script is forbidden.'); // It must be included from a Moodle page
}

// Make sure the code being tested is accessible.
require_once($CFG->dirroot . '/mod/quiz/editlib.php'); // Include the code to test

/** This class contains the test cases for the functions in editlib.php. */
class quiz_editlib_test extends UnitTestCase {
function test_something() {
// Do the test here.
}

// ... more test methods.
}
?>
</code>

That is, you have a class called something_test, and in that class you have lots of methods called test_something. Normally, you have one test method for each particular thing you want to test, and you should try to name the function to describe what is being tested - without making the name too ridiculously long!

=== A test function ===

The a test function typically looks like

<code php>
function test_move_question_up() {
// Setup fixture

// Exercise SUT
$newlayout = quiz_move_question_up('1,2,0', 2);

// Validate outcome
$this->assertEqual($newlayout, '2,1,0');

// Teardown fixture

}
</code>

This is the [http://xunitpatterns.com/Four%20Phase%20Test.html four phase test pattern]. Those comments use a lot of testing jargon. The fixture is the background situation that needs to be set up before the test runs. SUT is short for 'situation under test'. This is where you call the function or method that you want to test. Then you check to see if the function did the right thing. Finally, you have to clean up the fixture you created. With luck there is nothing to do here

In this simple example, there is no setup or teardown to do. We just call the function we are testing with some sample input, and check that the return value is what we expect.

=== Shared setUp and tearDown methods ===

If all your test cases relate to the same area of code, then they may all need to same bit of fixture set up. For example, all the tests in lib/simpletest/teststringmanager.php need an instance of the string_manager class to test.

To avoid duplicating code, you can override a method called <code>setUp()</code> that sets up the test data. If present, this method will be called before each test method. You can write a matching <code>tearDown()</code> method if there is any clean-up that needs to be done after each test case has run. For example, in lib/simpletest/teststringmanager.php there are setUp and tearDown methods that do something like:
<code php>
public function setUp() {
// ...
$this->stringmanager = new string_manager(...);
}

public function tearDown() {
$this->stringmanager = null;
}
</code>
Then, each test can use $this->stringmanager without having to worry about the details of how it is set up.

=== Further information ===

The ''SimpleTest'' documentation is at: http://www.simpletest.org/.

== Changes to your existing code to make it work with unit testing ==

The whole point of unit testing is to test each piece of functionality separately. You can only do this is only possible to isolate that function and call it individually, perhaps after setting up a few other things.

Therefore, it is good if you can write your code to depend on as few other things as possible.

=== Include paths ===

Includes like

<code php>
require_once('../../config.php'); // Won't work.
</code>

won't work. Instead, the more robust option is

<code php>
require_once(dirname(__FILE__) . '/../../config.php'); // Do this.
</code>

=== Access to global variables ===

Because your code was included from within a function, you can't access global variables until you have done a global statement.

<code php>
require_once(dirname(__FILE__) . '/../../config.php');
require_once($CFG->libdir . '/moodlelib.php'); // Won't work.
</code>

<code php>
require_once(dirname(__FILE__) . '/../../config.php');

global $CFG; // You need this.
require_once($CFG->libdir . '/moodlelib.php'); // Will work now.
</code>

=== Calls to global functions ===
Testing a class method that calls global functions can be problematic. At least, it's always complex, because we can't control what goes on in the global functions. We can't override the global functions or mock them in our unit tests. If the global functions themselves are well tested, this may not be a big problem, but most global functions are not well tested.

==== Bridge Pattern ====
If your code needs to rely extensively on some public API, you could use the [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] to decouple your code from that API. This way, when you write unit tests, you can override the bridging class or mock it, and control its outputs while you focus exclusively on testing your code.

An basic example follows: Imagine that I do not trust the ''get_string()'' global function, but my code needs to use it. Initially my code has strong coupling with ''get_string()'':

<code php>
class myclass {
public function print_stuff($stuff) {
echo get_string($stuff);
}
}
</code>

Now let's write a bridging class to solve this coupling issue and use it instead of ''get_string()'':

<code php>
class languageBridge {
public function get_string($stuff,$module='moodle') {
echo get_string($stuff, $module);
}
}

class myclass {
public $lang_bridge;
public function __construct() {
$this->lang_bridge = new languageBridge();
}
public function print_stuff($stuff) {
echo $this->lang_bridge->get_string($stuff);
}
}
</code>

The following is yet another example using a bridging method to decouple from the Moodle core API.

<code php>
class workshop_api {
/**
* This is a method we want to unittest
*/
public function get_peer_reviewers($context) {
static $users=null;
if (is_null($users)) {
$users = $this->get_users_by_capability($context, 'mod/workshop:peerassess',
'u.id, u.lastname, u.firstname', 'u.lastname,u.firstname', '', '', '', '', false, false, true);
}
return $users;
}

/**
* Bridging method to decouple from Moodle core API
*/
protected function get_users_by_capability() {
$args = func_get_args();
return call_user_func_array('get_users_by_capability', $args);
}
}
</code>

'''Warning:''' Here are some comments on the examples above expressing that the bridge pattern should be used very carefully.

* "I think that is a case of unit tests leading to worse software design, in that you are not using the standard API for something. But if you really want to unit test, I can't think of a better solution."
* "I think this can be OK if used very selectively. Unfortunately I don't think it's the solution if you want to decouple the very complex and deeply nested Moodle functions from each other"
* "...your code is designed to be part of Moodle, so decoupling from a standard Moodle API is perverse."

== Unit testing in 2.0 ==

{{Moodle 2.0}}
With the Objectification of the Database libraries in Moodle 2.0, new and better approaches to Unit testing can be used. Here is a sample of a simple test case: (in course/simpletest)

<code php>
require_once($CFG->dirroot . '/course/lib.php');

global $DB;
Mock::generate(get_class($DB), 'mockDB');

class courselib_test extends UnitTestCase {
var $realDB;

function setUp() {
global $DB;
$this->realDB = $DB;
$DB = new mockDB();
}

function tearDown() {
global $DB;
$DB = $this->realDB;
}

function testMoveSection() {
global $DB;
$course = new stdClass();
$course->id = 1;

$sections = array();
for ($i = 1; $i < 11; $i++) {
$sections[$i] = new stdClass();
$sections[$i]->id = $i;
$sections[$i]->section = $i - 1;
}

$DB->expectOnce('get_records', array('course_sections', array('course' => $course->id)));
$DB->setReturnValue('get_records', $sections);
$this->assertFalse(move_section($course, 2, 3));
}
}
</code>

See also '''UnitTestCaseUsingDatabase''' in lib/simpletestlib.php.

=== Testing HTML output ===

(work in progress - to be documented properly once the API stabilizes)

* ContainsTagWithAttribute($tag, $attribute, $value)
* ContainsTagWithAttributes($tag, $attributes)
* ContainsTagWithContents($tag, $content)
* ContainsEmptyTag($tag)

The syntax is
<code php>
$this->assert(new ContainsTagWithAttribute($tag, $attribute, $value), $html);
</code>

== Code coverage analysis==
<p class="note">'''Note:''' This section is a work in progress. Please use the [[{{TALKPAGENAME}}|page comments]] or an appropriate [http://moodle.org/course/view.php?id=5 moodle.org forum] for any recommendations/suggestions for improvement.{{{info|}}}</p>

{{Moodle 2.0}}

'''[[Wikipedia:Code_coverage|Code coverage]]''' is a technique, strongly tied with software testing, that allows to '''check and improve the quality of the tests''' by measuring the degree of source code that is being covered by them. With Moodle supporting more and more tests each day (slowly towards a '''Test Driven Development''' model) we need to integrate some tool into our development process helping to analyse the quality of ours tests.

Right now (in Moodle 2.0) we are using [http://www.simpletest.org/ SimpleTest], one simple and great tool to perform all the tests. Unluckily, it doesn't support code coverage analysis at all. In the other hand, other PHP unit testing products like [http://www.phpunit.de/ PHPUnit], more complex and powerful, have built-in support for that technique, but switching to a new product is out from our current [[Roadmap]] plans.

So, after some readings and comparisons, Moodle will implement its own extensions to SimpleTest, in order to fulfil the main goal of having statement/line code coverage analysis working under Moodle 2.0 onwards. To achieve this, also [http://developer.spikesource.com/projects/phpcoverage Spike PHPCoverage], a basic code-coverage tool, will be used and extended. You can find the details of the implementation of this tool at MDL-19579.

=== Changes ===

To enable code coverage in your tests, only a few modifications need to be performed to your current code:

# Change your test classes by adding two (public static) attributes: '''$includecoverage''' and '''$excludecoverage''', both arrays, being used to inform to the code coverage tool (via reflection) about which source code files and dirs must be covered/skipped by the analysis.
# Use '''[http://cvs.moodle.org/moodle/lib/simpletestcoveragelib.php?view=markup simpletestcoveragelib.php]''' instead of simpletestlib.php in your caller scripts.
# Use the '''autogroup_test_coverage''' class instead of the AutoGroupTest one (see below for details) in your caller scripts.

(note that only the 1st point above is needed for new unit tests being created because both 2 and 3 (changes in caller scripts) are already implemented in Moodle and awaiting your cool unit tests.

That's all! With those 3 basic changes, you will end with a complete code coverage report available for further analysis.

=== API ===

When using code coverage within Moodle there are two alternative APIs available, both providing the same code coverage reports at the end, but doing that in a different way. Here they are:

* '''Internal (hidden) coverage API''': This API is completely hidden beyond the Unit testing API and you won't need to know the details about it. Just perform the 1-2-3 changes described above and, after running the tests you'll get the final report available for being used immediately, without needing to perform anything in your code. His major drawback: it only can perform '''one''' "code coverage session" (a.k.a. instrumentation), so it's only suitable for testing scripts using only one unit test execution. One example of this type of unit testing is [http://cvs.moodle.org/moodle/admin/report/unittest/index.php?view=markup admin/report/unittest/index.php] where only one (big) test-group is executed.
* '''External (explicit) coverage API''': This API needs extra coding as long as coverage instantiating, configuration and report generation happens in the main script. It's a bit more complex but, in the other hand, it support '''multiple''' instrumentations to be performed, and gives you more control about the code coverage process. One example of this type of unit testing is [http://cvs.moodle.org/moodle/admin/report/unittest/dbtest.php?view=markup admin/report/unittest/dbtest.php] where multiple (one for each DB being tested) test-group are executed.

So, first of all (point 1 in prev section - usage), we need to define, for each unit test, which files / directories (relative to dirroot) we want to analyse with the tool. Here it's one example, for the '''dml_test''' unit test ([http://cvs.moodle.org/moodle/lib/dml/simpletest/testdml.php?view=markup /lib/dml/simpletest/testdml.php]), all we need to add to these lines to the class declaration :

<code php>
public static $includecoverage = array('lib/dml');
public static $excludecoverage = array('lib/dml/somedir');
</code>

By doing so, the code coverage tool will know which are the target files to perform coverage analysis/reporting and will do that for all the files (recursively) in the ''lib/dml''' dir but excluding the ''lib/dml/somedir'' directory (recursively too). Note that both attributes are arrays so multiple paths can be specified in any of them. Also note that the dir where the UnitTest is stored is automatically excluded (usually ''simpletest'' dirs).

And, as said, that's all you need to fulfil in order to get current/new unit tests being analysed by the code coverage tool by current Moodle scripts. The documentation below is only interesting for developers wanting to create new scripts able to perform unit testing with code coverage (points 2 and 3 in prev section - usage).

==== Internal coverage API ====
<code php>
$test = new autogroup_test_coverage($showsearch, $test_name, $performcoverage, $coveragename, $coveragedir);
</code>
Create one new autogroup test object with code coverage support, there you can specify if you want to perform coverage (true/false), the name of the report (title) and the directory where the final report will be created (under moodledata/codecoverage).
Optionally you can add more files and directories (relative to dirroot) to the list of files to be covered / ignored by using these functions (in case the defined in point 1 aren't enough).
<code php>
$test->add_coverage_include_path($path);
$test->add_coverage_exclude_path($path);
</code>
And then, affter adding a bunch of unit tests to the group, you simply invoke the test execution with code coverage support to end with a nice code coverage report under ''dataroot/codecoverage/$coveragedir'':
<code php>
$test->run($unit_test_reporter);
</code>
(don't forget that this API supports only '''one''' instrumentation to be performed)

And that's all!

==== External coverage API ====
<code php>
$covreporter = new moodle_coverage_reporter($coveragename, $coveragedir);
$covrecorder = new moodle_coverage_recorder($covreporter);
</code>
Create one coverage reporter, by passing its title and output directory as parameters.
<code php>
$test = new autogroup_test_coverage($showsearch, $test_name, $performcoverage);
</code>
Create one new autogroup test object with code coverage support, you don't need to specify the title and dir here (as already have been defined by the moodle_coverage_reporter object).
Optionally you can add more files and directories (relative to dirroot) to the list of files to be covered / ignored by using these functions (in case the defined in point 1 aren't enough).
<code php>
$test->add_coverage_include_path($path);
$test->add_coverage_exclude_path($path);
</code>
Then, after adding a bunch of unit tests to the group, you simply invoke the test execution with code coverage support with:
<code php>
$test->run_with_external_coverage($unit_test_reporter, $covrecorder);
</code>
(don't forget that this API supports '''multiple''' instrumentations to be performed)

And finally, you generate the code coverage report (under ''dataroot/codecoverage/$coveragedir'') using:
<code php>
$covrecorder->generate_report();
</code>
Once more, that's all!

==== Final notes ====
* Note that there are some more methods available in the moodle_coverage_recorder class. They will allow to control starting/stopping instrumentations by hand and other minor things but they shouldn't really be used. The run() and run_with_external_coverage() methods should be enough in 99% of cases.
* Not being part of the API, but used by it, there is one '''[http://cvs.moodle.org/moodle/admin/report/unittest/coveragefile.php?view=markup overagefile.php]''' script under ''admin/report/unittest'' responsible for serving the coverage report files from within Moodle. See current scripts in that dir to see how can be used.
* All the test execution / reporting / coverage utilities must be protected with the 'moodle/site:config' permission.

== A warning ==

In 'xUnit Test Patterns' there is a [http://xunitpatterns.com/TestAutomationRoadmap.html scale of testing difficulty] that goes from 1. to 6. Moodle is definitely at number 6. on that scale 'Non-object-oriented legacy software'. It then goes recommend that you don't start to learn about unit testing with that sort of software :-(

== Further reading about unit testing ==

[http://manning.com/reiersol/ PHP in Action] has an excellent chapter explaining unit testing in PHP with ''simpletest''. (Although the rest of that book advocates a style of programming that is very different from the style used in Moodle.)

[http://www.pragprog.com/titles/utj/pragmatic-unit-testing-in-java-with-junit Pragmatic Unit Testing in Java with JUnit] is also a very good introduction, despite being in the wrong programming language. JUnit and Simpletest are very similar.

[http://xunitpatterns.com/ xUnit Test Patterns] is the ultimate unit test book. I think it teaches you everything you could learn about unit testing by reading a book. The only way to learn more would be years of experience. It has really great advice for dealing with the kind of messy problems you get in a big, real project like Moodle.

{{CategoryDeveloper}}
[[Category:Quality Assurance]]

mod/techproject/view

2009-07-29T02:34:58Z

Markstevens:

{{Moodle 1.7}}{{Moodle 1.8}}

== Main Documentation Page For The "Techproject" Activity Module ==

You may come to this documentation through the automatically generated link at the bottom of some screen of the "techproject" module. This module was developed and is maintained by Valery Fremaux at http://www.ethnoinformatique.fr (Moodle site)

== The Technical Project Manager Module (Overview) ==

This Activity Module is a collaborative constructivist workplace for elaborating in a pedagogic context a project-driven learning activity using the standard IEEE specified "successive refinement". It provides tree-shaped friendly editors (5 actually) allowing writing and constructing the several descriptions that are produced and will document all steps of a project activity. Although its description model is mainly oriented towards "software development" project types, its information structure could be exploited each time a "Requirements" -> "Deliverable" process is consistent.

[[image:techproject_project_paradigm.gif|frame|center]]

The Techproject module is suitable for iterative project cycles, where a work is performed step by step, defining scheduled milestones :

[[image:techproject_project_cyclic_paradigm.gif|frame|center]]

== Some concepts ==

* [[mod/techproject/view/concepts/entitiesandunits|Project Entities and Project Units]]
* [[mod/techproject/view/concepts/treeeditors|Tree-shaped Entity Editor]]
* [[mod/techproject/view/concepts/associations|Cross-entity Associations]]
* [[mod/techproject/view/concepts/propagation|Indicators Propagation]]
* [[mod/techproject/view/concepts/grouping|Groups and project workspaces]]

== Screens of the Technical Project Manager ==

Several screens will allow manipulating the distinct descriptions that will be produced while a technical project is being processed. the whole information set might be collected and layout for outputting e.g. a "printable" document, using any appropriate XSL transform.

=== Screens for editing Entity Units ===

* [[mod/techproject/view/screens/description|The description screen]]
* [[mod/techproject/view/screens/requirements|The requirement screen]]
* [[mod/techproject/view/screens/specifications|The specification screen]]
* [[mod/techproject/view/screens/tasks|The task screen]]
* [[mod/techproject/view/screens/milestones|The milestone screen]]
* [[mod/techproject/view/screens/deliverables|The deliverable screen]]

=== Views ===

Views are screens that allow several displaying and sorting strategies, for project monitoring.

* [[mod/techproject/view/screens/summary|Summary]]
* [[mod/techproject/view/screens/byassignee|By assignee tasklist]]
* [[mod/techproject/view/screens/bypriority|By priority tasklist]]
* [[mod/techproject/view/screens/byworktype|By worktype tasklist]]
* [[mod/techproject/view/screens/detail|Entity Unit Browser]]
* [[mod/techproject/view/screens/gantt|Gantt view]]

=== Teacher's tools ===

* [[mod/techproject/view/screens/assessment|The assessment screen]]
* [[mod/techproject/view/screens/criteria|The criteria edition screen]]
* [[mod/techproject/view/screens/copy|The project copy screen]]
* [[mod/techproject/view/screens/cvsdrive|The CVS pilot]]
* [[mod/techproject/view/screens/importexport|The Import/Export screen]]

== Other information ==

*[[mod/techproject/view/configuration|Instance Settings]]
*[[mod/techproject/view/missingfeatures|What Is Missing ?]]
*[[mod/techproject/view/capabilities|Capabilities (>1.8+)]]

=== Reference, information, development and support ===

valery.fremaux-AT-club-internet.fr
[[Category:Teacher]]
[[fr:mod/techproject/view]]

mod/techproject/view/screens/deliverables

2009-07-29T02:30:57Z

Markstevens:

[[mod/techproject/view|Index]]

[[image:deliverables_overall_ne.gif|center]]

== Deliverables ==

Deliverables are resources that are the physical production of a project. These products may be goods, documents, software in files, contracts, agreements in documents, but qhould have a physical representation that is holdable, transferable, copiable, storable, etc. Within the techproject module, deliverables are descriptions of such resources. Thus it is important to distinguish between "requirements" that describes what "functional effets" the systems produces, and deliverables that represents concrete and physical objects that do produce these effects on some conditions (good use).

Managing deliverables has two major epochs :

A preliminary epoch, known as deliverable plan specification, in which we should design and choose how much and which deliverables should be presented within the complete project. The second epoch, known as "effective production", runs when implementation is done and deliverable map is charged with real productions.

Deliverables, as the majority of project entities (excepting milestones), can be organised in a way. Deliverables that are in leaf position in the tree denotes physical objects to be produced. Higher level nodes in the tree might be used for grouping and packing physical entries oin categories or any kind of organizing principle. As an example, we could use the highest level of deliverable description for splitting a content in :

* Source code package
* Compiled packages
* Technical documentation packs
* Document and user guides
* Marketing and sales support documents
* Tools
* Demos
* Tutorials and examples

Each one of these "packs" or content "categories" could thus be refined in description until reaching a "unity" desription that may be a single file or object.

Usually, deliverable description refinement goals the definition of physical arrangements so that each concerned user may find the system parts he needs in its own situation.

== Viewing Deliverables ==

Deliverables are viewed as a content-collapsed heading tree. Any sublevel can be collapsed if needed.

[[image:techproject_deliverables_heading.gif|center]]

Each heading provides synthesis information, obtained by propagating indicators, or through associated tasks:

* Numbering (autonumbering)
* Caption, that may be changed into an hyperlink if a resource is available for that deliverable
* The number of associated tasks (direct binding/through sub-deliverables)
* The completion level for that deliverable, as a graphical bar-graph

Completion level is propagated from binded tasks.

Each heading can be expanded so a complete qualifier report and a content abstract can be viewed.

== Attaching Resources to Deliverables ==

Deliverables are descriptions that may have resources attached to. These resources may be attached as an external URL, or as an uploaded file within Moodle moodledata repository.

Uploaded resources are stored within shadowed directories (crypted subdirs names) in the course file space, so that file robbery may be avoided. Resources can be freely updated by students (may change in further versions).

A single deliverable entry can be attached ONLY ONE Url OR uploaded resource.

[[fr:mod/techproject/view/screens/deliverables]]

User:Mark Stevens

2009-07-24T03:29:19Z

Markstevens: New page: Moodle advocate since 2004.

Moodle advocate since 2004.

Grade export

2009-07-23T04:52:24Z

Markstevens:

{{Grades}}Grades can be exported to Excel spreadsheet, OpenDocument spreadsheet, plain text file or XML file.

''Grade export is NOT intended for students.''

==How to export grades==
[[Image:Grade export.png|thumb|left|Grade export]]To export grades from the gradebook:
# Choose an export format from the gradebook dropdown menu.
# Set options as required.
# If the course uses groups, select whether to export grades for all participants or for a particular group.
# Select the grade items to be included. Note that ID numbers are required for all activities for XML file export. An ID number field can be found in the common module settings for each activity.
# Click the submit button.
# After previewing the data on the following page, click the download button.

==XML file export==

To export grades to XML file, you need to ensure that:
* Users have ID numbers (an optional field in the user profile)
* Activities have ID numbers (an optional field in the common module settings)

==Default grade export settings==

The grade export display type and grade export decimal points site-wide defaults may be set by an administrator in ''Administration > Grades > [[General grade settings|Grade settings]]''.

==Grade publishing==
[[Image:Grade publishing settings.png|thumb|left|Grade publishing settings]]
Grade publishing is a way of importing and exporting grades via a URL without being logged in to Moodle. Grade publishing is intended for administrators only, due to the security implications.

Grade publishing is disabled by default. It can be enabled by an administrator by checking the gradepublishing box in ''Administration > Grades > [[General grade settings|Grade settings]]''. Users with grade publishing capabilities (normally administrators only) are then provided with grade export publishing settings.

==Tips and tricks==
*Export grades in a spreadsheet format. Then copy and paste that information into another file that has worksheet ("raw grades"). Create other worksheets which are custom reports which take their data from "raw grades". This works if graded activities are '''not''' moved around to different positions in the course. This allows you to create a standard printed report(s). For example a compact landscape report of all students and all grades for each activity, a report of just quizes, another of lessons, another of assignments. A pivot table of students by scores, generated from a report worksheet, which gets its data from the raw data.
*Mailmerge exported grades into custom documents. For example, a document that is given to a department to file as a proof of training, with scores for every subject quiz.

==See also==

*[http://www.youtube.com/watch?v=yZcbN_7p2zI Video showing how to export grades in Moodle 1.9]

[[ca:grade/export/xml/index]]
[[es:Exportar_calificaciones]]
[[fr:Exportation des notes]]

SCORM activity

2009-03-26T03:12:10Z

Markstevens: /* See also */

{{Scorm}}

The '''SCORM/AICC''' module is a course [[Teacher_documentation#Activity_modules|activity]] which allows you (the teacher) to upload any SCORM or AICC package to include in your course.

SCORM (Sharable Content Object Reference Model) is a collection of specifications that enable interoperability, accessibility and reusability of web-based learning content. SCORM content can be delivered to learners via any SCORM-compliant Learning Management System (LMS) using the same version of SCORM.

==What is SCORM==
SCORM was developed as a result of collaboration in the public and private sectors. The President of the United States, Bill Clinton issued an Executive Order that created an agency (ADL) to oversee the standard for developing and distributing online learning. All Federal agencies are mandated to use programs that meet those standards. SCORM is one result of that order.

There's a really simple "What is SCORM" introduction here: http://moodle.org/mod/forum/discuss.php?d=3757#p18828

A slightly more detailed introduction here: http://www.rusticisoftware.com/resources/whatisscorm/What%20Is%20SCORM.htm

==Compatibility with Moodle==
SCORM 1.2 is supported in Moodle 1.9.3 and Moodle 1.8.7 and passes all the tests in the ADL Conformance test suite 1.2..7 for SCORM 1.2.

SCORM 2004 is not completely supported in Moodle at this stage. Parts of the API have been implemented, but others such as Navigation and Sequencing have not yet been implemented.

[[Image:SCORM_activity_homepage_student_19.png|thumb|center|300px|Student view of SCORM activity 1.9]]

==See also==
* [http://moodle.org/mod/data/view.php?id=7198 SCORM Repository] - allows uploading/downloading shared Objects
* The official standard: [http://www.adlnet.gov/scorm/ Advanced Distributed Learning - SCORM]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=3757 Simple introduction to SCORM]
*[http://moodle.org/mod/forum/discuss.php?d=57059 Are there any sugestions for scorm authoring with Microsoft word / or any other easy (maybe free) scorm authoring tool?]
*[http://moodle.org/mod/forum/discuss.php?d=95946 Is SCORM worth it?]

[[Category:Modules]]

[[es:SCORM]]
[[fr:SCORM]]
[[ja:SCORM]]
[[de:Lernpaket (SCORM)]]

Development talk:Site registration

2009-02-18T09:07:32Z

Markstevens: New section: Editing registered sites

Michael, thanks for writing up the guidelines for reviewing new Moodle sites :-) I just came across [[Verification of sites on moodle.org]] and wondered whether the information could be added to [[Development:Site registration]] and then the page deleted. What do you think? --[[User:Helen Foster|Helen Foster]] 06:48, 25 September 2008 (CDT)

Helen, I've updated/merged the instructions that appear on the "check new registrations page" so [[Verification of sites on moodle.org]] can be deleted.

== Editing registered sites ==

Hi All,

As we all know, the registered sites lists contain many duplicate and/or no longer existent sites. It's been suggested that the lists be divided regionally/alphabetically for maintenance. For example, I used to check middle east sites, but the list has grown so much I can barely keep up with one country now. Countries with thousands of sites could be divided alphabetically.

Any takers?

Case for Moodle

2005-12-08T06:13:28Z

Markstevens: /* Scalability */

== High availability ==

''The LMS must be robust enough to serve the diverse needs of thousands of learners, administrators, content builders and instructors simultaneously.''

Moodle and availability - [answer here]

== Scalability ==

''The infrastructure should be able to expand or scale to meet future growth, both in terms of the volume of instruction and the size of the student body.''

Moodle runs on a wide variety of webservers/database technologies. As with any installation of a server-based software system, it is crucial to refine carefully the choice of hardware, operating system, and database system, to ensure that the system can cope with a high throughput. The largest live Moodle installation at time of writing (Open Polytechnic of New Zeland) handles 45,000+ students and 6,500+ courses registered.

The consensus in the Moodle community seems to be that a Linux-based webserver running Apache, with PHP installed as well as a PHP accelerator, is commonly the best choice, and that the webserver and database server should sit on separate machines.

It should be possible to load-balance a Moodle installation, for example by using more than one webserver if necessary. The separate webservers should query the same database and refer to the same filestore area, but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster).

All this implies that Moodle's architecture makes it easy to respond to future demand, by adapting the technologies upon which it runs. This should be possible even in a live setting, to improve the service without major disruption.

== Usability ==

''To support a host of automated and personalized services, such as self-paced and role-specific learning, the access, delivery and presentation of material must be easy-to-use and highly intuitive — like surfing on the Web or shopping on Amazon.com.''

Moodle and usability - [answer here]

== Interoperability ==

''To support content from different sources and multiple vendors' hardware/software solutions, the LMS should exchange data using open industry standards for Web deployments (XML, SOAP or AQ).''

Moodle and interoperability - [answer here]

== Stability ==

''The LMS infrastructure can reliably and effectively manage a large enterprise implementation running 24x7.''

Moodle and stablility - [answer here]

== Security ==

''As with any outward-facing collaborative solution, the LMS can selectively limit and control access to online content, resources and back-end functions, both internally and externally, for its diverse user community.''

Moodle and security - [answer here]

== See also ==

*[http://moodle.org/mod/forum/discuss.php?d=33200 Building the case for Moodle Document] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=35845 Why switch to Moodle when the university already supports BlackCT] forum discussion

[[Category:Moodle]]
[[Category:Administrator]]