MoodleDocs - User contributions [en]

Development:NEWMODULE Documentation

2010-10-24T22:28:40Z

Nenashev: /* lang */ help

{{Template:Work in progress}}
{{New_Module}}
This first draft of Moodle Docs page about the creation of a new module is divided into the some sections. See block NEWMODULE at right side.

=Getting started=

== Base module folder content ==
To download the newmodule package, please refer to:
:* 1.8: http://download.moodle.org/plugins18/mod/NEWMODULE.zip
:* 1.9: http://download.moodle.org/plugins19/mod/NEWMODULE.zip
:* HEAD: http://download.moodle.org/plugins/mod/NEWMODULE.zip

Although you can download the newmodule package for moodle 1.8, such as 1.9 and head, this tutorial is intended for the newmodule development in Moodle 1.9 ONLY.

Let's start by getting an idea about what you find in the newmodule folder taken from http://download.moodle.org/plugins19/mod/NEWMODULE.zip
# db/install.xml
# db/upgrade.php
# icon.gif
# index.php
# lang/en_utf8/help/newmodule/index.html
# lang/en_utf8/help/newmodule/mods.html
# lang/en_utf8/newmodule.php
# lib.php
# mod_form.php
# README.txt
# version.php
# view.php

The path where you find each file is the correct one. So don't change the path of files and folders in this newmodule package.

Inside the db folder, at the beginning, you can only find install.xml and upgrade.php but sooner you will start to always add the new file "access.php".

=== db/install.xml ===
''db/install.xml'' is the file to write the xml describing the tables needed by the module.
Tables are at least two, first named with the same name of the module, second named "log_display".
They follow a strict syntax that you can learn by editing one of the several example you can find inside moodle modules.
Ultimately the only thing to take care is the <<previous>> <<next>> connection between tables and fields.
This is the mandatory file where you MUST write the structure of the tables your module is going to use.
The table "log_display" is the tables where you are requested to list all the "actions" that you will add to the logs of your module.

=== db/upgrade.php ===
''db/upgrade.php'' is the file that you will write each time you need to change the structure of the tables of your module.

To learn how to write this file, please refer to the examples you may find in the file itself.

=== icon.gif ===
It is a 16px per 16px icon identifying each instance of your module in the frame of a course.

=== index.php ===
''index.php'' is a page to list all instances of the functionality the module provides in a course.

=== lang ===
''lang'' is the folder reserved to language packs.

A module language pack is a folder named "xx_utf8" containing, in turn, a folder named "help" and a language file named with the same name of the module. xx is the two char long name of the language, i.e. en, de, es, it, fr and so forth. Each language file is dedicated to a specific language. The lang folder may contain as much language packs as provided by different translators.

The lang/xx_utf8/help/ folder contains all the help files you want to provide to your module. In order to link a help file from inside the code of your module pages use $mform->[[Development:lib/formslib.php_Form_Definition#setHelpButton|setHelpButton]] in [[#mod_form.php|mod_form.php]] and in other places use <code php> helpbutton('<<name of your help file saved in lang/xx_utf8/help/>>', get_string('your_string','newmodule'), 'newmodule');</code>

=== lib.php ===
''[[lib.php]]'' is the pre-filled file with "core" functions needed by each module.

Almost all newmodule functions go here. Each of them must have a name that starts with newmodule_
This file should have two well differenced parts:
* All the core Moodle functions, neeeded to allow the module to work integrated in Moodle.
* All the newmodule specific functions, needed to implement all the module logic.

Please, note that, if the module become complex and this lib grows a lot, it's HIGHLY recommended to move all these module specific functions to a new php file, called "locallib.php" (see forum, quiz...). This will help to save some memory when Moodle is performing actions across all modules.

There are convention to name functions into lib.php and locallib.php. See:
* [[Development:Coding_style#Functions_and_Methods]]
* [[Development:Modules]]

There are some details just above the each function in lib.php.

Mandatory function are, at least:

Module instance editing form handlers, that called from [http://xref.moodle.org/course/mod.php.source.html /course/mod.php] or [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php]:
*'''function newmodule_add_instance($newmodule)'''
This function is after an editing teacher ''create an instance'' of newmodule.

*'''function newmodule_update_instance($newmodule)'''
This function is executed after an editing teacher ''update an instance'' of newmodule

*'''function newmodule_delete_instance($id)'''
This function is executed after an editing teacher ''delete an instance'' of newmodule

*'''function newmodule_user_outline()'''
*'''function newmodule_user_complete($course, $user, $mod, $newmodule)'''

*'''function newmodule_print_recent_activity($course, $isteacher, $timestart)'''

*'''function newmodule_cron()'''
Take care with this function. Differently by all the other functions, this function is not called by passing it the $newmodule record. This means that this function, called by moodle core cron has to look for each newmodule instance id before operating.

Don't worry, even if you have more than a single instance of your module among moodle courses, this function will be executed just one time.

*'''function newmodule_get_participants($newmoduleid)'''
*'''function newmodule_scale_used($newmoduleid, $scaleid)'''
*'''function newmodule_scale_used_anywhere($scaleid)'''

*'''function newmodule_install()'''
*'''function newmodule_uninstall()'''

Some more functions should be added:

*'''function newmodule_reset_course_form_definition(&$mform)'''
*'''function newmodule_reset_course_form_defaults($course)'''
*'''function newmodule_reset_userdata($data)'''
These three functions are responsible for the newmodule reset process during the more general course reset process. Please, refer to [[mod/data/lib.php]] or to [[mod/feedback/lib.php]], for instance, to understand them better.

Two more functions should be added to lib.php are:
*'''function newmodule_get_view_actions()'''
*'''function newmodule_get_post_actions()'''
They distinguish between "read" and "post" log actions. These functions are used by moodle core during log gather.
The actions you list inside these two functions, must match the ones you listed in the table "log_display" in install.xml

==== Connection between '''lib.php''' and '''locallib.php''' ====
One important issue is about the connection between '''lib.php''' and '''locallib.php'''. Who has to call the other, how and why?
It has to be locallib.php to call lib.php through:
<code php>
require_once("$CFG->dirroot/mod/newmodule/lib.php");
</code>
as first line.

In this way, if moodle core calls function inside mod/newmodule/lib.php no module specific function will be loaded in memory.
If it is your newmodule to call a function, it has to require_once('locallib.php'); that, in turn, will require_once('lib.php') so that your module will "see" all its available functions.

=== mod_form.php ===
''mod_form.php'' is the file describing the form you get at the module instance creation or at the instance editing time.

There are only one class definition, that extends class ''moodleform_mod'' from [http://xref.moodle.org/course/moodleform_mod.php.source.html /course/moodleform_mod.php].

The syntax for add new form elements is very simple and by reading the file it is simple to change it on your need. It uses the syntax you can learn in [[Development:lib/formslib.php_Form_Definition]].

This file used only from [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php].

At date, there is a missing detail by the end of the file. You can read:
<code php>
//------------------------------------------------------------------------------
// add standard elements, common to all modules
$this->standard_coursemodule_elements();
//------------------------------------------------------------------------------
</code>
This part with one call of function inherited from moodleform_mod that is responsible for the common modules section at the end of your newmodule editing instance page. The section related to groups, outcomes, grades, visibility etc. This code can be customized by settings object passed to it:
<code php>
//------------------------------------------------------------------------------
// add standard elements, common to all modules
$features = new object();
$features->groups = false;
$features->groupings = false;
$features->groupmembersonly = true;
$this->standard_coursemodule_elements($features);
//------------------------------------------------------------------------------
</code>

One more tip about this file.
* Once you submit the form described by this file, your module executes the function: ''newmodule_add_instance'' or ''newmodule_update_instance'' both pre-written in [[#lib.php|lib.php]].
* It seems that check boxes in the editing instance form don't work. To test this, please verify the passed parameter $newmodule inside your function ''newmodule_update_instance'' through a simple: <code php>print_object($newmodule);</code>
* You will find that even by selecting or unselecting the check box in the newmodule instance editing form, the corresponding value in the array doesn't change. This is not an error, but at least a lack of code. You will find that all works fine by adding at the beginning of both functions a simple code like this:
<code php>
$checkboxes = array('myfirstcheckboxfield', 'mysecondcheckboxfield', and so fort with all your checkbox field);
foreach ($checkboxes as $checkbox) {
if (empty($newmodule->{$checkbox})) {
$newmodule->{$checkbox} = 0;
}
}
</code>

=== README.txt ===
This is the file where you are welcome to write what your newmodule does.

=== version.php ===
''version.php'' is a really very simple file as simple as important.

To understand why it is important, you need to know that there are a bunch of actions that moodle performs for your newmodule ONLY (with only one exception) at the newmodule installation. They are, at least, db tables editing and load of capability. If during the development of your module (that you already installed on your development environment or that you already shared with remote users) you need to change the structure of your newmodule tables or you need to change the capability used by your newmodule, you need to force moodle to edit tables and reload capability.

This is done by:
* adding the proper code in newmodule/db/upgrade.php (to do this, use XMLDB as stated in this same page below)
* increasing the newmodule version in version.php
* visiting the notification page of your installation of Moodle

=== view.php ===
This is the first executed code of your module. By selecting the link of the instance of your module, the code of newmodule/view.php is executed.

== Some very important missing files ==
There are five files that are not present in the newmodule package that 90% of times you will go to add to your newmodule.

1. The first one is locallib.php already described before.

2. The second one is access.php that has to be saved inside newmodule/db/ folder.
:In this file you will add all the capability used by your newmodule and loaded at the installation time or upgrade time. To learn the syntax of the capability, please refer to the same file in other modules or to: https://docs.moodle.org/en/Development:NEWMODULE_Adding_capabilities
3. The third missing file must be added to newmodule/ folder. It is settings.php and describes the form that can be accessed from: Site Administration block -> Modules -> Activities -> <<your newmodule name>>
:This form stores general settings for your newmodule into the site wide $CFG object. Because of this, it is strongly recommended to give to your newmodule general settings with names starting with "newmodule_". This file is useful when there is a setting that doesn't depend from the instance. I.e., if your newmodule simulates a telephone, you will probably save your telephone number in this newmodule setting site wide form instead of typing it each time you add a new instance of your newmodule into a course. In this case, to refer to you telephone number inside your newmodule you will use: $CFG->newmodule_telephonenumber
4. Directly in the newmodule folder, you need to add backuplib.php that is responsible for the backup of each instance of your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.
5. Again in the newmodule folder, you need to add restorelib.php that is responsible for the restore of each instance your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.

==Let's start==
To start using a downloaded package, please perform the 7 actions described in [[Development:NEWMODULE_Tutorial]] in ''How to Begin the Creation of a New Module'' paragraph.

Then, draw the structure of your tables on a sheet, edit the file db/install.xml according to your project, save, put your renamed newmodule folder in moodle/mod/ and visit the moodle notification page.

To add code to db/upgrade.php never do it manually. I always make use of Site Administration block -> Miscellaneous -> XMLDB editor and I ask it to write the code for me. It never fails.

Please remember: within your module, never use "embedded messages" like:
<pre>echo 'Welcome to this newmodule';</pre>
but make use of get_string or print_string. In this way your module will be multilang with a really small effort.
Use, for instance:
<code php>print_string('welcomemessage','newmodule');</code>
saving in newmodule/lang/en_utf8/newmodule.php
<code php>$string['welcomemessage'] = 'Welcome to this newmodule';</code>
==Some code snippets that I find useful==

=== Check the capability of a user ===

<code php>
if (newmodule_hascapabilitytodothis()) {
//user is allowed
} else {
// user is not allowed
}
</code>

typing in locallib.php

<code php>
function newmodule_hascapabilitytodothis($cm) {
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

return (has_capability('mod/newmodule:candothis', $context));
}
</code>

typing in db/access.php
<code php>
$mod_newmodule_capabilities = array(
'mod/newmodule:candothis' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
)
)
</code>

=== Edit the tables in use by your newmodule ===

* edit [[#db/install.xml|db/install.xml]] manually by editing fields and or tables in the xml structure.
* go to Site Administration block -> Miscellaneous -> XMLDB editor and load the tables of your module
* ask to the XMLDB editor the snippets of code you need to add to [[#db/upgrade.php|db/upgrade.php]]
* copy and paste in [[#db/upgrade.php|db/upgrade.php]]
* in the line: <code php>if ($result && $oldversion < xxxxxxxxxxxx)</code> (replace xxxxxxxxxxxx with the version number you are going to give to your newmodule)
* change (increase) the version number
* visit the Moodle notification page

=== Add a single line to logs from your newmodule ===

<code php>
add_to_log($course->id, 'newmodule', '<<action already listed in log_display>>', "view.php?id=$cm->id", "$newmodule->id");
</code>

=== Ensure that remote user will not be able to contact your pages by typing their URL directly in the address bar ===

as first line of each of your php script
<code php>
if (!defined('MOODLE_INTERNAL')) {
die('Direct access to this script is forbidden.'); // It must be included from a Moodle page
}
</code>

==Some suggestion I find useful==
'''To include php scripts''', try:
<pre>require_once('myscript.php');</pre>

'''To include php library''', try:
<pre>require_once('locallib.php');</pre>

'''To periodically execute function newmodule_cron()''', try:
<pre>$module->cron = xxxx;</pre>
providing some code in: <pre>function newmodule_cron()</pre>
Your function newmodule_cron() will be executed about each xxxx seconds

'''Do not include config when it is not needed'''
<pre>require_once('config.php')</pre>
is not needed in library scripts

'''Do not use global $cm or $newmodule in your function'''
but use proper function parameters.

So, never use:
<pre>function newmodule_lookatthesky() {
global $cm, $newmodule;

// your stuff
}</pre>
but use:
<pre>function newmodule_lookatthesky($cm, $newmodule) {

// your stuff
}</pre>

==See also==

* [http://dev.moodle.org/course/view.php?id=2 Moodle Developers' Course]
* [[Development:Modules]]
* [[Development:Places to search for lang strings|Where to put language strings for your plugin]]
* [[Development:Installing and upgrading plugin database tables|Defining the database tables for your plugin]]

{{CategoryDeveloper}}
[[Category:Developer|Modules]]

Development:NEWMODULE Documentation

2010-10-24T20:30:33Z

Nenashev: /* mod_form.php */ a little more

{{Template:Work in progress}}
{{New_Module}}
This first draft of Moodle Docs page about the creation of a new module is divided into the some sections. See block NEWMODULE at right side.

=Getting started=

== Base module folder content ==
To download the newmodule package, please refer to:
:* 1.8: http://download.moodle.org/plugins18/mod/NEWMODULE.zip
:* 1.9: http://download.moodle.org/plugins19/mod/NEWMODULE.zip
:* HEAD: http://download.moodle.org/plugins/mod/NEWMODULE.zip

Although you can download the newmodule package for moodle 1.8, such as 1.9 and head, this tutorial is intended for the newmodule development in Moodle 1.9 ONLY.

Let's start by getting an idea about what you find in the newmodule folder taken from http://download.moodle.org/plugins19/mod/NEWMODULE.zip
# db/install.xml
# db/upgrade.php
# icon.gif
# index.php
# lang/en_utf8/help/newmodule/index.html
# lang/en_utf8/help/newmodule/mods.html
# lang/en_utf8/newmodule.php
# lib.php
# mod_form.php
# README.txt
# version.php
# view.php

The path where you find each file is the correct one. So don't change the path of files and folders in this newmodule package.

Inside the db folder, at the beginning, you can only find install.xml and upgrade.php but sooner you will start to always add the new file "access.php".

=== db/install.xml ===
''db/install.xml'' is the file to write the xml describing the tables needed by the module.
Tables are at least two, first named with the same name of the module, second named "log_display".
They follow a strict syntax that you can learn by editing one of the several example you can find inside moodle modules.
Ultimately the only thing to take care is the <<previous>> <<next>> connection between tables and fields.
This is the mandatory file where you MUST write the structure of the tables your module is going to use.
The table "log_display" is the tables where you are requested to list all the "actions" that you will add to the logs of your module.

=== db/upgrade.php ===
''db/upgrade.php'' is the file that you will write each time you need to change the structure of the tables of your module.

To learn how to write this file, please refer to the examples you may find in the file itself.

=== icon.gif ===
It is a 16px per 16px icon identifying each instance of your module in the frame of a course.

=== index.php ===
''index.php'' is a page to list all instances of the functionality the module provides in a course.

=== lang ===
''lang'' is the folder reserved to language packs. A module language pack is a folder named "xx_utf8" containing, in turn, a folder named "help" and a language file named with the same name of the module. xx is the two char long name of the language, i.e. en, de, es, it, fr and so forth.

Each language file is dedicated to a specific language. The lang folder may contain as much language packs as provided by different translators. The lang/xx_utf8/newmodule/ folder contains all the help files you want to provide to your module. In order to link a help file from inside the code of your module pages try:
<code php> helpbutton('<<name of your help file saved in lang/xx_utf8/newmodule/>>', get_string('your_string','newmodule'), 'newmodule');</code>
:or, in mod_form.php,
<code php>$mform->setHelpButton </code> as stated in

=== lib.php ===
''[[lib.php]]'' is the pre-filled file with "core" functions needed by each module.

Almost all newmodule functions go here. Each of them must have a name that starts with newmodule_
This file should have two well differenced parts:
* All the core Moodle functions, neeeded to allow the module to work integrated in Moodle.
* All the newmodule specific functions, needed to implement all the module logic.

Please, note that, if the module become complex and this lib grows a lot, it's HIGHLY recommended to move all these module specific functions to a new php file, called "locallib.php" (see forum, quiz...). This will help to save some memory when Moodle is performing actions across all modules.

There are convention to name functions into lib.php and locallib.php. See:
* [[Development:Coding_style#Functions_and_Methods]]
* [[Development:Modules]]

There are some details just above the each function in lib.php.

Mandatory function are, at least:

Module instance editing form handlers, that called from [http://xref.moodle.org/course/mod.php.source.html /course/mod.php] or [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php]:
*'''function newmodule_add_instance($newmodule)'''
This function is after an editing teacher ''create an instance'' of newmodule.

*'''function newmodule_update_instance($newmodule)'''
This function is executed after an editing teacher ''update an instance'' of newmodule

*'''function newmodule_delete_instance($id)'''
This function is executed after an editing teacher ''delete an instance'' of newmodule

*'''function newmodule_user_outline()'''
*'''function newmodule_user_complete($course, $user, $mod, $newmodule)'''

*'''function newmodule_print_recent_activity($course, $isteacher, $timestart)'''

*'''function newmodule_cron()'''
Take care with this function. Differently by all the other functions, this function is not called by passing it the $newmodule record. This means that this function, called by moodle core cron has to look for each newmodule instance id before operating.

Don't worry, even if you have more than a single instance of your module among moodle courses, this function will be executed just one time.

*'''function newmodule_get_participants($newmoduleid)'''
*'''function newmodule_scale_used($newmoduleid, $scaleid)'''
*'''function newmodule_scale_used_anywhere($scaleid)'''

*'''function newmodule_install()'''
*'''function newmodule_uninstall()'''

Some more functions should be added:

*'''function newmodule_reset_course_form_definition(&$mform)'''
*'''function newmodule_reset_course_form_defaults($course)'''
*'''function newmodule_reset_userdata($data)'''
These three functions are responsible for the newmodule reset process during the more general course reset process. Please, refer to [[mod/data/lib.php]] or to [[mod/feedback/lib.php]], for instance, to understand them better.

Two more functions should be added to lib.php are:
*'''function newmodule_get_view_actions()'''
*'''function newmodule_get_post_actions()'''
They distinguish between "read" and "post" log actions. These functions are used by moodle core during log gather.
The actions you list inside these two functions, must match the ones you listed in the table "log_display" in install.xml

==== Connection between '''lib.php''' and '''locallib.php''' ====
One important issue is about the connection between '''lib.php''' and '''locallib.php'''. Who has to call the other, how and why?
It has to be locallib.php to call lib.php through:
<code php>
require_once("$CFG->dirroot/mod/newmodule/lib.php");
</code>
as first line.

In this way, if moodle core calls function inside mod/newmodule/lib.php no module specific function will be loaded in memory.
If it is your newmodule to call a function, it has to require_once('locallib.php'); that, in turn, will require_once('lib.php') so that your module will "see" all its available functions.

=== mod_form.php ===
''mod_form.php'' is the file describing the form you get at the module instance creation or at the instance editing time.

There are only one class definition, that extends class ''moodleform_mod'' from [http://xref.moodle.org/course/moodleform_mod.php.source.html /course/moodleform_mod.php].

The syntax for add new form elements is very simple and by reading the file it is simple to change it on your need. It uses the syntax you can learn in [[Development:lib/formslib.php_Form_Definition]].

This file used only from [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php].

At date, there is a missing detail by the end of the file. You can read:
<code php>
//------------------------------------------------------------------------------
// add standard elements, common to all modules
$this->standard_coursemodule_elements();
//------------------------------------------------------------------------------
</code>
This part with one call of function inherited from moodleform_mod that is responsible for the common modules section at the end of your newmodule editing instance page. The section related to groups, outcomes, grades, visibility etc. This code can be customized by settings object passed to it:
<code php>
//------------------------------------------------------------------------------
// add standard elements, common to all modules
$features = new object();
$features->groups = false;
$features->groupings = false;
$features->groupmembersonly = true;
$this->standard_coursemodule_elements($features);
//------------------------------------------------------------------------------
</code>

One more tip about this file.
* Once you submit the form described by this file, your module executes the function: ''newmodule_add_instance'' or ''newmodule_update_instance'' both pre-written in [[#lib.php|lib.php]].
* It seems that check boxes in the editing instance form don't work. To test this, please verify the passed parameter $newmodule inside your function ''newmodule_update_instance'' through a simple: <code php>print_object($newmodule);</code>
* You will find that even by selecting or unselecting the check box in the newmodule instance editing form, the corresponding value in the array doesn't change. This is not an error, but at least a lack of code. You will find that all works fine by adding at the beginning of both functions a simple code like this:
<code php>
$checkboxes = array('myfirstcheckboxfield', 'mysecondcheckboxfield', and so fort with all your checkbox field);
foreach ($checkboxes as $checkbox) {
if (empty($newmodule->{$checkbox})) {
$newmodule->{$checkbox} = 0;
}
}
</code>

=== README.txt ===
This is the file where you are welcome to write what your newmodule does.

=== version.php ===
''version.php'' is a really very simple file as simple as important.

To understand why it is important, you need to know that there are a bunch of actions that moodle performs for your newmodule ONLY (with only one exception) at the newmodule installation. They are, at least, db tables editing and load of capability. If during the development of your module (that you already installed on your development environment or that you already shared with remote users) you need to change the structure of your newmodule tables or you need to change the capability used by your newmodule, you need to force moodle to edit tables and reload capability.

This is done by:
* adding the proper code in newmodule/db/upgrade.php (to do this, use XMLDB as stated in this same page below)
* increasing the newmodule version in version.php
* visiting the notification page of your installation of Moodle

=== view.php ===
This is the first executed code of your module. By selecting the link of the instance of your module, the code of newmodule/view.php is executed.

== Some very important missing files ==
There are five files that are not present in the newmodule package that 90% of times you will go to add to your newmodule.

1. The first one is locallib.php already described before.

2. The second one is access.php that has to be saved inside newmodule/db/ folder.
:In this file you will add all the capability used by your newmodule and loaded at the installation time or upgrade time. To learn the syntax of the capability, please refer to the same file in other modules or to: https://docs.moodle.org/en/Development:NEWMODULE_Adding_capabilities
3. The third missing file must be added to newmodule/ folder. It is settings.php and describes the form that can be accessed from: Site Administration block -> Modules -> Activities -> <<your newmodule name>>
:This form stores general settings for your newmodule into the site wide $CFG object. Because of this, it is strongly recommended to give to your newmodule general settings with names starting with "newmodule_". This file is useful when there is a setting that doesn't depend from the instance. I.e., if your newmodule simulates a telephone, you will probably save your telephone number in this newmodule setting site wide form instead of typing it each time you add a new instance of your newmodule into a course. In this case, to refer to you telephone number inside your newmodule you will use: $CFG->newmodule_telephonenumber
4. Directly in the newmodule folder, you need to add backuplib.php that is responsible for the backup of each instance of your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.
5. Again in the newmodule folder, you need to add restorelib.php that is responsible for the restore of each instance your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.

==Let's start==
To start using a downloaded package, please perform the 7 actions described in [[Development:NEWMODULE_Tutorial]] in ''How to Begin the Creation of a New Module'' paragraph.

Then, draw the structure of your tables on a sheet, edit the file db/install.xml according to your project, save, put your renamed newmodule folder in moodle/mod/ and visit the moodle notification page.

To add code to db/upgrade.php never do it manually. I always make use of Site Administration block -> Miscellaneous -> XMLDB editor and I ask it to write the code for me. It never fails.

Please remember: within your module, never use "embedded messages" like:
<pre>echo 'Welcome to this newmodule';</pre>
but make use of get_string or print_string. In this way your module will be multilang with a really small effort.
Use, for instance:
<code php>print_string('welcomemessage','newmodule');</code>
saving in newmodule/lang/en_utf8/newmodule.php
<code php>$string['welcomemessage'] = 'Welcome to this newmodule';</code>
==Some code snippets that I find useful==

=== Check the capability of a user ===

<code php>
if (newmodule_hascapabilitytodothis()) {
//user is allowed
} else {
// user is not allowed
}
</code>

typing in locallib.php

<code php>
function newmodule_hascapabilitytodothis($cm) {
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

return (has_capability('mod/newmodule:candothis', $context));
}
</code>

typing in db/access.php
<code php>
$mod_newmodule_capabilities = array(
'mod/newmodule:candothis' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
)
)
</code>

=== Edit the tables in use by your newmodule ===

* edit [[#db/install.xml|db/install.xml]] manually by editing fields and or tables in the xml structure.
* go to Site Administration block -> Miscellaneous -> XMLDB editor and load the tables of your module
* ask to the XMLDB editor the snippets of code you need to add to [[#db/upgrade.php|db/upgrade.php]]
* copy and paste in [[#db/upgrade.php|db/upgrade.php]]
* in the line: <code php>if ($result && $oldversion < xxxxxxxxxxxx)</code> (replace xxxxxxxxxxxx with the version number you are going to give to your newmodule)
* change (increase) the version number
* visit the Moodle notification page

=== Add a single line to logs from your newmodule ===

<code php>
add_to_log($course->id, 'newmodule', '<<action already listed in log_display>>', "view.php?id=$cm->id", "$newmodule->id");
</code>

=== Ensure that remote user will not be able to contact your pages by typing their URL directly in the address bar ===

as first line of each of your php script
<code php>
if (!defined('MOODLE_INTERNAL')) {
die('Direct access to this script is forbidden.'); // It must be included from a Moodle page
}
</code>

==Some suggestion I find useful==
'''To include php scripts''', try:
<pre>require_once('myscript.php');</pre>

'''To include php library''', try:
<pre>require_once('locallib.php');</pre>

'''To periodically execute function newmodule_cron()''', try:
<pre>$module->cron = xxxx;</pre>
providing some code in: <pre>function newmodule_cron()</pre>
Your function newmodule_cron() will be executed about each xxxx seconds

'''Do not include config when it is not needed'''
<pre>require_once('config.php')</pre>
is not needed in library scripts

'''Do not use global $cm or $newmodule in your function'''
but use proper function parameters.

So, never use:
<pre>function newmodule_lookatthesky() {
global $cm, $newmodule;

// your stuff
}</pre>
but use:
<pre>function newmodule_lookatthesky($cm, $newmodule) {

// your stuff
}</pre>

==See also==

* [http://dev.moodle.org/course/view.php?id=2 Moodle Developers' Course]
* [[Development:Modules]]
* [[Development:Places to search for lang strings|Where to put language strings for your plugin]]
* [[Development:Installing and upgrading plugin database tables|Defining the database tables for your plugin]]

{{CategoryDeveloper}}
[[Category:Developer|Modules]]

Development:NEWMODULE Documentation

2010-10-24T18:58:16Z

Nenashev: just a little wikification

{{Template:Work in progress}}
{{New_Module}}
This first draft of Moodle Docs page about the creation of a new module is divided into the some sections. See block NEWMODULE at right side.

=Getting started=

== Base module folder content ==
To download the newmodule package, please refer to:
:* 1.8: http://download.moodle.org/plugins18/mod/NEWMODULE.zip
:* 1.9: http://download.moodle.org/plugins19/mod/NEWMODULE.zip
:* HEAD: http://download.moodle.org/plugins/mod/NEWMODULE.zip

Although you can download the newmodule package for moodle 1.8, such as 1.9 and head, this tutorial is intended for the newmodule development in Moodle 1.9 ONLY.

Let's start by getting an idea about what you find in the newmodule folder taken from http://download.moodle.org/plugins19/mod/NEWMODULE.zip
# db/install.xml
# db/upgrade.php
# icon.gif
# index.php
# lang/en_utf8/help/newmodule/index.html
# lang/en_utf8/help/newmodule/mods.html
# lang/en_utf8/newmodule.php
# lib.php
# mod_form.php
# README.txt
# version.php
# view.php

The path where you find each file is the correct one. So don't change the path of files and folders in this newmodule package.

Inside the db folder, at the beginning, you can only find install.xml and upgrade.php but sooner you will start to always add the new file "access.php".

=== db/install.xml ===
''db/install.xml'' is the file to write the xml describing the tables needed by the module.
Tables are at least two, first named with the same name of the module, second named "log_display".
They follow a strict syntax that you can learn by editing one of the several example you can find inside moodle modules.
Ultimately the only thing to take care is the <<previous>> <<next>> connection between tables and fields.
This is the mandatory file where you MUST write the structure of the tables your module is going to use.
The table "log_display" is the tables where you are requested to list all the "actions" that you will add to the logs of your module.

=== db/upgrade.php ===
''db/upgrade.php'' is the file that you will write each time you need to change the structure of the tables of your module.

To learn how to write this file, please refer to the examples you may find in the file itself.

=== icon.gif ===
It is a 16px per 16px icon identifying each instance of your module in the frame of a course.

=== index.php ===
''index.php'' is a page to list all instances of the functionality the module provides in a course.

=== lang ===
''lang'' is the folder reserved to language packs. A module language pack is a folder named "xx_utf8" containing, in turn, a folder named "help" and a language file named with the same name of the module. xx is the two char long name of the language, i.e. en, de, es, it, fr and so forth.

Each language file is dedicated to a specific language. The lang folder may contain as much language packs as provided by different translators. The lang/xx_utf8/newmodule/ folder contains all the help files you want to provide to your module. In order to link a help file from inside the code of your module pages try:
<code php> helpbutton('<<name of your help file saved in lang/xx_utf8/newmodule/>>', get_string('your_string','newmodule'), 'newmodule');</code>
:or, in mod_form.php,
<code php>$mform->setHelpButton </code> as stated in

=== lib.php ===
''[[lib.php]]'' is the pre-filled file with "core" functions needed by each module.

Almost all newmodule functions go here. Each of them must have a name that starts with newmodule_
This file should have two well differenced parts:
* All the core Moodle functions, neeeded to allow the module to work integrated in Moodle.
* All the newmodule specific functions, needed to implement all the module logic.

Please, note that, if the module become complex and this lib grows a lot, it's HIGHLY recommended to move all these module specific functions to a new php file, called "locallib.php" (see forum, quiz...). This will help to save some memory when Moodle is performing actions across all modules.

There are convention to name functions into lib.php and locallib.php. See:
* [[Development:Coding_style#Functions_and_Methods]]
* [[Development:Modules]]

There are some details just above the each function in lib.php.

Mandatory function are, at least:

Module instance editing form handlers, that called from [http://xref.moodle.org/course/mod.php.source.html /course/mod.php] or [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php]:
*'''function newmodule_add_instance($newmodule)'''
This function is after an editing teacher ''create an instance'' of newmodule.

*'''function newmodule_update_instance($newmodule)'''
This function is executed after an editing teacher ''update an instance'' of newmodule

*'''function newmodule_delete_instance($id)'''
This function is executed after an editing teacher ''delete an instance'' of newmodule

*'''function newmodule_user_outline()'''
*'''function newmodule_user_complete($course, $user, $mod, $newmodule)'''

*'''function newmodule_print_recent_activity($course, $isteacher, $timestart)'''

*'''function newmodule_cron()'''
Take care with this function. Differently by all the other functions, this function is not called by passing it the $newmodule record. This means that this function, called by moodle core cron has to look for each newmodule instance id before operating.

Don't worry, even if you have more than a single instance of your module among moodle courses, this function will be executed just one time.

*'''function newmodule_get_participants($newmoduleid)'''
*'''function newmodule_scale_used($newmoduleid, $scaleid)'''
*'''function newmodule_scale_used_anywhere($scaleid)'''

*'''function newmodule_install()'''
*'''function newmodule_uninstall()'''

Some more functions should be added:

*'''function newmodule_reset_course_form_definition(&$mform)'''
*'''function newmodule_reset_course_form_defaults($course)'''
*'''function newmodule_reset_userdata($data)'''
These three functions are responsible for the newmodule reset process during the more general course reset process. Please, refer to [[mod/data/lib.php]] or to [[mod/feedback/lib.php]], for instance, to understand them better.

Two more functions should be added to lib.php are:
*'''function newmodule_get_view_actions()'''
*'''function newmodule_get_post_actions()'''
They distinguish between "read" and "post" log actions. These functions are used by moodle core during log gather.
The actions you list inside these two functions, must match the ones you listed in the table "log_display" in install.xml

==== Connection between '''lib.php''' and '''locallib.php''' ====
One important issue is about the connection between '''lib.php''' and '''locallib.php'''. Who has to call the other, how and why?
It has to be locallib.php to call lib.php through:
<code php>
require_once("$CFG->dirroot/mod/newmodule/lib.php");
</code>
as first line.

In this way, if moodle core calls function inside mod/newmodule/lib.php no module specific function will be loaded in memory.
If it is your newmodule to call a function, it has to require_once('locallib.php'); that, in turn, will require_once('lib.php') so that your module will "see" all its available functions.

=== mod_form.php ===
''mod_form.php'' is the file describing the form you get at the module instance creation or at the instance editing time.
The syntax is very simple and by reading the file it is simple to change it on your need.

It uses the syntax you can learn in https://docs.moodle.org/en/Development:lib/formslib.php_Form_Definition. This file used only from [http://xref.moodle.org/course/modedit.php.source.html /course/modedit.php].

At date, there is a missing detail by the end of the file.
:You can read:
<pre>//------------------------------------------------------------------------------
// add standard elements, common to all modules
$this->standard_coursemodule_elements();
//------------------------------------------------------------------------------</pre>
:This part is responsible for the common modules section at the end of your newmodule editing instance page. (the section related to groups)
:This code can be customized by changing it as described below:
<pre>//------------------------------------------------------------------------------
// add standard elements, common to all modules
$features = new object();
$features->groups = false;
$features->groupings = false;
$features->groupmembersonly = true;
$this->standard_coursemodule_elements($features);
//------------------------------------------------------------------------------</pre>

One more tip about this file.
:Once you submit the form described by this file, your module executes the function: ''newmodule_add_instance'' or ''newmodule_update_instance'' both pre-written in ''lib.php''.
:It seems that check boxes in the editing instance form don't work. To test this, please verify the passed parameter $newmodule inside your function ''newmodule_update_instance'' through a simple: <code php>print_object($newmodule);</code>
:You will find that even by selecting or unselecting the check box in the newmodule instance editing form, the corresponding value in the array doesn't change. This is not an error, but at least a lack of code.
:By adding a simple code like:
<code php>
$checkboxes = array('myfirstcheckboxfield', 'mysecondcheckboxfield', and so fort with all your checkbox field);
foreach ($checkboxes as $checkbox) {
if (empty($newmodule->{$checkbox})) {
$newmodule->{$checkbox} = 0;
}
}
</code>
:at the beginning of both functions, you will find that all works fine.

=== README.txt ===
This is the file where you are welcome to write what your newmodule does.

=== version.php ===
''version.php'' is a really very simple file as simple as important.

To understand why it is important, you need to know that there are a bunch of actions that moodle performs for your newmodule ONLY (with only one exception) at the newmodule installation. They are, at least, db tables editing and load of capability. If during the development of your module (that you already installed on your development environment or that you already shared with remote users) you need to change the structure of your newmodule tables or you need to change the capability used by your newmodule, you need to force moodle to edit tables and reload capability.

This is done by:
* adding the proper code in newmodule/db/upgrade.php (to do this, use XMLDB as stated in this same page below)
* increasing the newmodule version in version.php
* visiting the notification page of your installation of Moodle

=== view.php ===
This is the first executed code of your module. By selecting the link of the instance of your module, the code of newmodule/view.php is executed.

== Some very important missing files ==
There are five files that are not present in the newmodule package that 90% of times you will go to add to your newmodule.

1. The first one is locallib.php already described before.

2. The second one is access.php that has to be saved inside newmodule/db/ folder.
:In this file you will add all the capability used by your newmodule and loaded at the installation time or upgrade time. To learn the syntax of the capability, please refer to the same file in other modules or to: https://docs.moodle.org/en/Development:NEWMODULE_Adding_capabilities
3. The third missing file must be added to newmodule/ folder. It is settings.php and describes the form that can be accessed from: Site Administration block -> Modules -> Activities -> <<your newmodule name>>
:This form stores general settings for your newmodule into the site wide $CFG object. Because of this, it is strongly recommended to give to your newmodule general settings with names starting with "newmodule_". This file is useful when there is a setting that doesn't depend from the instance. I.e., if your newmodule simulates a telephone, you will probably save your telephone number in this newmodule setting site wide form instead of typing it each time you add a new instance of your newmodule into a course. In this case, to refer to you telephone number inside your newmodule you will use: $CFG->newmodule_telephonenumber
4. Directly in the newmodule folder, you need to add backuplib.php that is responsible for the backup of each instance of your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.
5. Again in the newmodule folder, you need to add restorelib.php that is responsible for the restore of each instance your module and of its log.
:To learn how to code it, start by stealing it from some other module and read it.

==Let's start==
To start using a downloaded package, please perform the 7 actions described in [[Development:NEWMODULE_Tutorial]] in ''How to Begin the Creation of a New Module'' paragraph.

Then, draw the structure of your tables on a sheet, edit the file db/install.xml according to your project, save, put your renamed newmodule folder in moodle/mod/ and visit the moodle notification page.

To add code to db/upgrade.php never do it manually. I always make use of Site Administration block -> Miscellaneous -> XMLDB editor and I ask it to write the code for me. It never fails.

Please remember: within your module, never use "embedded messages" like:
<pre>echo 'Welcome to this newmodule';</pre>
but make use of get_string or print_string. In this way your module will be multilang with a really small effort.
Use, for instance:
<code php>print_string('welcomemessage','newmodule');</code>
saving in newmodule/lang/en_utf8/newmodule.php
<code php>$string['welcomemessage'] = 'Welcome to this newmodule';</code>
==Some code snippets that I find useful==

=== Check the capability of a user ===

<code php>
if (newmodule_hascapabilitytodothis()) {
//user is allowed
} else {
// user is not allowed
}
</code>

typing in locallib.php

<code php>
function newmodule_hascapabilitytodothis($cm) {
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

return (has_capability('mod/newmodule:candothis', $context));
}
</code>

typing in db/access.php
<code php>
$mod_newmodule_capabilities = array(
'mod/newmodule:candothis' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
)
)
</code>

=== Edit the tables in use by your newmodule ===

* edit [[#db/install.xml|db/install.xml]] manually by editing fields and or tables in the xml structure.
* go to Site Administration block -> Miscellaneous -> XMLDB editor and load the tables of your module
* ask to the XMLDB editor the snippets of code you need to add to [[#db/upgrade.php|db/upgrade.php]]
* copy and paste in [[#db/upgrade.php|db/upgrade.php]]
* in the line: <code php>if ($result && $oldversion < xxxxxxxxxxxx)</code> (replace xxxxxxxxxxxx with the version number you are going to give to your newmodule)
* change (increase) the version number
* visit the Moodle notification page

=== Add a single line to logs from your newmodule ===

<code php>
add_to_log($course->id, 'newmodule', '<<action already listed in log_display>>', "view.php?id=$cm->id", "$newmodule->id");
</code>

=== Ensure that remote user will not be able to contact your pages by typing their URL directly in the address bar ===

as first line of each of your php script
<code php>
if (!defined('MOODLE_INTERNAL')) {
die('Direct access to this script is forbidden.'); // It must be included from a Moodle page
}
</code>

==Some suggestion I find useful==
'''To include php scripts''', try:
<pre>require_once('myscript.php');</pre>

'''To include php library''', try:
<pre>require_once('locallib.php');</pre>

'''To periodically execute function newmodule_cron()''', try:
<pre>$module->cron = xxxx;</pre>
providing some code in: <pre>function newmodule_cron()</pre>
Your function newmodule_cron() will be executed about each xxxx seconds

'''Do not include config when it is not needed'''
<pre>require_once('config.php')</pre>
is not needed in library scripts

'''Do not use global $cm or $newmodule in your function'''
but use proper function parameters.

So, never use:
<pre>function newmodule_lookatthesky() {
global $cm, $newmodule;

// your stuff
}</pre>
but use:
<pre>function newmodule_lookatthesky($cm, $newmodule) {

// your stuff
}</pre>

==See also==

* [http://dev.moodle.org/course/view.php?id=2 Moodle Developers' Course]
* [[Development:Modules]]
* [[Development:Places to search for lang strings|Where to put language strings for your plugin]]
* [[Development:Installing and upgrading plugin database tables|Defining the database tables for your plugin]]

{{CategoryDeveloper}}
[[Category:Developer|Modules]]

Development:lib/formslib.php Usage

2010-10-22T20:50:54Z

Nenashev: /* Usage of Formslib */ more readable

{{Formslib}}
==Usage of Formslib==

There are many phpdoc style comments in lib/formslib.php

course/edit.php and the included course/edit_form.php provide a good example of usage of this library.

Also see the PEAR docs for [http://pear.php.net/package/HTML_QuickForm/ HTML_QuickForm docs] I found this [http://pear.php.net/manual/en/package.html.html-quickform.tutorial.php quick tutorial] and this [http://www.midnighthax.com/quickform.php slightly longer one] particularly useful.

We created some special wrapper functions for moodle. Function $mform->get_data() returns an object with the contents of the submitted data or returns null if no data has been submitted or validation fails.

===Basic Usage in A Normal Page===

Generally the structure of a page with a form on it looks like this :

<code php>
require_once('pathtoformdescription');
//you'll process some page parameters at the top here and get the info about
//what instance of your module and what course you're in etc. Make sure you
//include hidden variable in your forms which have their defaults set in set_data
//which pass these variables from page to page

$mform = new yourmod_formfunction_form();//name of the form you defined in file above.
//default 'action' for form is strip_querystring(qualified_me())
if ($mform->is_cancelled()){
//you need this section if you have a cancel button on your form
//here you tell php what to do if your user presses cancel
//probably a redirect is called for!
} else if ($fromform=$mform->get_data()){
//this branch is where you process validated data.

} else {
// this branch is executed if the form is submitted but the data doesn't validate and the form should be redisplayed
// or on the first display of the form.
//setup strings for heading
print_header_simple($streditinga, '',
"<a href=\"$CFG->wwwroot/mod/$module->name/index.php?id=$course->id\">$strmodulenameplural</a> ->
$strnav $streditinga", $mform->focus(), "", false);
//notice use of $mform->focus() above which puts the cursor
//in the first form field or the first field with an error.

//call to print_heading_with_help or print_heading? then :

//put data you want to fill out in the form into array $toform here then :

$mform->set_data($toform);
$mform->display();
print_footer($course);

}
</code>

===Defining Your Form Class===

The form class tells us about the structure of the form. You are encouraged to put this in a file called {function}_form.php probably in the same folder in which the page that uses it is located. The name of your class should be {modname}_{function}_form eg. forum_post_form or course_edit_form. These classes will extend class moodleform.

Note the name you give the class is used as the id attribute of your form in html (any trailing '_form' is chopped off'). Your form class name should be unique in order for it to be selectable in CSS by theme designers who may want to tweak the css just for that form.

====definition()====

[[Development:lib/formslib.php_Form_Definition|Help is here for defining your form]] by defining a function definition() in your form class that sets up your form structure.

===Use in Activity Modules Add / Update Forms===

Syntax is the same in activity modules to create your update / add page. We are still supporting mod.html but if you want to use the new formslib then you can in Moodle 1.8 just include in your module directory the file mod_form.php instead of mod.html and it will be automatically detected. Inside this file you define a class with class name '{modname}__mod_form' which extends the class 'moodleform_mod'. See many examples of the core modules which have been converted to use formslib already.

====defaults_preprocessing====

For activity modules you use the same syntax to define your form. You may also want to override method defaults_preprocessing this can be used to take the data from the data base and tell the form how to fill out defaults in the form with this data. For example in the forum module in forum/mod_form.php we needed to tick an enable check box if a date had been selected in the date select. Normally data is loaded from the database and directly loaded into form fields with the same name as the database record you only need to use defaults_preprocessing if there isn't this one to one relationship. Another example is the lesson/mod_form.php which takes the data from the database and unserializes it. choice/mod_form.php shows an exampe of loading data from another db table referred to by a foreign key, to include in the form.

====Post Processing Still Done in lib.php Functions====

Post processing of data is done in lib.php functions modname_add_instance and modname_update_instance after the data has been validated. When migrating a form often little changes need to be made in the post processing. An exception is that date and date_time_selector fields automatically have their submitted data turned into timestamps so you don't need to do this in your add and update functions anymore.

====Automatically Including Standard Activity Module Form Elements====

Standard activity module form elements are automatically included using the moodleform_mod method standard_coursemodule_elements(). The default is to include a visibility and groupsmode select box and to include all necessary hidden fields. You can pass a parameter false to tell the method that your module doesn't support groups and so you don't want the groupsmode select button.

[[Category:Formslib]]

Notes

2010-09-30T21:24:48Z

Nenashev: miscopying

{{Moodle 1.9}}From Moodle 1.9 onwards, teachers may add notes about their students.

The notes page may be accessed via the Notes tab in a user's profile page or the Notes tab on the Participants page.

==Note status==

A note's status determines who can see the note.

* Personal - The note will be visible only to you (as the teacher)
* Course - The note will be visible to other teachers in this course (users with [[Capabilities/moodle/notes:view|notes:view]] capability in this course)
* Site - The note will be visible to other teachers in all courses (users with [[Capabilities/moodle/notes:view|notes:view]] capability in any course)

==Tips and tricks==

* Enable/disable notes: iIn Moodle 1.9.4 onwards, notes may be disabled by unticking the ''enablenotes'' checkbox in ''Administration > Security > [[Site policies]]''.

==See also==
*[http://www.youtube.com/watch?v=cS2tBi-ct5k Moodle 1.9 Notes Tutorial video]

[[Category:Notes]]

[[ca:notes/index|Anotacions]]
[[de:Anmerkungen]]
[[eu:Oharrak]]
[[fr:Annotations]]
[[ja:ノート]]

Notes

2010-09-30T21:23:39Z

Nenashev: is it right?

{{Moodle 1.9}}From Moodle 1.9 onwards, teachers may add notes about their students.

The notes page may be accessed via the Notes tab in a user's profile page or the Notes tab on the Participants page.

==Note status==

A note's status determines who can see the note.

* Personal - The note will be visible only to you (as the teacher)
* Course - The note will be visible to other teachers in this course (users with [[Capabilities/moodle/notes:view|notes:view]] capability in this course)
* Site - The note will be visible to other teachers in all courses (
* Course - The note will be visible to other teachers in this course (users with [[Capabilities/moodle/notes:view|notes:view]] capability in any course)

==Tips and tricks==

* Enable/disable notes: iIn Moodle 1.9.4 onwards, notes may be disabled by unticking the ''enablenotes'' checkbox in ''Administration > Security > [[Site policies]]''.

==See also==
*[http://www.youtube.com/watch?v=cS2tBi-ct5k Moodle 1.9 Notes Tutorial video]

[[Category:Notes]]

[[ca:notes/index|Anotacions]]
[[de:Anmerkungen]]
[[eu:Oharrak]]
[[fr:Annotations]]
[[ja:ノート]]

Calendar

2009-08-18T09:20:19Z

Nenashev: grouping lines about groups and separating lines about activities

{{Calendar}}

The Calendar displays the following events:

* Site (event viewable in all courses - created by admin users)
* Course (event viewable only to course members - created by teachers)
* Groups (event viewable only by members of a group - created by teachers)
* User (personal event a student user can create - viewable only by the user)

Adding closing dates to [[course activities]] — [[assignment]]s, [[forum]]s, [[quizz]]es, etc. will cause them to show up in the [[Calendar block|calendar block]] as course events.

You can view previous or future months on Calendar by clicking the left/right arrows next to the current month's name. The current date is outlined.

Events are added to the calendar, and can be aimed at individual users, your defined groups, or your courses. You can hide or show various categories of events by clicking on the color key below the calendar. This can make the calendar easier to read (especially if there are many events on the calendar). For example, if you wanted to hide Group event dates (events assigned to learner Groups you create), click "Group events" on the bottom of the Calendar. This would hide all group events, and the color code would disappear from the link on the calendar. To show the events again, click the Group Events link again.

Both the daily detail screen and the monthly detail screen have the Preferences button in the upper right. This button leads to a screen like this: The last two settings ('Maximum upcoming events' and 'Upcoming events look-ahead') affect how the Upcoming Events block displays information. You may change any of these settings to suit your class needs. When you have finished any changes, click Save changes.

Both the daily and monthly detail screens have the New Event button. This allows you to manually add events for your classes (remember that the system will automatically add due dates for assignments, quizzes, etc. when you create those activities).

==See also==
*[[Calendar FAQ]]
*[http://www.youtube.com/watch?v=Rwst4lSNniw Video on using the Moodle calendar]
*[[Calendar settings]] for administrators

[[fr:Calendrier]]
[[ca:Calendari]]
[[de:Kalender]]

Complete install packages for Windows

2009-06-19T16:30:34Z

Nenashev: /* Troubleshooting */ eAccelerator

Complete install packages are available from [http://download.moodle.org/ Moodle Downloads], located on a tab for each of the operating systems. The packages are designed for new installations on a server or standalone computer. Please note the standard distributions only contain the Moodle code.

This document provides instructions for using the Windows packages. Separate instructions are available for [[Complete Install Packages for Mac OS X|Mac OS X packages]].

For installation on a Windows 2000 or Windows 2003 server it is good practice to perform a manual install (see the manual installation section in [[Windows_installation|Windows Installation]]).

After installing the Windows package, note that there are other downloads (e.g. additional modules and plugins) that may involve more customization of configuration files.

The complete install packages allow Moodle to be installed, along with the prerequisites that includes a web server, database and scripting language (Apache, MySQL and PHP in this case). Several versions of the complete install package are available. The instructions on the download page provide guidance on which version is likely to be most suitable.

:''Note:'' The latest complete install package version components, may not be backwardly compatible. Always check version compatibility of each component if you intend to develop materials on a later version of Moodle than the version installed on your "main" Moodle site. In short, complete install packages are designed for first time install on a "clean" machine.

==System requirements==
:*256 MB RAM (minimum), 512 MB RAM (recommended)
:*160 MB free Fixed Disk (more space will be needed depending on user uploads)
:*Windows 98/ME (minimum)
:*Windows NT/2000/XP (recommended)

==Install complete package process==
The complete install package is a zip file that contains a webserver called [[Apache]], plus Moodle and Moodle's required [[MySQL]] database and [[PHP]] program.

There are three basic parts to the this install process.
#Download and unpack the complete install package.
#Start the webserver.
#Install Moodle using a web browser.

===First create file structure===
====Download the package====
[http://download.moodle.org/windows Download Windows] packed-zip file from Moodle.
[[Image:Moodle Setup zipfile.jpg|frame|center|A downloaded complete install package Windows 1.9 zip file in Windows Explorer]]

====Unpack the package====
Unpack (extract files by clicking on) the zip file you downloaded to a drive or partition of your choice. The extract process will create three files ("Start Moodle", "Stop Moodle", and "README") and a subfolder called "server".
*Do NOT rename the "server" subfolder
:''Note:'' There will also be a folder under this server subfolder, called \moodle that holds the Moodle program.

:''TIP:'' Create a folder and extract the files there. For example, you might have one folder called Moodle193 and another one called Moodle187 for different versions or purposes.

:''TIP:'' Make path to "server" subfolder simple. Best way if it will be in drive root. Like "D:\moodle193\server". Long path especially with any strange symbols can make XAMPP not working properly.

===Second - start the webserver===
Now you are ready to start the webserver. Use the "Start Moodle.exe" file which you should find in the top directory. Once the "Start Moodle.exe" program is open, don't close it, use "Stop Moodle.exe" for that purpose.

:''Note:'' These programs control both Apache and MySQL programs that operate the webserver. Some sites will individually start and stop Apache and MySQL with the Xampp bat files found in the "server" subfolder.

:''Tip:'' Alternatively, on a stand alone computer with several potential webservers that might be running, you can use the "xampp_restart.exe" file in the "server" subfolder.

:''Tip:'' You can also add shortcuts to the commands that start and stop the site in your Windows "start" menu.

Now you are ready to start the Moodle installation.

:''Warning:'' Windows XP requires the msvcr71.dll library file in order to run Xampp. Installing the [http://www.microsoft.com/downloads/details.aspx?familyid=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en .Net 1.1 framework] (not .Net 2.0 and upper) could resolve it. You can also search for the file on Google, download it and copy it into the server/apache/bin folder.

===Third - start Moodle installation===
Start your web browser and type <nowiki> localhost, or http://127.0.0.1 or http://localhost </nowiki>in the address bar. You will either start your first time Moodle installation or if it is already installed you will enter the Moodle site's [[Front Page]] or Login screen.

:''Tip:'' After Moodle installs, put the site in your "favorites" or as a "bookmark" in you browser.

[[Image:Moodle_Setup_localhost_browser.jpg|frame|center|A browser's addressbar showing "localhost". Click on the green Goto arrow will go to the installed Moodle site.]]

:''Tip:'' After Moodle installs, put the site in your "favorites" or as a "bookmark" in you browser.

====Set language====
The initial install page will be displayed after you type "localhost".

[[Image:C Install Windows 1.png|thumb|center|600px|Set initial language]]

*Choose your preferred language (English is used in this example) and click the “Next” button.

====Diagnostic results====
A diagnostic report is displayed – hopefully it will look like this, if not you may need to address some issues.
[[Image:Complete Windows Install 2.png|thumb|center|546px|Moodle liked and gave a Pass ]]

*Click the “Next” button to continue.
====Moodle paths====
The paths for your Moodle installation are shown – accept the ones that are shown on your screen.

[[image:Complete install Windows 3.png|thumb|center|600px|Installation paths]]

*Click the “Next” button to continue.

====Database configuration====
What you enter in the "Host Server" field depends on what you intend to use the new Moodle installation for.
If you are just going to use it for local testing, then use 'localhost'.
If you are going to test the new installation on a LAN, and will be accessing it from other machines on that LAN, then put the private IP address or network name of the serving machine, followed by a forward slash and moodle: Host Server - 192.168.1.1/moodle
If you are going to test the installation on the internet, then you will need to put the public ip address followed by a forward slash and moodle: your_ip_address/moodle or you can put your domain name here instead.

*In the next fields, we enter the database settings. The fields are populated with some suggested values.

*We strongly recommend you place a user name and password in this screen. (Don't forget them).

*DO NOT USE THE “ROOT” USER WITHOUT A PASSWORD FOR PRODUCTION INSTALLATIONS AS THIS CREATES A SECURITY VULNERABILITY
[[image:Complete install Windows 4.png|thumb|center|535px|Installation's database settings]]

*When the fields have been populated, click the “Next” button to continue.

====Check server====
The install process checks the server it installed.
[[image:Complete install Windows 5.png|thumb|center|535px|Check server environment screen]]
*Click the “Next” button to continue.

====Confirm initial language pack====
Moodle will now check to see if the language pack is available for the language you selected at the first step. If it is not, Moodle will continue with the install in English.
[[image:Complete install Windows 6.png|thumb|center|535px|Language pack check]]

====Confirm config.php====
Provided the Moodle folder is writable, a message confirming the configuration has been completed will be displayed.
[[image:Complete install Windows 7.png|thumb|center|549px|Confirmation that config.php has been created]]

*Click the “ Continue” button to proceed.

====Moodle copyright & agreement====
The Moodle copyright / license notices are displayed.

[[image:Complete install Windows 8.png|thumb|center|400px|Copyright notice and agreement]]

*Click the “Yes” button to continue.

====Current release and unattended option====
The current release information is shown.
'''Check off the unattended operations box'''. This will automatically advance through many screens. If you would like to watch the install screen by screen, do not check this box and be prepared to press the "continute button" many times.

*Click the "Continue" button and wait.
[[Image:Complete install Windows 9.png|thumb|center|600px|Current release and "unattended" check box]]

====Installation modules and blocks screens====
In most cases this will be followed by a series of screens that have a continue button on the bottom. This process stops with Admin user profile settings which needs to be filled out.

====Administrator user profile====
[[Image:Complete install Windows 10.png|thumb|center|The administrator's users profile screen]]

Fill out the required fields.
*Click on "Save" to continue

====Front page settings====
The next screen is the Front Page settings page. There are two parts to it.
The first part will ask for your Full site name and a short name for the navigation bar. There is also a place for a description. You can change these later.

[[Image:Complete install Windows 11a.png|thumb|center|The Moodle sites [[Front Page]] information]]

The second part on the bottom instructs Moodle if you will disable the new user self [[authentication]] through email process. The default is to disable. This can be changed later in the [[Site administration block|site administration block]].

[[Image:Complete install Windows 11ba.png|thumb|center|500px|Determine if users can create their own profiles when they log onto the side via email self authentication]]

*Click on "Save changes" button to go to Moodle sites home page.

====Moodle on====
'''Now you are ready to Moodle !'''

[[Image:Complete install Windows 12.png|thumb|center|Blank Front page of your new site]]

The Site Administration block is on the left, the "Turn edit on" button in the upper right corner, withe the site description block just below it.

===Congratulations - Moodle has been installed===
This finishes the installation of a complete package. Type <nowiki>http://localhost</nowiki> in your browser and Moodle will open.

Your next task will be to configure Moodle to meet your needs. Don't worry, it is easy to change any of the settings now that Moodle is up and running.
*The [[Site administration block]] is where most of the site configuration takes place. The
[[Administrator_documentation]]for links that help configure Moodle. The Administrator documentation page has a [[Administrator_documentation#Configuration|configuration section]].

== Security matters (A MUST READ!)==

As mentioned before, XAMPP is not meant for production use but only for developers
in a development environment. The way XAMPP is configured is to be open as possible
and allowing the developer anything he/she wants. For development environments this
is great but in a production environment it could be fatal. Here a list of missing security
in XAMPP:

The MySQL administrator (root) has no password.
The MySQL daemon is accessible via network.
phpMyAdmin is accessible via network.
Examples are accessible via network.

To fix most of the security weaknesses simply call the following URL:

<nowiki>http://localhost/security/</nowiki>

The root password for MySQL + phpMyAdmin and also a XAMPP directory protection can be established here.

Note that on the Windows installer package, some (all?) of these issues have been fixed already by default and the above link does not work.

If in doubt, more info is [http://www.apachefriends.org/en/faq-xampp-windows.html here]

== Apache and MySQL tweaks ==
Most of the time it is not necessary to tweak Apache or MySQL after completing the complete install package. Nor is it necessary to individually start and stop them because that is what the Xampp_start, Xampp_restart and Xammp_stop files are for.

=== Installing Apache and MySQL as services===
(This is only for NT4 | Windows 2000 | Windows XP operating systems)

\xampplite\apache\apache_installservice.bat =
==> Install Apache 2 as service

\xampplite\apache\apache_uninstallservice.bat =
==> Uninstall Apache 2 as service

\xampplite\mysql\mysql_installservice.bat =
==> Install MySQL as service

\xampplite\mysql\mysql_uninstallservice.bat =
==> Uninstall MySQL as service

==> After all Service (un)installations, please restart your system!

===Apache Notes===

You can use the apache_start and apache_stop bat files to start and stop apache from running. However the Xampp_start or Xampp_restart and Xampp_stop is recommended to turn on/off both Apache and MySQL.

====Troubleshooting====

If you find that Apache is very flaky, with the page often not loading properly or even at all (especially on localhost), try adding these lines to the end of C:\your_moodle_installer_directory\apache\conf\httpd.conf

EnableSendfile Off
EnableMMAP Off
Win32DisableAcceptEx

If You edit some .php files but browser still show old state of them, try to disable eAccelerator extension in \server\php\php.ini

[eAccelerator]
;extension=eaccelerator.dll

===MySQL notes===
Again, the recommendation to start and stop the entire webserver is to use the xampp_start or Xampp_restart and the Xampp_stop. The following maybe useful if you wish to tweak the system further. Please be careful.

(1) The MySQL server can be started by double-clicking (executing) mysql_start.bat. This file can be found in the same folder you installed xampp in, most likely this will be C:\xampplite\. The exact path to this file is X:\xampplite\mysql_start.bat, where "X" indicates the letter of the drive you unpacked xampp into.This batch file starts the MySQL server in console mode. The first intialization might take a few minutes.

Do not close the DOS window or you'll crash the server! To stop the server, please use mysql_shutdown.bat, which is located in the same directory.

(2) To use the MySQL Daemon with "innodb" for better performance,
please edit the "my" (or "my.cnf") file in the /xampplite/mysql/bin directory or for services the c:\my.cnf for windows NT/2000/XP. In that director, activate the
"innodb_data_file_path=ibdata1:30M"
statement. Attention, "innodb" is not recommended for 95/98/ME.

:To use MySQL as Service for NT/2000/XP, simply copy the "my" / "my.cnf" file to C:\my, or C:\my.cnf. Please note that this file has to be placed in C:\ (root), other locations are not permitted. Then execute the "mysql_installservice.bat" in the mysql folder.

(3) MySQL starts with standard values for the user id and the password. The preset user id is "root", the password is "" (= no password). To access MySQL via PHP with the preset values, you'll have to use the following syntax:
mysql_connect("localhost","root","");
If you want to set a password for MySQL access, please use of mysqladmin.
To set the password "secret" for the user "root", type the following:

\xampplite\mysql\bin\mysqladmin -u root password secret

After changing the password you'll have to reconfigure phpMyAdmin to use the new password, otherwise it won't be able to access the databases. To do that, open the file config.inc.php in \xampplite\phpmyadmin\ and edit the following lines:

$cfg['Servers'][$i]['user'] = 'root'; // MySQL user
$cfg['Servers'][$i]['auth_type'] = 'http'; // HTTP authentificate

So first the 'root' password is queried by the MySQL server, before phpMyAdmin may access.

Have a lot of fun! Viel Spaß! Bonne Chance!

==See also==
*[[Site administration block]] where most of the site configuration takes place
*[[Administrator_documentation]]for links that help configure Moodle.
**[[Administrator_documentation#Configuration|Administration configuration section]]
*[[Installation FAQ]]
*[[Installation guide - Moodle for Windows on a USB Memory Stick]]
*Return to [[Windows installation]]
*[[Windows 1 computer many servers |Multiple web servers, on 1 computer]] similar to windows installation page, with some tips
*[https://docs.moodle.org/en/Windows_installation_using_XAMPP#Troubleshooting Troubleshooting]if you are running Skype.
*[[Installing_AMP]] lots of XAMPP stuff. XAMPP stands for X (cross platform), Apache, MySQL,PHP and Perl. XAMPP used in Moodle does not include Perl. MAMP stands for Mac, Apache, MySQL and PHP.
*[[Complete Install Packages for Mac OS X]]

[[es:Paquetes_para_Instalaci%C3%B3n_Completa]]
[[pl:Kompletne pakiety instalacyjne]]
[[de:Vollständiges Installationspaket für Windows]]

[[Category:Administrator]]
[[Category:Installation]]

Complete install packages for Windows

2009-06-19T16:10:24Z

Nenashev: /* Unpack the package */ keep path shorter

Complete install packages are available from [http://download.moodle.org/ Moodle Downloads], located on a tab for each of the operating systems. The packages are designed for new installations on a server or standalone computer. Please note the standard distributions only contain the Moodle code.

This document provides instructions for using the Windows packages. Separate instructions are available for [[Complete Install Packages for Mac OS X|Mac OS X packages]].

For installation on a Windows 2000 or Windows 2003 server it is good practice to perform a manual install (see the manual installation section in [[Windows_installation|Windows Installation]]).

After installing the Windows package, note that there are other downloads (e.g. additional modules and plugins) that may involve more customization of configuration files.

The complete install packages allow Moodle to be installed, along with the prerequisites that includes a web server, database and scripting language (Apache, MySQL and PHP in this case). Several versions of the complete install package are available. The instructions on the download page provide guidance on which version is likely to be most suitable.

:''Note:'' The latest complete install package version components, may not be backwardly compatible. Always check version compatibility of each component if you intend to develop materials on a later version of Moodle than the version installed on your "main" Moodle site. In short, complete install packages are designed for first time install on a "clean" machine.

==System requirements==
:*256 MB RAM (minimum), 512 MB RAM (recommended)
:*160 MB free Fixed Disk (more space will be needed depending on user uploads)
:*Windows 98/ME (minimum)
:*Windows NT/2000/XP (recommended)

==Install complete package process==
The complete install package is a zip file that contains a webserver called [[Apache]], plus Moodle and Moodle's required [[MySQL]] database and [[PHP]] program.

There are three basic parts to the this install process.
#Download and unpack the complete install package.
#Start the webserver.
#Install Moodle using a web browser.

===First create file structure===
====Download the package====
[http://download.moodle.org/windows Download Windows] packed-zip file from Moodle.
[[Image:Moodle Setup zipfile.jpg|frame|center|A downloaded complete install package Windows 1.9 zip file in Windows Explorer]]

====Unpack the package====
Unpack (extract files by clicking on) the zip file you downloaded to a drive or partition of your choice. The extract process will create three files ("Start Moodle", "Stop Moodle", and "README") and a subfolder called "server".
*Do NOT rename the "server" subfolder
:''Note:'' There will also be a folder under this server subfolder, called \moodle that holds the Moodle program.

:''TIP:'' Create a folder and extract the files there. For example, you might have one folder called Moodle193 and another one called Moodle187 for different versions or purposes.

:''TIP:'' Make path to "server" subfolder simple. Best way if it will be in drive root. Like "D:\moodle193\server". Long path especially with any strange symbols can make XAMPP not working properly.

===Second - start the webserver===
Now you are ready to start the webserver. Use the "Start Moodle.exe" file which you should find in the top directory. Once the "Start Moodle.exe" program is open, don't close it, use "Stop Moodle.exe" for that purpose.

:''Note:'' These programs control both Apache and MySQL programs that operate the webserver. Some sites will individually start and stop Apache and MySQL with the Xampp bat files found in the "server" subfolder.

:''Tip:'' Alternatively, on a stand alone computer with several potential webservers that might be running, you can use the "xampp_restart.exe" file in the "server" subfolder.

:''Tip:'' You can also add shortcuts to the commands that start and stop the site in your Windows "start" menu.

Now you are ready to start the Moodle installation.

:''Warning:'' Windows XP requires the msvcr71.dll library file in order to run Xampp. Installing the [http://www.microsoft.com/downloads/details.aspx?familyid=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en .Net 1.1 framework] (not .Net 2.0 and upper) could resolve it. You can also search for the file on Google, download it and copy it into the server/apache/bin folder.

===Third - start Moodle installation===
Start your web browser and type <nowiki> localhost, or http://127.0.0.1 or http://localhost </nowiki>in the address bar. You will either start your first time Moodle installation or if it is already installed you will enter the Moodle site's [[Front Page]] or Login screen.

:''Tip:'' After Moodle installs, put the site in your "favorites" or as a "bookmark" in you browser.

[[Image:Moodle_Setup_localhost_browser.jpg|frame|center|A browser's addressbar showing "localhost". Click on the green Goto arrow will go to the installed Moodle site.]]

:''Tip:'' After Moodle installs, put the site in your "favorites" or as a "bookmark" in you browser.

====Set language====
The initial install page will be displayed after you type "localhost".

[[Image:C Install Windows 1.png|thumb|center|600px|Set initial language]]

*Choose your preferred language (English is used in this example) and click the “Next” button.

====Diagnostic results====
A diagnostic report is displayed – hopefully it will look like this, if not you may need to address some issues.
[[Image:Complete Windows Install 2.png|thumb|center|546px|Moodle liked and gave a Pass ]]

*Click the “Next” button to continue.
====Moodle paths====
The paths for your Moodle installation are shown – accept the ones that are shown on your screen.

[[image:Complete install Windows 3.png|thumb|center|600px|Installation paths]]

*Click the “Next” button to continue.

====Database configuration====
What you enter in the "Host Server" field depends on what you intend to use the new Moodle installation for.
If you are just going to use it for local testing, then use 'localhost'.
If you are going to test the new installation on a LAN, and will be accessing it from other machines on that LAN, then put the private IP address or network name of the serving machine, followed by a forward slash and moodle: Host Server - 192.168.1.1/moodle
If you are going to test the installation on the internet, then you will need to put the public ip address followed by a forward slash and moodle: your_ip_address/moodle or you can put your domain name here instead.

*In the next fields, we enter the database settings. The fields are populated with some suggested values.

*We strongly recommend you place a user name and password in this screen. (Don't forget them).

*DO NOT USE THE “ROOT” USER WITHOUT A PASSWORD FOR PRODUCTION INSTALLATIONS AS THIS CREATES A SECURITY VULNERABILITY
[[image:Complete install Windows 4.png|thumb|center|535px|Installation's database settings]]

*When the fields have been populated, click the “Next” button to continue.

====Check server====
The install process checks the server it installed.
[[image:Complete install Windows 5.png|thumb|center|535px|Check server environment screen]]
*Click the “Next” button to continue.

====Confirm initial language pack====
Moodle will now check to see if the language pack is available for the language you selected at the first step. If it is not, Moodle will continue with the install in English.
[[image:Complete install Windows 6.png|thumb|center|535px|Language pack check]]

====Confirm config.php====
Provided the Moodle folder is writable, a message confirming the configuration has been completed will be displayed.
[[image:Complete install Windows 7.png|thumb|center|549px|Confirmation that config.php has been created]]

*Click the “ Continue” button to proceed.

====Moodle copyright & agreement====
The Moodle copyright / license notices are displayed.

[[image:Complete install Windows 8.png|thumb|center|400px|Copyright notice and agreement]]

*Click the “Yes” button to continue.

====Current release and unattended option====
The current release information is shown.
'''Check off the unattended operations box'''. This will automatically advance through many screens. If you would like to watch the install screen by screen, do not check this box and be prepared to press the "continute button" many times.

*Click the "Continue" button and wait.
[[Image:Complete install Windows 9.png|thumb|center|600px|Current release and "unattended" check box]]

====Installation modules and blocks screens====
In most cases this will be followed by a series of screens that have a continue button on the bottom. This process stops with Admin user profile settings which needs to be filled out.

====Administrator user profile====
[[Image:Complete install Windows 10.png|thumb|center|The administrator's users profile screen]]

Fill out the required fields.
*Click on "Save" to continue

====Front page settings====
The next screen is the Front Page settings page. There are two parts to it.
The first part will ask for your Full site name and a short name for the navigation bar. There is also a place for a description. You can change these later.

[[Image:Complete install Windows 11a.png|thumb|center|The Moodle sites [[Front Page]] information]]

The second part on the bottom instructs Moodle if you will disable the new user self [[authentication]] through email process. The default is to disable. This can be changed later in the [[Site administration block|site administration block]].

[[Image:Complete install Windows 11ba.png|thumb|center|500px|Determine if users can create their own profiles when they log onto the side via email self authentication]]

*Click on "Save changes" button to go to Moodle sites home page.

====Moodle on====
'''Now you are ready to Moodle !'''

[[Image:Complete install Windows 12.png|thumb|center|Blank Front page of your new site]]

The Site Administration block is on the left, the "Turn edit on" button in the upper right corner, withe the site description block just below it.

===Congratulations - Moodle has been installed===
This finishes the installation of a complete package. Type <nowiki>http://localhost</nowiki> in your browser and Moodle will open.

Your next task will be to configure Moodle to meet your needs. Don't worry, it is easy to change any of the settings now that Moodle is up and running.
*The [[Site administration block]] is where most of the site configuration takes place. The
[[Administrator_documentation]]for links that help configure Moodle. The Administrator documentation page has a [[Administrator_documentation#Configuration|configuration section]].

== Security matters (A MUST READ!)==

As mentioned before, XAMPP is not meant for production use but only for developers
in a development environment. The way XAMPP is configured is to be open as possible
and allowing the developer anything he/she wants. For development environments this
is great but in a production environment it could be fatal. Here a list of missing security
in XAMPP:

The MySQL administrator (root) has no password.
The MySQL daemon is accessible via network.
phpMyAdmin is accessible via network.
Examples are accessible via network.

To fix most of the security weaknesses simply call the following URL:

<nowiki>http://localhost/security/</nowiki>

The root password for MySQL + phpMyAdmin and also a XAMPP directory protection can be established here.

Note that on the Windows installer package, some (all?) of these issues have been fixed already by default and the above link does not work.

If in doubt, more info is [http://www.apachefriends.org/en/faq-xampp-windows.html here]

== Apache and MySQL tweaks ==
Most of the time it is not necessary to tweak Apache or MySQL after completing the complete install package. Nor is it necessary to individually start and stop them because that is what the Xampp_start, Xampp_restart and Xammp_stop files are for.

=== Installing Apache and MySQL as services===
(This is only for NT4 | Windows 2000 | Windows XP operating systems)

\xampplite\apache\apache_installservice.bat =
==> Install Apache 2 as service

\xampplite\apache\apache_uninstallservice.bat =
==> Uninstall Apache 2 as service

\xampplite\mysql\mysql_installservice.bat =
==> Install MySQL as service

\xampplite\mysql\mysql_uninstallservice.bat =
==> Uninstall MySQL as service

==> After all Service (un)installations, please restart your system!

===Apache Notes===

You can use the apache_start and apache_stop bat files to start and stop apache from running. However the Xampp_start or Xampp_restart and Xampp_stop is recommended to turn on/off both Apache and MySQL.

===Troubleshooting===

If you find that Apache is very flaky, with the page often not loading properly or even at all (especially on localhost), try adding these lines to the end of C:\your_moodle_installer_directory\apache\conf\httpd.conf

EnableSendfile Off
EnableMMAP Off
Win32DisableAcceptEx

===MySQL notes===
Again, the recommendation to start and stop the entire webserver is to use the xampp_start or Xampp_restart and the Xampp_stop. The following maybe useful if you wish to tweak the system further. Please be careful.

(1) The MySQL server can be started by double-clicking (executing) mysql_start.bat. This file can be found in the same folder you installed xampp in, most likely this will be C:\xampplite\. The exact path to this file is X:\xampplite\mysql_start.bat, where "X" indicates the letter of the drive you unpacked xampp into.This batch file starts the MySQL server in console mode. The first intialization might take a few minutes.

Do not close the DOS window or you'll crash the server! To stop the server, please use mysql_shutdown.bat, which is located in the same directory.

(2) To use the MySQL Daemon with "innodb" for better performance,
please edit the "my" (or "my.cnf") file in the /xampplite/mysql/bin directory or for services the c:\my.cnf for windows NT/2000/XP. In that director, activate the
"innodb_data_file_path=ibdata1:30M"
statement. Attention, "innodb" is not recommended for 95/98/ME.

:To use MySQL as Service for NT/2000/XP, simply copy the "my" / "my.cnf" file to C:\my, or C:\my.cnf. Please note that this file has to be placed in C:\ (root), other locations are not permitted. Then execute the "mysql_installservice.bat" in the mysql folder.

(3) MySQL starts with standard values for the user id and the password. The preset user id is "root", the password is "" (= no password). To access MySQL via PHP with the preset values, you'll have to use the following syntax:
mysql_connect("localhost","root","");
If you want to set a password for MySQL access, please use of mysqladmin.
To set the password "secret" for the user "root", type the following:

\xampplite\mysql\bin\mysqladmin -u root password secret

After changing the password you'll have to reconfigure phpMyAdmin to use the new password, otherwise it won't be able to access the databases. To do that, open the file config.inc.php in \xampplite\phpmyadmin\ and edit the following lines:

$cfg['Servers'][$i]['user'] = 'root'; // MySQL user
$cfg['Servers'][$i]['auth_type'] = 'http'; // HTTP authentificate

So first the 'root' password is queried by the MySQL server, before phpMyAdmin may access.

Have a lot of fun! Viel Spaß! Bonne Chance!

==See also==
*[[Site administration block]] where most of the site configuration takes place
*[[Administrator_documentation]]for links that help configure Moodle.
**[[Administrator_documentation#Configuration|Administration configuration section]]
*[[Installation FAQ]]
*[[Installation guide - Moodle for Windows on a USB Memory Stick]]
*Return to [[Windows installation]]
*[[Windows 1 computer many servers |Multiple web servers, on 1 computer]] similar to windows installation page, with some tips
*[https://docs.moodle.org/en/Windows_installation_using_XAMPP#Troubleshooting Troubleshooting]if you are running Skype.
*[[Installing_AMP]] lots of XAMPP stuff. XAMPP stands for X (cross platform), Apache, MySQL,PHP and Perl. XAMPP used in Moodle does not include Perl. MAMP stands for Mac, Apache, MySQL and PHP.
*[[Complete Install Packages for Mac OS X]]

[[es:Paquetes_para_Instalaci%C3%B3n_Completa]]
[[pl:Kompletne pakiety instalacyjne]]
[[de:Vollständiges Installationspaket für Windows]]

[[Category:Administrator]]
[[Category:Installation]]

WebDAV Setup

2009-03-01T12:11:43Z

Nenashev: Using Moodle: WebDAV extension for Moodle

WebDAV access allows users which can edit course files to do so from a convenient WebDAV "Web Folder"/Mountpoint which acts like a local drive.

To set up WebDAV access in your Moodle installation:

* In Admin->Server->WebDAV Set webdavenable to Yes.
* The 'moodle/site:webdav' capability controls who can connect - by defauly the "Course Creator" role has it. Assign the role at the system level for users to be able to connect.
* If you want to restrict WebDAVaccess so it is only accessible from the local LAN, use the webdavsubnet setting.

(This feature will be available after v1.9)

To use WebDAV your webserver must support this. There a 2 steps needed:
* Installing the DAV module in your webserver
In a commonly used server, apache, the module is called mod_dav. Using the Debian OS, "aptitude install libapache-mod-dav" does the trick.
* Disabling magic_quotes_gpc
When this module is installed, create an entry in your apache config file (under the <VirtualHost> entry for the applicable domain) like this: "php_value magic_quotes_gpc 0" to disable magic_quotes_gpc and your serevr should be setup correctly.

== See Also ==
* [[WebDAV Connect]]
* [http://moodle.org/mod/forum/discuss.php?d=41217 Using Moodle: WebDAV extension for Moodle] discussion from 2006

[[Category: Administrator]]

Guest role

2009-02-28T22:43:38Z

Nenashev: +/* Skip login page by URL */

==Guest access==

Moodle has a built-in "Guest account". Visitors can log in as guests using the "Login as a guest" button on the login screen and enter any courses which allow guest access. In addition, logged-in users can enter any courses which allow guest access without being required to enrol.

Guests ALWAYS have "read-only" access - meaning they can't leave any posts or otherwise mess up the course for real students.

They ''cannot'':

* Post in [[Forum module|forums]]
* Edit [[Wiki module|wiki]] pages
* Participate in a [[Chat module|chat]]
* Take [[Quiz|quizzes]]
* Submit [[Assignment|assignments]]
* Contribute [[Glossary|glossary]] entries or comments
* View [[SCORM]] content (because progress not tracked for a guest)
* Receive any scores or grades (because of the read-only access)

This feature can be handy when you want to let a colleague in to look around at your work, or to let students see a course before they have decided to enrol.

Note that you have a choice between two types of guest access: with an [[Enrolment key|enrolment key]] or without. If you choose to allow guests who have the key, then the guest will need to provide the current enrolment key EVERY TIME they log in (unlike students who only need to do it once). This lets you restrict which guests can get into a course. If you choose to allow guests to enter without a key, then anyone can get into your course.

If you want guests to be able to take quizzes, or any of the other activities listed above, and have considered the security implications, you can create a visitor account, say with username = password = visitor, for everyone to share.

==Enabling guest access==

To enable guest access to a Moodle site, the guest login button should be set to "show" by an admin in ''Administration > Users > [[Authentication]]''.

Teachers can then set whether their courses allow guest access in the [[Course settings|course settings]].

To allow visitors to be logged in as guests automatically when entering courses with guest access, the ''autologinguests'' box should be checked by an admin in ''Administration > Users > Permissions > [[User policies]]''.

==Disabling guest access==

Guest access for visitors can be disabled by hiding the guest login button in ''Administration > Users > [[Authentication]]''. If any courses allow guest access, then only logged-in users will be able to enter them.

==Self-enrolment==

Sometimes you may wish to allow people to have a more interactive engagement with a course without you having to enrol them in advance. In this case you can enable "self-enrolment" for your course. This allows anyone with a user account on your Moodle server to become a student on your course. As with guest access, you can use the [[enrolment key]] to limit this only to people to whom you have given the key.

==Skip login page by URL==

When you want get URL for external peoples to view You moodle pages witch allowed guest access, you can add to one simple URL parameter ''username=guest'' to skip login page and automatically login this users as Guests.

For example, this URL will be ask user to login before display Welcome page of the "Using Moodle" cource:
* http://moodle.org/mod/resource/view.php?id=1361
But this URL make visitor logged in as Guest and display required page immediately:
* [http://moodle.org/mod/resource/view.php?id=1361&username=guest http://moodle.org/mod/resource/view.php?id=1361'''&username=guest''']
Note: if user try to go to login directly from page, opened by this URL, he can't do it because login page will be return him to that URL back and relogin to Guest again. It can be frustrating, and because this, use this method only in links for really external visitors. 

==See also==

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=56914 Change in self-enrolment procedure and status of course visitors]
*[http://moodle.org/mod/forum/discuss.php?d=69674 Allowing guests to post in forum?]

[[Category:Roles]]

[[fr:Accès invité]]
[[ja:ゲストアクセス]]
[[de:Gast-Rolle]]

Development:Developer documentation

2007-11-27T10:20:23Z

Nenashev: /* Documentation for core components */ phpXRef MUST be described some where here

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>. If you are a developer, you probably want to change your [[Special:Preferences|preferences]] to include the Development namespace in searches. A page may be added to the Developer category by typing <code><nowiki>[[Category:Developer|New page name]]</nowiki></code> at the bottom of the page.

==How Moodle development works==

This [[Development:Overview|overview of the Moodle development process]] may be handy in understanding how the development of Moodle occurs and how people become Moodle developers.

==Guidelines==

The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Development:Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle design goals]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc
*[[Development:Working with the Community|Working with the Community]] explains how to engage with the dev community and discuss changes
*[[Unit tests]] explains how to run the unit tests, and how to write new test cases.

==Documentation for core components==

This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].

The documents below give a general overview. For detailed function-by-function documentation, see the [http://phpdocs.moodle.org/ phpDocumentor] documentation that is automatically generated from the comments in the code. And don't forget that the most up-to-date and detailed description of how the code works is the code itself. Moodle code should be easy to read and understand. Use the source, Luke!

Also You can use [http://xref.moodle.org/nav.html?index.html phpXRef] site, that provide interactive source browsing engine around all moodle sources.

===Core components that affect everything===

*[[Development:Database schema introduction|The database schema]]
*lib/moodlelib.php
*[[Development:lib/weblib.php|lib/weblib.php]] for outputting stuff.
*[[Development:XMLDB_Documentation|Database abstraction layer]] @ v[[1.7]]
*[[Development:Roles|Roles and Capabilities system]] @ v[[1.7]] for controlling who can do what.
*[[Development:lib/formslib.php|Forms library]] @ v[[1.8]] for creating accessible and secure HTML forms that let users edit things.

===Core libraries with a more specific uses===

*[[Authentication API]]
*[[Cookieless Sessions]]
*[[Development:Moodle Network|Moodle Network]]
*[[Email processing]]
*[[Development:Environment checking|Environment checking]] before install, check the user's server to ensure Moodle will work there.
*[[Question engine]]
*[[Stats package]]
*[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]
*[http://developer.yahoo.com/yui YUI JavaScript library] - YUI was selected as the official AJAX library for Moodle.
*[[Development:lib/graphlib|lib/graphlib]]

===Modules included in the standard distribution===

*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]

==How you can contribute==

===Make a new plugin===

The M in Moodle stands for modular, and the easiest, most maintainable way to add new functionality to Moodle is by using one of the many plugin APIs. There are many types of plugin you can write:
*[[Development:Modules|Activity modules]]
*[[Development:Admin reports|Admin reports]]
*[[Development:Assignment types|Assignment types]]
*[[Development:Authentication plugins|Authentication plugins]]
*[[Development:Blocks|Blocks]]
*[[Course formats]]
*[[Development:Course Report Plugins|Course reports]]
*[[Development:Database fields|Database fields]]
*[[Development:Database presets|Database presets]]
*[[Development:Enrolment plugins|Enrolment plugins]]
*[[Development:Filters|Filters]]
*[[Development:Grade export/import|Grade export/import]]
*[[Development:Grade report|Grade report]]
*[[Development:Question engine|Question engine]]
*[[Development:Question import/export formats|Question import/export formats]]
*[[Quiz reports]]
*[[Development:Resource types|Resource types]]
*[[Development:SSO plugins|SSO plugins]]
*[[Development:Search engine adapters|Search engine adapters]]
*[[Development:Course Report Plugins|Course Report Plugins]]

When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 Moodle modules and plugins database].

===Change core code===

Some types of change can only be made by editing the core Moodle code. Such changes are much harder to maintain than plugins. If you want your core change to be considered for inclusion in the official Moodle release, you need to create an issue in the [[Tracker|tracker]], and attach your change as a [[Development:How_to_create_a_patch|patch]]. It is also a good idea to discuss your ideas in the forums first.

===Ways to contribute that do not involve PHP programming===

*[[Themes|Create Moodle themes]]
*[[Translation|Translate Moodle into other languages]]
*[[MoodleDocs:Guidelines for contributors|Help document Moodle]]
*[[Development:Database schemas|Database schemas]]
*[[Development:Tests|Join the testing effort]], which involves [[Tracker|participating in the bug tracker]]

==Plans for the future==

Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystallize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.

*[[Roadmap]]
*[[Development:Developer notes|Developer notes]]
*[[Student projects]]
*[[Developer conferences]]

== Resources and tools ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[[Development:Finding_your_way_into_the_Moodle_code|Finding your way into the Moodle code]] - also aimed at newcomers
*[http://tracker.moodle.org/ Moodle tracker] - bug reports, feature requests and other tracked issues
**[[Firefox tracker search]] - How to setup a firefox quicksearch to easily navigate to moodle bugs
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD
*Browse the code online:
**[http://moodle.cvs.sourceforge.net/moodle/moodle/ the code with a complete change history from CVS]
**[http://xref.moodle.org/index.html the code, with links generated by PHPXref]
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - compiled from the comment attached to each class and function in the code
*[[Development:Database Schema|Database Schema]] - for recent releases
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
**especially the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]
**[[Filters used on the Moodle.org forums|cool tricks you can use in the moodle.org forums]]
*Some tools people use when working on Moodle code:
**[[Development:Setting_up_Eclipse|Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
**[[Development:vim|Setting up Vim for Moodle development]]
**[[Development:ctags|Ctags]] - Using a tags file to navigate code

==See also==

*[http://security.moodle.org/ Moodle Security Centre]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

[[Category:Developer]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[zh:开发者文档]]
[[ja:開発者ドキュメント]]

Roles FAQ

2007-07-16T10:28:28Z

Nenashev: /* How do I change the name for "teacher" in the course description? */ about dummy roles

{{Roles}}

==What is the definition of a...==

;Role
:An identifier of the user's status in some context, for example Teacher, Student and Forum moderator
;Capability
:A description of a particular Moodle feature, for example [[Capabilities/moodle/blog:create|moodle/blog:create]]
;Permission
:A setting for a capability - inherit, allow, prevent or prohibit
;Context
:A "space" in Moodle, such as courses, activity modules or blocks

==Why isn't my role change taking effect?==

Role changes only take effect after the next login from that user. Regarding testing new roles, please refer to the information in [[Manage roles]].

Also, please check the context in which the role is assigned. Certain capabilities e.g. [[Capabilities/moodle/user:update|moodle/user:update]] may only be applied in the system context, so assigning a role in the course context will result in the role change not taking effect.

==Why are participants being added automatically when a new course is created?==

If a user is assigned a global role or a role in the course category context then the user has this role in ALL courses in that context. Thus users who are students or teachers at the category level appear as course participants in all courses in that category.

Please check ''Administration > Users > Permissions > Assign global roles'' and also the Assign roles link in course categories page and unassign users as necessary.

==Why are all students enrolled in all courses?==

Either
*Users are assigned the role of student in the site/system context rather than the course context (see FAQ above)
Or
*The default role for all users in ''Administration > Users > Permissions > User policies'' is set to Student rather than Authenticated user (Moodle 1.8 onwards).

==Why are there differences in the users listed as course participants and users assigned roles in a course?==

Users assigned roles in a higher context, for example users assigned the role of teacher in a course category context, may appear as course participants. The discussion [http://moodle.org/mod/forum/discuss.php?d=59900 Discrepancies between Assign Roles lists and Participants list] contains a longer explanation.

==How can I prevent administrators being listed as course participants?==

Ensure that administrators are not assigned another role in addition to their admin role.

==Why are hidden assignments still visible?==

Hidden assignments are not hidden from admins or teachers i.e. users with the [[Capabilities/moodle/role:viewhiddenassigns|viewhiddenassigns capability]].

==Where are permissions inherited from?==

Permissions are inherited from a role assigned in a higher-level context which has permissions set to allow for particular capabilities. If permission is never allowed/not set in any context (in particular, if you are creating or editing a role at the site level), then a user will have no permission for that capability.

For example, the Student role has permission not set for the change site configuration capability. The permission is never allowed in any context so users assigned the role of Student cannot change the site configuration.

==What is a hierarchy of permissions?==

This determines which permission wins or is going to be in effect if there is an apparent conflict. For example, the site allows all students the permission to to post in forums, but a teacher might prevent that right in a particular course. The hierarchy of permissions would allow a student to post in one course but not in another course.

==Are there any differences in Roles in Moodle 1.7 and 1.8?==

In addition to many Roles fixes and refinements (see the list of [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10221 Roles improvements] in the Tracker), in Moodle 1.8 the ''system'' context is separated from the ''site'' context.

The site context in Moodle 1.8 is the "front page course" and its activities. Roles may be assigned in the site context via ''Administration > Front Page > Front Page roles''.

A "Duplicate role" button has been added in Moodle 1.8, which makes creating new roles based on predefined roles much quicker.

==How do I change the name for "teacher" in the course description?==

Either
* Edit the role of Teacher via ''Administration > Users > Permissions > Define roles'' and rename it. The new name will apply site-wide.
Or
* Create a duplicate teacher role with an alternative name and assign users the duplicate teacher role as appropriate in the course context. In ''Administration > Appearance > Course manager'' select the alternative name for teacher that you wish to be displayed in the course description.
Or
* One more way to do it in 1.8 is to create new "dummy" roles (no capabilities) with those names and assign them to teachers along with the real roles. In the course manager settings you can choose which roles display on the front page under each course. (The feature request [http://tracker.moodle.org/browse/MDL-9182 Ability to assign or display custom title for role of person in course] contains a this further method.)

{{Moodle 1.9}}From Moodle 1.9 onwards, names for different roles in a course may be changed in the [[Course settings|course settings]].

==How do I allow teachers to assign other teachers in a course==

This is disabled by default but it can be switched on by modifying the teacher's role. At ''Administration > Users > Permissions > Define roles'' select the "Allow role assignments" tab and tick the checkbox where Teacher and Teacher intersect.

==Why doesn't "Switch role to.." within a course seem to work properly for a Course Creator?==

This feature is intended for Teachers assigned at the course level. Users assigned at "higher" contexts should not expect reliable results from this function.

[[Category:Roles]]
[[Category:FAQ]]

[[es:FAQ_roles]]
[[fr:FAQ des rôles]]
[[ja:ロールFAQ]]

Filters

2007-03-31T21:55:03Z

Nenashev: class for multilang

'''Filters''' allow for the automatic transformation of entered text into different, often more complex forms. For example the titles of [[Resources|resources]] can automatically become hyperlinks that take you to the relevant resource, URLs pointing to [[mp3]] files can become [[Flash]] controls embedded in the webpage that let you pause and rewind the audio. The possibilities are endless and there are a number of standard filters included with Moodle and many more specialized filters contributed by the community.

Filters are one of Moodle's pluggable resources and may be added or removed simply by using a file manager to add or remove them from the /filters directory. Moodle detects those that are present and makes them available to use.

In versions prior to 1.7, the filters manager and individual filter settings may be found in the site administration block >> [[Configuration]] >> Filters. In 1.7 it can be found in the administration block >> Modules >> Filters.

[[Image:Filters_configuration_table.JPG|thumb|300px|left|Moodle 1.6 Filters administration]]
Prior to Moodle 1.6 the filters administration screen has two columns - '''active''' and '''inactive'''. The arrows are used to move filters from one column to the other. Only filters in the active column will be applied. Note that up and down arrows are provided to the left of the '''active''' column to enable the order in which filters are applied to be changed. In some cases this can be significant.
{{Moodle 1.6}}
Moodle 1.6 has a more unified administration screen (similar to the modules and blocks administration screens).

The filters administration screen enables individual filters to be shown (enabled) or hidden (disabled). Only enabled filters will be applied to displayed text. The order in which filters are applied to displayed text can be significant - you can change the order in which enabled filters are applied using the up and down buttons. The enabled filters are applied from the top of the list down. Some filters have their own settings screen. Please refer to the documentation for the individual filter for more information.

Underneath the filter selection area, there are fields which control the cache.
 

==Filters==

*Activity Names Auto-linking - This scans text for activity titles that exist in the same course and creates a link.
*[[Algebra filter|Algebra]] - This filter will convert algebra code into GIF images. It requires the tex filter to be installed ([[#TeX notation|see below]]). Note also that your system must also include the following Perl module: HTML::Entities.pm
*Database auto-linking - As the name suggests, this filter enables automatic linking of [[Database module]] entries.
*Email Protection - This filter scans the text for any email addresses. Where found they are changed to reduce the chance of being added to a spammers list.
*Glossary auto-linking - As the name suggests, this filter enables automatic linking of [[Glossary module]] entries. In addition to this filter, individual glossary entries should have the "This entry should be automatically linked" box checked.
*[[Multi language content]] - This filter enables resources to be created in multiple languages. It looks for <span lang="xx" class="multilang">... tags which indicate that a text contains multiple languages. Then it selects and outputs the best language for the current user. The language of the resource will change when the user changes their selected Moodle language. Please note: going to the past, the multilang filter supported the <lang> tag. Then, officially, we changed it to the standard HTML tag and the <lang> solution is now deprecated.
*[[Multimedia plugins]]
*Resource Names Auto-linking - The titles of [[Resources]] can automatically become hyperlinks that take you to the relevant resource within the same course.
*[[TeX filter|TeX notation]]
*Tidy - This filter checks whether HTML code is XHTML compliant, tidying where necessary. To make this filter work you need to have PHP compiled with the libtidy option; see http://www.php.net/tidy. The Using Moodle discussion [http://moodle.org/mod/forum/discuss.php?d=28418 Tidy Filter for Moodle 1.5] contains more details.
*Wiki Page Auto-linking
*[[Word censorship]] - This filter "blacks out" words found on a list.

==Cache Controls==
{{Moodle 1.6}}
*Text cache lifetime - To reduce load on the server and to speed display of pages, Moodle can store previously processed pages (that have not changed) for a period of time. This setting controls the time for which processed pages are stored. A longer setting may improve performance but has the effect that changes to pages may not become visible for a time. You can switch caching off completely here.
*Filter uploaded files - This setting enables uploaded files (HTML and text only) to be processed by the filters system. You can choose to have none, only HTML or all files filtered.
*Filter match once per page - This setting effects the glossary, activity and resource linking filters. If set to yes, only the first match on the complete page will be converted to a link. All others will be ignored.
*Filter match once per text - This setting effects the glossary, activity and resource linking filters. If set to yes, only the first match in a discrete block of text will be converted to a link. All others in that text block will be ignored.
*Filter all strings - When set to yes, almost all Moodle text will be filtered. This is probably only necessary when using the multi-language filter.

==Config.php settings==
{{Moodle 1.5}}
*For Moodle 1.6 see the Cache Settings above. For earlier versions of Moodle, the filter/config.php file will need to be changed for the visual effects below. The following two settings affect the glossary, activity and resource linking filters:
:To convert only the first matching title on a page, insert or uncomment the following line in config.php: <code>$CFG->filtermatchoneperpage = true;</code>
:To convert only the first matching title in a discrete block of text, insert or uncomment the following line in config.php: <code>$CFG->filtermatchonepertext = true;</code>

==See also==

*[[Development:Filters]]
Non-standard filters:

* [[Jmol filter|Jmol]] - for interactive 3D viewing of molecular structures
* [[Code Syntax Highlighting]] - for more readable excerpts of programming languages including [[PHP]], [[HTML]], [[CSS]], and XML amongst many others

[[Category:Administrator]]
[[Category:Filter]]

[[es:Filtros (Administrador)]]
[[fr:Filtres (administrateur)]]

filter/multilang/config

2007-03-31T21:51:23Z

Nenashev:

#redirect [[Multi language content]]

Development:Roles and modules

2007-01-17T08:42:12Z

Nenashev: link to Roles and Capabilities forum instead of General Developer's one

This is a page for '''developers''' that describes how to make Moodle modules work under 1.7 roles system. =) For more background information, please read [[Development:Roles]]. For any clarifications please post to the [http://moodle.org/mod/forum/view.php?f=941 Roles and Capabilities forum].

==Introduction==

Moodle 1.6 and below uses 7 default roles, namely primary admin, admin, editing teachers, non-editing teachers, students and guests. The set of capabilities that users associated to these roles can perform is fixed. To check permissions, we normally use isteacheredit($courseid), isguest() etc.

{{Moodle 1.7}}
Under the new 1.7 system, roles do not have a fixed set of capabilities anymore. We use a different function called has_capability() to check for specific capabilities, more on this later.

==Context==

Context is an important concept to make roles work. There are currently 8 levels

define('CONTEXT_SYSTEM', 10);
define('CONTEXT_PERSONAL', 20);
define('CONTEXT_USERID', 30);
define('CONTEXT_COURSECAT', 40);
define('CONTEXT_COURSE', 50);
define('CONTEXT_GROUP', 60);
define('CONTEXT_MODULE', 70);
define('CONTEXT_BLOCK', 80);

They are stored as a tuple [contextlevel][instanceid]. For example course with id =2 would be [50][2]. Module with id 495 would be [70][495].

At module level, you only need to worry about CONTEXT_MODULE. Normally, foreach page accessible in your module you would need to load the module using get_context_instance(). The way to use it for modules is $context = get_context_instance(CONTEXT_MODULE, $cm->id); where $cm is the course module object that you would normally have anyway. The contextid is needed for every permission check later on in all your pages.

==The has_capability($capability, $contextid, $kill) function==

inputs:

$capability is the name of the capability
$contextid is normally $context->id, the module context id
$kill set to 1 if you want to kill the page, it will throw an error and inform the user that required permission is missing. For example you place has_capability('forum_read', $context->id, true) at the top of the page to prevent users from reading the whole page.

This function looks up a capability for a given context and associated parents recursively. We are pretty much relying on this funciton alone to resolve all capability issues. Original isteacher(), isadmin(), isstudent() etc should all be changed accordingly.

==Loading capabilities== - for now, this plan might change later

Loading capabilities is done when a user first log in. Because it is quite an expensive call, we only load it once and stores everything in the session. So when has_capability() is called, it looks for the values stored in the session variable.

==Code rewrite==

Some modules might require some tiny rewrites because permission is only checked once at the top, for example some scripts only checks for isstudent() at the top. Now we are able to refine those capabilities, so we need to put the required code changes (add has_capability()) to where the specific capability is needed. For example, in a forum we check to see if user is a student before displaying a discussion page, now we need to check individual permissions for forum_read and forum_reply.

==Sample code==

<pre>// somewhere at the top, after getting $cm, load context

$context = get_context_instance(CONTEXT_MODULE, $cm->id);

...

has_capability('forum_read', $cm->id, true); // kills this page if user is not allowed to read

...

if (has_capability('forum_reply', $cm->id) {
print_reply_link();
}</pre>

==Core API==

The core API is located at libdir/accesslib, if you would like to read it =)

[[Category:Developer]]
[[Category:Roles]]

Development:Roles

2007-01-17T08:40:09Z

Nenashev: /* See also */ forum link's

'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.

==Definitions==

A role is an identifier of the user's status in some context. For example, teacher, student and fourm moderator are examples of roles.

A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.

A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.

A context is a "space" in the Moodle, such as courses, activity modules, blocks etc.

==The existing system==

Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can perform are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.

==The new roles and capability system==

{{Moodle 1.7}}Role has two primary functions:
# define list of permissions - role definition is global for all contexts, but can be changed by local context overrides
# replace old course erolments - role assignment in course context is simitar to the old enrolment process

The new system will allow authorized users to define an arbitrary number of roles (eg a teacher)

A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)

Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)

Here are the possible contexts, listed from the most general to the most specific.

#CONTEXT_SYSTEM -- the whole site
#CONTEXT_PERSONAL -- yourself
#CONTEXT_USER -- another user
#CONTEXT_COURSECAT -- a course category
#CONTEXT_COURSE -- a course
#CONTEXT_GROUP -- a group
#CONTEXT_MODULE -- an activity module
#CONTEXT_BLOCK -- a block

An authorized user will be able to assign an arbitrary number of roles to each user in any context.

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.

Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.

For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.

If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in "Science forum" in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in "Science forum".

Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.

This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.

==Upgrading from 1.6==

A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.

===Admins===

Admin users will be assigned the default legacy admin role in the system (site) context

===Course Creators===

Admin users will be assigned the default legacy course creator role in the system (site) context

===Teachers===

Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.

===Students===

Users who were students will be assigned the default student role in all courses they were student.

===Guests===

There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.

==Capabilities==

This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.

===Core-level Capabilities===

Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php

#moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7
#moodle/legacy:student
#moodle/legacy:teacher
#moodle/legacy:editingteacher
#moodle/legacy:coursecreator
#moodle/legacy:admin
#moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings
#moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
#moodle/site:readallmessages - reads all messages and history
#moodle/site:approvecourse - approves a pending course
#moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php
#moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php
#moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php
#moodle/site:import - can import other courses into this context : 1)block_admin.php
#moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in
#moodle/site:accessdb - directly accessing db (phpmyadmin)
#moodle/site:viewfullnames - able to see fullnames of other users
#moodle/site:viewparticipants - able to view participants
#moodle/site:viewreports - able to view site/course reports
#moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas
#moodle/site:uploadusers - ability to upload/update users from text file; moodle/role:assign capability is needed for course enrolling
#moodle/blog:view - read blogs (usable in system or course context)
#moodle/blog:create - write new blog posts (usable in system context only)
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use (usable in system context only)
#moodle/blog:managepersonaltags - delete personal blog tags that others can use (usable in system context only) Note: users can always add own personal tags. This setting should be off for students by default.
#moodle/blog:manageentries - edit/delete all blog entries (usable in system context only)
#moodle/course:setcurrentsection - mark course section
#moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php
#moodle/course:delete - create courses : 1)course/category.php
#moodle/course:update - update course settings
#moodle/course:view - can use this to find participants
#moodle/course:viewparticipants - allows a user to view participant list
#moodle/course:viewscales - view scales (i.e. in a help window?) : 1)course/scales.php
#moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)
#moodle/course:managescales - add, delete, edit scales, move scales up and down : 1)blocks/block_admin.php 2)course/scales.php
#moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php
#moodle/course:managefiles - manage course files and folders
#moodle/course:managequestions - manage course questions
#moodle/course:managemetacourse - manage child courses in metacourse
#moodle/course:reset - able to reset the course
#moodle/course:useremail - Can use the enable/disable email stuff
#moodle/course:visibility - hide/show courses : 1)course/category.php
#moodle/course:viewhiddencourses - see hidden courses
#moodle/course:activityvisibility - hide/show activities within a course
#moodle/course:viewhiddenactivities - able to see activities that have been hidden
#moodle/course:sectionvisibility - hide/show sections
#moodle/course:viewhiddensections - view hidden sections
#moodle/course:viewcoursegrades - views all grades in course
#moodle/course:viewhiddenuserfields - view all hidden user fields
#moodle/course:managegrades - manages grades settings in course
#moodle/category:create - create category : 1)course/index.php
#moodle/category:delete - delete category : 1)course/index.php
#moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php
#moodle/category:visibility - hide/show categories : 1)course/index.php
#moodle/user:viewusergrades - view your own, or other user's grades (with specified context)
#moodle/user:create - create user : 1) user/edit.php
#moodle/user:delete - delete user : 1) admin/user.php
moodle/user:readuserblogs - read blog entries
#moodle/user:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

===User-level Capabilities===
# moodle/user:readuserposts -read individual user posts on profile page (parent?)
# moodle/user:readuserblogs -read individual user blogs on profile page (parent?)
# moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)
# moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)

===Module-level Capabilities===
The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.

The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The part before the colon is the full path to the module in the Moodle code. The module capabilities are defined in mod/mod_name/db/access.php.

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:writeentry - add / edit and delete (own) entries
##mod/data:managetemplates - add, delete, edit fields and templates
##mod/data:manageentries - edit/delete all entries
##mod/data:comment - comment
##mod/data:managecomments - edit/delete all comments
##mod/data:rate - rate an entry
##mod/data:viewrating
##mod/data:approve - approves an entry
##mod/data:uploadentries - batch upload of entries
#Exercise
##mod/exercise:assess
#Forum
##mod/forum:viewdiscussion
##mod/forum:viewdiscussionsfromallgroups
##mod/forum:viewhiddentimedposts
##mod/forum:startdiscussion
##mod/forum:replypost
##mod/forum:viewrating
##mod/forum:viewanyrating
##mod/forum:rate
##mod/forum:createattachment
##mod/forum:deleteownpost
##mod/forum:deleteanypost
##mod/forum:splitdiscussions
##mod/forum:movediscussions
##mod/forum:editanypost
##mod/forum:viewqandawithoutposting
##mod/forum:viewsubscribers
##mod/forum:managesubscriptions
##mod/forum:throttlingapplies
#Glossary
##mod/glossary:write - add entries
##mod/glossary:manageentries - add, edit, delete entries
##mod/glossary:managecategories - create, delete, edit categories
##mod/glossary:comment - comment on an entry
##mod/glossary:managecomments - edit, delete comments
##mod/glossary:import - import glossaries
##mod/glossary:export - export glossaries
##mod/glossary:approve - approve glossaries
##mod/glossary:rate - rates glossary
##mod/glossary:viewrating - view ratings
#Hotpot
##mod/hotpot:attempt - attempt a hotpot
##mod/hotpot:viewreport - review and view reports
##mod/hotpot:grade - (grade? and) regrade
##mod/hotpot:deleteattempt - deletes attempts
#Label
##none
#Lams
##mod/lams:participate - original student
##mod/lams:manage - original teacher
#Lesson
##mod/lesson:edit - add and edit pages
##mod/lesson:manage - view student attempts
#Quiz
##mod/quiz:grade - comment, override grade, manual grade
##mod/quiz:preview - previews the quiz
##mod/quiz:viewreports - view quiz result reports
##mod/quiz:manage - add/delete/move (up or down) questions for a quiz
##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]
#Resource
#Scorm
##mod/scorm:viewgrades
#Survey
##mod/survey:download - downloads survery result
##mod/survey:participate - participate/ do survey
##mod/survey:readresponses - read all user's responese
#Wiki
##mod/wiki:participate - original student, meaning depends of type and course setting
##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups
##(Waiting on new wiki)
#Workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.

#Authorize.net Payment Gateway
##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.

===Blocks===
#activity_modules
##None
#admin
#admin_2
#admin_bookmarks
#blog_menu
#blog_tags
#calendar_month
#calendar_upcoming
#course_list
#course_summary
#glossary_random
#html
#loancalc
#login
#messages
#news_items
#online_users
#participants
#quiz_results
#recent_activity
#rss_client
##block/rss_client:createprivatefeeds
##block/rss_client:createsharedfeeds
##block/rss_client:manageownfeeds
##block/rss_client:manageanyfeeds
#search
#search_forums
#section_links
#site_main_menu
#social_activities

===Questions===
I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&bugid=6118&pos= bug 6118].

See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)

==Programming Interface==

Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.

* You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):
'mod/forum:viewforum' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'guest' => CAP_PREVENT,
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'coursecreator' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
* To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.
* On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:

$context = get_context_instance(CONTEXT_MODULE, $cm->id);
* Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:
if (!has_capability('mod/forum:viewforum', $context)) {
print_error('nopermissiontoviewforum');
}
* If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:

require_capability('mod/forum:viewforum', $context);

* Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated "No permissions" message that lists the permission they were missing.

As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.

==Metacourses==

The behaviour of metacourses in Moodle 1.7 changed slightly, in that where it used to just synch students from child courses to the parent course, it will now synch ALL roles. Teachers etc of the child courses will have the same role in the meta course. Technically metacourse synchronises all role assignments in CONTEXT_COURSE with its child courses; the only exception are users with moodle/course:managemetacourse capability, these users are synchronized only upwards, they are not unenrolled from metacourse when unenroling from child course or when removing the child from metacourse.

In order to import/enrol other courses into metacoure you need to have moodle/course:managemetacourse capability. You can add manually only participants with moodle/course:managemetacourse, all other participants are automatically synced with child courses - if you try to manually enrol user without this capability error is displayed. Similar error is shown also when you try to manually unenrol participant from meta course while still being enrolled in child course.

Sample setup:
* metacourse manager has been assigned role with moodle/course:managemetacourse capability in system or course category context
* students are enrolled in several child courses
* teachers are enrolled in separate child course(s)

==Problem areas we are working on ==

===Student view===

The "Student view" button has been removed completely.

If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.

===Teacher forum===

Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.

We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.

===Enrolment plugins===

====Process of logging in====

# load_user_capability() is called to load all the capabilities
# check_enrolment_plugins() is called at the top of load_user_capability() to check all the enrolment plugins.
# For each active plugin:
##Check for setup_enrolments($user) and run it. This function will do all the processing needed to assign or unassign roles from the current user.
# load_user_capability() continues and loads up all the roles
# load_defaultuser_role() is called to add default site permissions (all users)

====Process of checking access to a course====

require_login($course->id) is called by the script and has logic like this:

# Is the user a guest at site level?
## Yes: Does the course allow guests?
### Yes: return true (and further capabilities are checked by the script)
### No: send the user to course/enrol.php for enrolment
## No: continue below

# Does the user have moodle/course:view in that (course) context?
## Yes: then they can enter (and further capabilities are checked by the script)
## No: is guest access allowed on the course?
### Yes: assign temporary guest role to that user for that context (in session cache).
### No: send the user to course/enrol.php for enrolment.

====Process of enrolling====

(more soon)

==Scenario brainstorming==

This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.

===Student===
Obviously.

===Site Designers===
Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

===Educational Authority Adviser===
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

===Educational Inspector===
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

===Second Marker / Moderator===
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

===Peer observer of teaching===
Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).

===External Examiner===
Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

===Parent===
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.

In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?

Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.

There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.

===Manager===
''Please add text here...''

===Weekly Seminar Leader===
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''

===Mentor/Mentee===
''Please add text here...''

===Community-Designed Rating Criteria===
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''

===Visitor===

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

===Guest Speaker===

This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.

===Former Student===
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)

===Librarian===

Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.

===Teacher===

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)

===Community Education Tutors/Trainers===
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

===Secretary/Student Worker===

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

===Teaching Assistant===

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

===Student - FERPA rights===

A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name
in any public place. Could include this student only being seen with an "alias" within course spaces. Is this an attribute rather
than a role?

===Help Desk===

Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy
of inheritance is needed, full access will be problematic with FERPA.

===Admin - Catgory based===

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

===Process Roles===

organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:
* Give a student the role of forum-moderator with edit and chunk-rights
* Give students different roles & rights in a Webquest design (and change these roles next week
* Give students different resources, depending of their roles in a rolegame/simulation
* Give a student the rights to create the section content of next week (and only that week..)

==Things to finish for 1.7 Beta==
'''18 Sept 2006'''

#Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]
#Address function: isteacher, isadmin, isstudent [Yu]
#Remove "view" capabilities from all modules unless required [Vy]
#Remove all old references from remaining Blocks [Vy]
#Metacourses [Skodak]
#Add risks to GUI[Skodak]
#Enrolment plugins [Martin and Alastair]
#[[Development:Stats_roles_1.7|Statistics]] [Penny]
#Fix Loginas
#Add category-level assigns [Yu]
#[[Development:Backup_roles_1.7|Backups]] [Eloy?]

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. The sketches below are not worked out proposals. Their task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from "allow" to "prohibit" (If you may want to see larger images please click onto the image or the "Enlarge" icon below the image.)

The list of possible settings is very long and '' "... the problem is not to overwhelm people with information" ''.

[[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]

1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.
 

[[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]

2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements.

For example click on an icon beside the sub heading "Course categories" and show/hide all table rows with the CLASS "course-category".
 

[[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]

3) '' "The main problem is the last column for risk ... we were thinking of putting little icons in there ..." ''
Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tool-tip function would be able to give the user valuable information about the meaning.
 

==See also==

*[[Hardening new Roles system]]
*Using Moodle course:
**[http://moodle.org/mod/forum/view.php?f=941 Roles and Capabilities forum]
**Key discussions at Using Moodle forums:
***[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
***[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]
[[Category:Developer]]
[[Category:Future]]
[[Category:Roles]]

mod/data

2006-10-06T08:21:40Z

Nenashev:

see [[Database module]]

Development:Developer documentation

2006-09-27T09:51:04Z

Nenashev: /* Documentation for core components */

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>.

==Guidelines==
The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle architecture]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Unit tests]] explains how to run the unit tests, and how to write new test cases.
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc

== Resources and tools ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[http://tracker.moodle.org/ Moodle bug tracker] - bug reports, feature requests and other tracked issues
*[http://moodle.org/mod/forum/view.php?id=55 General developer forum]
*[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web
*[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
*[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.
*[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD

==How you can contribute==

The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):
*[[Modules (developer)|Activity modules]]
*[[Assignment types]]
*[[Authentication|Authentication methods]]
*[[Blocks Howto|Blocks]]
*[[Course formats]]
*[[Database fields (developer)|Database fields]]
*[[Database presets]]
*[[Enrolment plugins (developer)|Enrolment plugins]]
*[[Filters (developer)|Filters]]
*[[Question_engine]]
*[[Question import/export formats]]
*[[Question bank|Question bank teacher docs]]
*[[Question_engine#Question_types|Question types developper docs]]
*[[Quiz reports]]
*[[Resource types]]
*[[SSO plugins]]

There are also ways you can contribute that don't involve PHP programming:
*[[Themes]]
*[[Translation]]
*[[Database Schemas|Database schemas]]

You can also help a lot by
*[[Tests|Testing]]
*[[Tracker|Participating in the bug tracker]]

==Plans for the future==
Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.
*[[Roadmap]]
*[[Developer notes]]
*[[Student projects]]
*[[Developer conference|Developer conferences]]

==Documentation for core components==
This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].

*[[Development:Migration to Role-driven model|Migration to Role-driven model]] @ v[[1.7]]
*[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]
*[[Question engine]]
*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]
*[[Authentication API]]
*[[Stats package]]
*[[Email processing]]
*[[Cookieless Sessions]]

==Documentation for contributed code==
Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.

==See also==
*[http://security.moodle.org/ Moodle Security Centre]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

[[Category:Developer]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[zh:开发者文档]]

Development:Developer documentation

2006-09-27T09:50:33Z

Nenashev: /* Documentation for core components */

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>.

==Guidelines==
The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle architecture]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Unit tests]] explains how to run the unit tests, and how to write new test cases.
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc

== Resources and tools ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[http://tracker.moodle.org/ Moodle bug tracker] - bug reports, feature requests and other tracked issues
*[http://moodle.org/mod/forum/view.php?id=55 General developer forum]
*[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web
*[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
*[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.
*[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD

==How you can contribute==

The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):
*[[Modules (developer)|Activity modules]]
*[[Assignment types]]
*[[Authentication|Authentication methods]]
*[[Blocks Howto|Blocks]]
*[[Course formats]]
*[[Database fields (developer)|Database fields]]
*[[Database presets]]
*[[Enrolment plugins (developer)|Enrolment plugins]]
*[[Filters (developer)|Filters]]
*[[Question_engine]]
*[[Question import/export formats]]
*[[Question bank|Question bank teacher docs]]
*[[Question_engine#Question_types|Question types developper docs]]
*[[Quiz reports]]
*[[Resource types]]
*[[SSO plugins]]

There are also ways you can contribute that don't involve PHP programming:
*[[Themes]]
*[[Translation]]
*[[Database Schemas|Database schemas]]

You can also help a lot by
*[[Tests|Testing]]
*[[Tracker|Participating in the bug tracker]]

==Plans for the future==
Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.
*[[Roadmap]]
*[[Developer notes]]
*[[Student projects]]
*[[Developer conference|Developer conferences]]

==Documentation for core components==
This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].

*[[Development:Migration to Role-driven model]] @ v[[1.7]]
*[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]
*[[Question engine]]
*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]
*[[Authentication API]]
*[[Stats package]]
*[[Email processing]]
*[[Cookieless Sessions]]

==Documentation for contributed code==
Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.

==See also==
*[http://security.moodle.org/ Moodle Security Centre]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

[[Category:Developer]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[zh:开发者文档]]

Development:Developer documentation

2006-09-27T09:48:29Z

Nenashev: /* Documentation for core components */ version tip

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>.

==Guidelines==
The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle architecture]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Unit tests]] explains how to run the unit tests, and how to write new test cases.
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc

== Resources and tools ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[http://tracker.moodle.org/ Moodle bug tracker] - bug reports, feature requests and other tracked issues
*[http://moodle.org/mod/forum/view.php?id=55 General developer forum]
*[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web
*[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
*[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.
*[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD

==How you can contribute==

The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):
*[[Modules (developer)|Activity modules]]
*[[Assignment types]]
*[[Authentication|Authentication methods]]
*[[Blocks Howto|Blocks]]
*[[Course formats]]
*[[Database fields (developer)|Database fields]]
*[[Database presets]]
*[[Enrolment plugins (developer)|Enrolment plugins]]
*[[Filters (developer)|Filters]]
*[[Question_engine]]
*[[Question import/export formats]]
*[[Question bank|Question bank teacher docs]]
*[[Question_engine#Question_types|Question types developper docs]]
*[[Quiz reports]]
*[[Resource types]]
*[[SSO plugins]]

There are also ways you can contribute that don't involve PHP programming:
*[[Themes]]
*[[Translation]]
*[[Database Schemas|Database schemas]]

You can also help a lot by
*[[Tests|Testing]]
*[[Tracker|Participating in the bug tracker]]

==Plans for the future==
Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.
*[[Roadmap]]
*[[Developer notes]]
*[[Student projects]]
*[[Developer conference|Developer conferences]]

==Documentation for core components==
This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].

*[[Migration to Role-driven model]] @ v[[1.7]]
*[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]
*[[Question engine]]
*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]
*[[Authentication API]]
*[[Stats package]]
*[[Email processing]]
*[[Cookieless Sessions]]

==Documentation for contributed code==
Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.

==See also==
*[http://security.moodle.org/ Moodle Security Centre]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

[[Category:Developer]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[zh:开发者文档]]

Development:Developer documentation

2006-09-27T09:41:23Z

Nenashev: /* Documentation for core components */ migration to role-driven model need to be described

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>.

==Guidelines==
The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle architecture]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Unit tests]] explains how to run the unit tests, and how to write new test cases.
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc

== Resources and tools ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[http://tracker.moodle.org/ Moodle bug tracker] - bug reports, feature requests and other tracked issues
*[http://moodle.org/mod/forum/view.php?id=55 General developer forum]
*[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web
*[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
*[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.
*[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD

==How you can contribute==

The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):
*[[Modules (developer)|Activity modules]]
*[[Assignment types]]
*[[Authentication|Authentication methods]]
*[[Blocks Howto|Blocks]]
*[[Course formats]]
*[[Database fields (developer)|Database fields]]
*[[Database presets]]
*[[Enrolment plugins (developer)|Enrolment plugins]]
*[[Filters (developer)|Filters]]
*[[Question_engine]]
*[[Question import/export formats]]
*[[Question bank|Question bank teacher docs]]
*[[Question_engine#Question_types|Question types developper docs]]
*[[Quiz reports]]
*[[Resource types]]
*[[SSO plugins]]

There are also ways you can contribute that don't involve PHP programming:
*[[Themes]]
*[[Translation]]
*[[Database Schemas|Database schemas]]

You can also help a lot by
*[[Tests|Testing]]
*[[Tracker|Participating in the bug tracker]]

==Plans for the future==
Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.
*[[Roadmap]]
*[[Developer notes]]
*[[Student projects]]
*[[Developer conference|Developer conferences]]

==Documentation for core components==
This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].

*[[Role-driven model migration|Migration to Role-driven model]] @ v[[1.7]]
*[[UTF-8 migration|Migration to UTF-8]]
*[[Question engine]]
*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]
*[[Authentication API]]
*[[Stats package]]
*[[Email processing]]
*[[Cookieless Sessions]]

==Documentation for contributed code==
Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.

==See also==
*[http://security.moodle.org/ Moodle Security Centre]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

[[Category:Developer]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[zh:开发者文档]]

LDAP enrolment

2006-09-13T09:03:15Z

Nenashev: /* LDAP Enrollment HOWTO (by Lars Jensen) */ ++ link to LDAP authentication

== LDAP Enrollment HOWTO (by Lars Jensen) ==

This howto describes how to set up LDAP enrollment in Moodle. [[LDAP enrolment]] works best in moodle when used in conjunction with [[LDAP authentication]], and we're going to assume that you have already set moodle up for LDAP authentication.

=== Assumptions ===

# You are running a recent version of moodle. We have tested the setup presented here on versions 1.5.2+ and 1.6dev. It is likely to work on moodle 1.4.5 as well.
# You are using LDAP authentication as your primary authentication method.
# Each user in has a uid attribute in the users LDAP record, that matches the ID number in the same users moodle profile (this can easily be arranged with a mapping on the moodle LDAP Authentication setup page).

=== The Course Setup ===

Our setup involves the following course and user definitions:

* Two courses, '''Math101''' and '''Eng201'''.
* Two teachers, '''teachera''' and '''teacherb'''.
* Three students, '''studentd''', '''studente''', and '''studentf'''.
* studentd and studente are enrolled as students in Math101, and teachera is enrolled as teacher of Math101. studente and studentf are enrolled as students in Eng201, and teachera and teacherb are both enrolled as teachers of Eng201.

=== The LDAP Container Setup ===

# Define two LDAP containers ou=StudentEnrollment and ou=TeacherEnrollment
# For each course we define an LDAP group entry (e.g a posixGroup entry) in the StudentEnrollment and TeacherEnrollment containers. Thus, we define a Math101 posixGroup under StudentEnrollment, and we define a Math101 posixGroup under TeacherEnrollment. We define the two Eng201 groups in a similar way.
# Enroll students and teachers as members of in the LDAP-groups we just defined. This is done by entering the users uid attribute in the memberUid attribute of the relevant group:
#* teachera is a member of the Math101 group under TeacherEnrollment.
#* studentd and studente are a members of the Math101 group under StudentEnrollment.
#* teachera and teacherb are members of the Eng201 group under TeacherEnrollment
#* studente and studentf are a members of the Eng201 group under StudentEnrollment.

=== The LDAP Enrollment Configuration in Moodle ===

The LDAP enrollment settings in moodle corresponding to the above setup are as follows:

{| cellspacing="0" cellpadding="5" border="1"
! LDAP Enrollment Variable:
! Value:
|-
| enrol_ldap_student_contexts:
| ou=StudentEnrollment,dc=ldapserver,dc=tmcc,dc=edu
|-
| enrol_ldap_student_memberattribute:
| memberUid
|-
| enrol_ldap_teacher_contexts:
| ou=TeacherEnrollment,dc=ldapserver,dc=tmcc,dc=edu
|-
| enrol_ldap_teacher_memberattribute:
| memberUid
|-
| enrol_ldap_objectclass:
| posixGroup
|-
| enrol_ldap_course_idnumber:
| cn
|-
| enrol_ldap_course_shortname:
| cn
|-
| enrol_ldap_course_fullname:
| cn
|-
| enrol_ldap_autocreate:
| Yes
|-
|}

Additionally, since you are using LDAP authentication, you should also map the moodle "ID number" of users to the "uid" in the ldap entry of the user. This is done on the moodle LDAP Authentication page (not the LDAP Enrollment page).

=== Notes: ===

# You do not need to create the courses manually in moodle. If they don't exist, they will be created when the first enrolled user login.
# We are using the same string cn and uid in a users LDAP record. This is not necessary, I believe. However, if you use different values, you will need to define the ldap_user_attribute to uid in the LDAP authentication setup.
# The value of the group id number (gidNumber) defined for the groups in step 2 of the LDAP Container Setup above is not critical. It is not used in this setup.
# The attached .ldif file assumes that users are in the ou=People container in LDAP. You will need to configure your LDAP Authentication setup to reflect this (ldap_contexts variable).
# User passwords for this setup are defined in the attached .ldif file.
# If you use the attached .ldif file, you'll need to edit the ldap server information (the "dn=" lines).

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=31761 LDAP Enrollment HOWTO] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=39549 LDAP Auto enrollment] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=41829 LDAP nightmare Part II] forum discussion

[[Category:Administrator]]
[[Category:Enrolment]]

LDAP enrollment

2006-09-13T09:02:20Z

Nenashev:

#redirect [[LDAP enrolment]]

LDAP authentication

2006-09-13T08:50:47Z

Nenashev: ++ see also LDAP enrolment

This document describes how to set up LDAP authentication in Moodle. You can find a [[#Basic Scenario|Basic Scenario]], where everything is simple and straightforward, and that should be enough for most installations. If your installation is a little bigger and you are using multiple LDAP servers, or multiple locations (contexts) for your users in your LDAP tree, then have a look at the [[#Advanced Scenarios|Advanced Scenarios]].

==Basic Scenario==

===Assumptions===

# Your Moodle site is located at '''http://your.moodle.site/'''
# You have configured your PHP installation with the LDAP extension. It is loaded and activated, and it shows when you go to '''http://your.moodle.site/admin/phpinfo.php''' (logged in as user 'admin').
# Your LDAP server has '''192.168.1.100''' as its IP address.
# You are not using LDAP with SSL (also known as LDAPS) in your settings. This might prevent certain operations from working (e.g., you cannot update data if you are using MS Active Directory -- MS-AD from here on --), but should be OK if you just want to authenticate your users.
# You don't want your users to change their passwords the first time they log in into Moodle.
# You are using a single domain as the source of your authentication data in case you are using MS-AD (more on this in the Appendices).
# You are using a top level distinguished name (DN) of '''dc=my,dc=organization,dc=domain''' as the root of your LDAP tree.
# You have a non-privileged LDAP user account you will use to bind to the LDAP server. This is not necessary with certain LDAP servers, but MS-AD requires this and it won't hurt if you use it even if your LDAP server doesn't need it. Make sure '''this account and its password don't expire''', and make this password as strong as possible. Remember you only need to type this password once, when configuring Moodle, so don't be afraid of making it as hard to guess as possible. Let's say this user account has a DN of '''cn=ldap-user,dc=my,dc=organization,dc=domain''', and password '''hardtoguesspassword'''.
# All of your Moodle users are in an organizational unit (OU) called '''moodleusers''', which is right under your LDAP root. That OU has a DN of '''ou=moodleusers,dc=my,dc=organization,dc=domain'''.
# You '''don't''' want your LDAP users' passwords to be stored in Moodle at all.

===Configuring Moodle authentication===

Log in as an admin user and go to Administration >> Users >> Authentication. In the drop down listbox titled "Choose an authentication method" select "Use an LDAP Server". You will get a page similar to this one:

 
::: [[Image:auth_ldap_config_screenshot.jpg]]
 

Now, you just have to fill in the values. Let's go step by step.
 
 

{| border="1" cellspacing="0" cellpadding="5"
! Field name
! Value to fill in
|-
| ldap_host_url
| As the IP of your LDAP server is 192.168.1.100, type "'''ldap://192.168.1.100'''" (without the quotes).
|-
| ldap_version
| Unless you are using a really old LDAP server, '''version 3''' is the one you should choose.
|-
| ldap_preventpassindb
| As you '''don't''' want to store the users's password in Moodle's database, choose '''Yes''' here.
|-
| ldap_bind_dn
| This is the distinguished name of the bind user defined above. Just type "'''cn=ldap-user,dc=my,dc=organization,dc=domain'''" (without the quotes).
|-
| ldap_bind_pw
| This is the bind user password defined above. Type "'''hardtoguesspassword'''" (without the quotes).
|-
| ldap_user_type
| Choose:
* '''Novel Edirectory''' if your LDAP server is running Novell's eDdirectory.
* '''posixAccount (rfc2307)''' if your LDAP server is running a RFC-2307 compatible LDAP server (choose this is your server is running OpenLDAP).
* '''posixAccount (rfc2307bis)''' if your LDAP server is running a RFC-2307bis compatible LDAP server.
* '''sambaSamAccount (v.3.0.7)''' if your LDAP server is running with SAMBA's 3.x LDAP schema extension and you want to use it.
* '''MS ActiveDirectory''' if your LDAP server is running Microsoft's Active Directory (MS-AD)
|-
| ldap_contexts
| The DN of the context (container) where all of your Moodle users are found. Type '''ou=moodleusers,dc=my,dc=organization,dc=domain''' here.
|-
| ldap_search_sub
| If you have any sub organizational units (subcontexts) hanging from '''ou=moodleusers,dc=my,dc=organization,dc=domain''' and you want Moodle to search there too, set this to '''yes'''. Otherwise, set this to '''no'''.
|-
| ldap_opt_deref
| Sometimes your LDAP server will tell you that the real value you are searching for is in fact in another part of the LDAP tree (this is called an alias). If you want Moodle to 'dereference' the alias and fetch the real value from the original location, set this to '''yes'''. If you don't want Moodle to dereference it, set this to '''no'''. If you are using MS-AD, set this to '''no'''.
|-
| ldap_user_attribute
| The attribute used to name/search users in your LDAP tree. This option takes a default value based on the ''ldap_user_type'' value you choosed above. So unless you need something special, you don't need to fill this in.

By the way, it's usually '''cn''' (Novell eDirectory and MS-AD) or '''uid''' (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could use '''sAMAccountName''' (the pre-Windows 2000 logon account name) if you need too.
|-
| ldap_memberattribute
| The attribute used to list the members of a given group. This option takes a default value based on the ''ldap_user_type'' value you choosed above. So unless you need something special, you don't need to fill this in.

By the way, the usual values are '''member''' and '''memberUid'''.
|-
| ldap_objectclass
| The type of LDAP object used to search for users. This option takes a default value based on the ''ldap_user_type'' value you choosed above. So unless you need something special, you don't need to fill this in.

Here are the default values for each of the ''ldap_user_type'' values:
* '''User''' for Novel eDirectory
* '''posixAccount''' for RFC-2037 and RFC-2037bis
* '''sambaSamAccount''' for SAMBA 3.0.x LDAP extension
* '''user''' for MS-AD
|-
| Force change password
| Set this to ''Yes'' if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to ''no''. Bear in mind the password they are forced to change is the one stored in your LDAP server.

As you don't want your users to change their passwords in their first login, leave this set to ''No''
|-
| Use standard Change Password Page
|
* Setting this to ''Yes'' makes Moodle use it's own standard password change page, everytime users want to change their passwords.
* Setting this to ''No'' makes Moodle use the the page specified in the field called "Change password URL" (at the bottom of the configuration page).

Bear in mind that changing your LDAP passwords from Moodle might require a LDAPS connection (this is true at least for MS-AD).

Also, code for changing passwords from Moodle for anything but Novell eDirectory is almost not tested, so this may or may not work for other LDAP servers.
|-
| ldap_expiration
|
* Setting this to ''No'' will make Moodle not to check if the password of the user has expired or not.
* Setting this to ''LDAP'' will make Moodle check if the LDAP password of the user has expired or not, and warn her a number of days before the password expires.

Current code only deals with Novell eDirectory LDAP server, but there is a patch floating around to make it work with MS-AD too (search in the authentication forum).

So unless you have Novell eDirectory server (or use the patch), choose ''No'' here.
|-
| ldap_expiration_warning
| This value sets how many days in advance of password expiration the user is warned that her password is about to expire.
|-
| ldap_exprireattr
| The LDAP user attribute used to check password expiration. This option takes a default value based on the ''ldap_user_type'' value you choosed above. So unless you need something special, you don't need to fill this in.
|-
| ldap_gracelogins
| This setting is specific to Novell eDirectory. If set to ''Yes'', enable LDAP gracelogin support. After password has expired the user can login until gracelogin count is 0.

So unless you have Novell eDirectory server and want to allow gracelogin support, choose ''No'' here.
|-
| ldap_graceattr
| This setting is currently not used in the code (and is specific to Novell eDirectory).

So you don't need to fill this in.
|-
| ldap_create_context
|
|-
| ldap_creators
| The DN of the group that contains all of your Moodle creators. This is typically a posixGroup with a "memberUid" attribute for each user you want to be a creator. If your group is called ''creators'', type '''cn=creators,ou=moodleusers,dc=my,dc=organization,dc=domain''' here. Each memberUid attribute contains the CN of a user who is authorized to be a creator. Do not use the user's full DN (e.g., not '''memberUid: cn=JoeTeacher,ou=moodleusers,dc-my,dc=organizations,dc=domain''', but rather '''memberUid: JoeTeacher''').

In eDirectory, the objectClass for a group is (by default) not '''posixGroup''' but '''groupOfNames,''' whose member attribute is '''member,''' not '''memberUid,''' and whose value is the full DN of the user in question. Although you can probably modify Moodle's code to use this field, a better solution is just to add a new '''objectClass''' attribute of '''posixGroup''' to your creators group and put the CNs for each creator in a '''memberUid''' attribute.

In MS Active Directory, you will need to create a security group for your creators to be part of and then add them all. If your ldap context above is 'ou=staff,dc=my,dc=org' then your group should then be 'cn=creators,ou=staff,dc=my,dc=org'. If some of the users are from other contexts and have been added to the same security group, you'll have to add these as separate contexts after the first one using the same format.
|-
| First name
| The name of the attribute that holds the first name of your users in your LDAP server. This is usually '''givenName'''.

This setting is optional
|-
| Surname
| The name of the attribute that holds the surname of your users in your LDAP server. This is usually '''sn'''.

This setting is optional
|-
| Email address
| The name of the attribute that holds the email address of your users in your LDAP server. This is usually '''mail'''.

This setting is optional
|-
| Phone 1
| The name of the attribute that holds the telephone number of your users in your LDAP server. This is usually '''telephoneNumber'''.

This setting is optional
|-
| Phone 2
| The name of the attribute that holds an additional telephone number of your users in your LDAP server. This can be '''homePhone''', '''mobile''', '''pager''', '''facsimileTelephoneNumber''' or even others.

This setting is optional
|-
| Department
| The name of the attribute that holds the department name of your users in your LDAP server. This is usully '''departmentNumber''' (for posixAccount and maybe eDirectory) or '''department''' (for MS-AD).

This setting is optional
|-
| Address
| The name of the attribute that holds the street address of your users in your LDAP server. This is usully '''streetAddress''' or '''street'.

This setting is optional
|-
| City/town
| The name of the attribute that holds the city/town of your users in your LDAP server. This is usully '''l''' (lowercase L) or '''localityName''' (not valid in MS-AD).

This setting is optional
|-
| Country
| The name of the attribute that holds the couuntry of your users in your LDAP server. This is usully '''c''' or '''countryName''' (not valid in MS-AD).

This setting is optional
|-
| Description
| '''description'''

This setting is optional
|-
| ID Number
|

This setting is optional
|-
| Language
| '''preferredLanguage'''

This setting is optional
|-
| Instructions
|
|}

The rest of the fields are common to all authentication methods and will not be discussed here.

==Advanced Scenarios==

===Using multiple LDAP Servers===
Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax :
ldap://my.first.server ; ldap//my.second.server ; ...

Of course, this will only work if all the servers share the same directory information, using a replication or synchronization mecanism once introduced in eDirectory and now generalized to the main LDAP-compatible directories.

There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.

===Using multiple user locations (contexts) in your LDAP tree===
There is no need to use multiple user locations if your directory tree is flat, i.e. if all user accounts reside in a '''ou=people,dc=my,dc=organization,dc=domain''' or '''ou=people,o=myorg''' container.

At the opposite, if you use the ACL mecanism to delegate user management, there are chances that your users will be stored in containers like '''ou=students,ou=dept1,o=myorg''' and '''ou=students,ou=dept2,o=myorg''' ...

Then there is an alternative :
* Look at the '''o=myorg''' level with the ldap_search_sub attribute set to '''yes'''.
* Set the ldap_context to '''ou=students,ou=dept1,o=myorg ; ou=students,ou=dept2,o=myorg'''.

Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree '''and''' on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same ''common name'' (cn), while having different ''distinguished names''. Then only the second solution will have a deterministic result (returning allways the same user).

===Using LDAPS (LDAP + SSL)===
====MS Active Directory + SSL ====

If the Certificate Authority is not installed you'll have to install it first as follows:
# Click '''Start''' -> '''Control Panel''' -> '''Add or Remove programs.'''
# Click '''Add/Remove Windows Components''' and select '''Certificate Services.'''
# Follow the prosedure provided to install the '''Certificate Authority'''. Enterprise level is a good choice.

Verify that SSL has been enabled on the server by installing suptools.msi from Windows installation cd's \Support\tools directory. After support tools installation:
# Select '''Start''' -> '''Run''', write '''ldp''' in the Open field.
# From the ldp window select '''Connection''' -> '''Connect''' and supply valid hostname and port number '''636'''. Also select the SSL check box.

If successful, you should get information about the connection.

Next step is to tell PHP's OpenLDAP extension to disable SSL certificate checking. On Windows servers you're most likely using pre-compiled PHP version, where you must create a path ''C:\OpenLDAP\sysconf''. In this path create a file called "ldap.conf" with content:

TLS_REQCERT never.

Now you should be able to use '''ldaps://''' when connecting to MS-AD.

==Appendices==

===Child Domains and the Global Catalog in MS Active Directory===

Moodle currently only has limited support for multiple domain controllers; specifically it expects each of the LDAP servers listed to contain identical sets of information. If you have users in multiple domains this presents an issue. One solution when working with MS-AD is to use the Global Catalog. The Global Catalog is designed to be a read-only, partial representation of an entire MS-AD forest, designed for searching the entire directory when the domain of the required object is not known.

For example your organisation has a main domain example.org, staff and students are contained in two child domains staff.example.org and students.example.org. The 3 domains (example.org, staff.example.org and students.example.org) each have a domain controller (dc01, dc02 and dc03 respectively.) Each domain controller contains a full, writable, representation of only the objects that belong to its domain. However, assuming that the Global Catalog has been enabled (see below) on one of the domain controllers (for example dc01) a query to the Global Catalog would reveal matching objects from all three domains. The Global Catalog is automatically maintained through replication across the active directory forest, it can also be enabled on multiple servers (if, for example, you need redundancy / load balancing.)

To make use of this in Moodle to allow logins from multiple domains is simple. The Global Catalog runs on port 3268 as opposed to 389 for standard LDAP queries. As a result, still assuming the Global Catalog is running on dc01, the ''''ldap_host_url'''' would be ''ldap://dc01.example.org:3268''. The rest of the settings are the same as for other MS-AS Auth setups.

You should use the ''''ldap_contexts'''' setting to indicate the locations of individuals you wish to grant access. To extend the example above a little: In the example.org domain users are all in the'' 'Users' ''OU, in the staff.example.org domain users are in two OUs at the root of the domain,'' 'Support Staff' ''and'' 'Teaching Staff' '', and in the students.example.org domain students are in an OU indicating the year that they enrolled, all of which are under the'' 'Students' ''OU. As a result our ''''ldap_contexts'''' setting may look a little like this:'' 'OU=Users,DC=example,DC=org; OU=Support Staff,DC=staff,DC=example,DC=org; OU=Teaching Staff,DC=staff,DC=example,DC=org; OU=Students,DC=students,DC=example,DC=org''.' The ''''ldap_search_sub'''' option should be set to'' 'Yes' ''to allow moodle to search within the child OUs.

Its worth noting that the Global Catalog only contains a partial representation of the attributes of each object, as defined in the Partial Attribute Set supplied by Microsoft. However common information likely to be of use to a general Moodle installation (Forename, Surname, Email Address, sAMAccountName etc) is included in the set. For specific needs the schema can be altered to remove or add various attributes.

In most cases the Global Catalog is read-only, update queries must be made over the standard LDAP ports to the domain controller that holds the object in question (in our example, updating a student's details would require an LDAP query to the students.example.org domain controller - dc03, it would not be possible to update details by querying the Global Catalog.) The exception to this would be in an environment where there is only a single domain in the active directory forest; in this case the Global Catalog holds a writable full set of attributes for each object in the domain. However, for the purposes of Moodle authorisation, there would be no need to use the Global Catalog in this case.

====Enabling the Global Catalog====

The Global Catalog is available on Windows 2000 and Windows 2003 Active Directory servers. To enable, open the ‘Active Directory Sites and Services’ MMC (Microsoft Management Console) snap-in. Extend ‘Sites’ and then the name of the Site containing the active directory forest you wish to use. Expand the server you wish to enable the Global Catalog on, right click ‘NTDS settings’ and select the ‘Properties’ tab. To enable, simply click the ‘Global Catalog’ checkbox. Under a Windows 2000 server it is necessary to restart the server (although it won’t prompt you to); under Windows 2003 server it is not necessary to restart the server. In either case you will generally have to wait for the AD forest to replicate before the Global Catalog offers a representation of the entire AD forest. Changes made in Active Directory will also be subject to a short delay due to the latency involved with replication. If your AD servers are firewalled port 3268 will need to be opened for Global Catalog servers.
If your organisation uses Microsoft Exchange then it its highly likely that at least one Domain Controller will already have Global Catalog enabled – Exchange 2000 and 2003 rely on the Global Catalog for address information, users also access the Global Catalog when using the GAL (Global Address List)

==See also==

*[http://moodle.org/mod/forum/view.php?id=42 Using Moodle: User authentication] forum
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=32168 PHP LDAP module does not seem to be present] forum discussion
* [[LDAP enrolment]]

[[Category:Administrator]]
[[Category:Authentication]]

Category:Administrator

2006-06-29T20:22:01Z

Nenashev:

An index of documentation pages for '''administrators'''.

[[es:Categoría:Administrador]]
[[ru:Категория:Администратору]]

Development:Roles

2006-06-29T08:53:57Z

Nenashev:

'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.

''Please note that none of the following is finalised.''

==Definitions==

By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.

A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.

==The existing system==

Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.

==The new roles and capability system==

The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role.

To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.

''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''

==The plan==

There are a few major things that need to be done. Here's a list (in no particular order):

#Identify permissions required for site/course/each module.
#Define the database structure for storing roles and capabilities.
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?
#Consider interface issues, especially how to manage conflicting role/exception rules.
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?
#Consider the impact on backup/restore.
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.

==Capabilities==

This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?

What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)

Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.

Do we need to add canview and cansearch logs at site/course/user/group level?

I could use a canview at a course level, if I understand what that means exactly.--[[User:N Hansen|N Hansen]] 19:43, 12 June 2006 (WST)

===Site-level Capabilities===

#canconfigsitevariables - applcialbe in admin/config.php
#canreadblogs
#canpostblogs
#candeleteallblogs
#canbrowseuser
#canviewhiddenactivity
#cancreatecourse
#caneditownprofile
#caneditallprofiles

===Course-level Capabilities===

#viewcoursecontent
#caneditcourse
#cancreatebackups
#canrestorebackups
#cancreateblocks
#caneditblocks
#candeleteblocks

===Module-level Capabilities===

#Assignment
##assignment_read - reading the assignment description
##assignment_mark - marking, viewing of list of submitted assignments
#Chat
##chat_chat - allows a user to participate in this chat
##chat_readlog - allows a user to read past chat session logs
##chat_deletelog - allows a user to delete past chat logs
#Choice
##choice_choose - make a choice
##choice_readresponses - read all responses
##choice_deleteresponses - deletes all responses
#Database
##data_readentry - reads other people's entry
##data_writeentry - add / edit and delete (own) entries
##data_managetemplates - add, delete, edit fields and templates
##data_manageentries - edit/delete all entry
##data_comment - comment
##data_managecomment - edit/delete all comments
##data_rate - rate an entry
##data_approve - approves an entry
##data_uploadentries - batch upload of entries
#Exercise
##exercise_canadd
##exercise_canedit
##exercise_candelete
##exercise_canassess
#Forum
##forum_canadd
##forum_canedit
##forum_candelete
##forum_canreadpost
##forum_canstartnewdiscussion
##forum_canreply
##forum_caneditallpost
##forum_candeleteallpost
##forum_canrate
#Glossary
##glossary_read - view entries
##glossary_write - add entries
##glossary_manageentries - add, edit, delete entries
##glossary_managecat - create, delete, edit categories
##glossary_comment - comment on an entry
##glossary_managecomments - edit, delete comments
##glossary_import - import glossaries
##glossary_export - export glossaries
##glossary_approve - approve glossaries
##glossary_rate - rates glossary
##glossary_readrate - view rating?
#Hotpot
##hotpot_candd
##hotpot_canedit
##hotpot_candelete
##hotpot_canparticipate
#Label
#Lams
##lams_canadd
##lams_canedit
##lams_candelete
#Lesson
##lesson_canadd
##lesson_canedit
##lesson_candelete
##lesson_canparticipate
#Quiz
##quiz_canadd
##quiz_canedit
##quiz_candelete
##quiz_canaddquestion
##quiz_caneditquestion
##quiz_candeletequestion
##quiz_canparticipate
##quiz_cangrade
#Resource
##resource_canadd
##resource_canedit
##resource_candelete
#Scorm
##scorm_canadd
##scorm_canedit
##socrm_candelete
#Survey
##survey_canadd
##survey_canedit
##survey_candelete
##survey_canviewresponses
#Wiki
##wiki_canadd
##wiki_canedit
##wiki_candelete
##wiki_canstartnewwiki
##wiki_canparticipate
#Workshop
##workshop_canadd
##workshop_canedit
##workshop_candelete
##workshop_cangrade
##workshop_canparticipate

==Scenarios==

This section is for brainstorming some example roles that we would like to support:

===Student===
Has this one been missed?

===Site Designers===
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

===Educational Authority Adviser===
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

===Educational Inspector===
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

===Second Marker / Moderator===
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

===External Examiner===
Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

===Parent===
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.

In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.

Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

===Manager===
''Please add text here...''

===Weekly Seminar Leader===
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''

===Mentor/Mentee===
''Please add text here...''

===Community-Designed Rating Criteria===
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''

===Visitor===

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

===Former Student===
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Librarian===

Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

===Teacher===

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)

===Community Education Tutors/Trainers===
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

===Secretary/Student Worker===

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

===Teaching Assistant===

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

===Admin - Catgory based===

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

===PROCESS ROLES===

organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:
<li>1. Give a student the role of forum-moderator with edit and chunk-rights
<li>2. Give students different roles & rights in a Webquest design (and change these roles next week
<li>3. Give students different resources, depending of their roles in a rolegame/simulation
<li>4. Give a student the rights to create the section content of next week (and only that week..)
<li>5. ..

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

[[Category:Developer]]
[[Category:Future]]

[[ru:Роли]]

User:Nashev

2006-06-20T22:27:59Z

Nenashev:

Russian developer

[http://moodle.org/user/view.php?id=26945&course=1 Nashev @ moodle site]

[[ru:User:Ne Nashev]]

Development:UTF-8 scripts

2006-03-29T05:53:11Z

Nenashev: possible solution for glossary letter-index

[[UTF-8 migration]] > Recoding PHP scripts

==Recoding PHP scripts==

=== Introduction ===

This page will show a list of well known UTF-8 related modifications to be applied to 1.6 in order to work better under Unicode. Some of the changes can be applied always while others would break compatibility with non UTF-8 sites so they have to be executed conditionally, i.e:
if (!empty($CFG->unicodedb)) {
//Code to be executed in UTF8 mode
} else {
//Old code
}

For each modification we'll show if it's executed always or conditionally, using the "'''A'''" and "'''C'''" abbreviation. Also, the current status will be maintained with "'''N'''"ot implemented, "'''W'''"ork in progress and "'''D'''"one. Obviously, "'''D'''" is the desired final status for all the modifications.

Finally, please, you are welcome to add new items to the list, thanks!, but do it at the end (to maintain its current numeration).

=== The List ===

# (D,A) Build one "check for 1.6 upgrade" utility under 1.5. Now it's present in the admin page. It's able to check for BD, PHP and PHP libraries, allowing function execution and built over the new [http://cvs.sourceforge.net/viewcvs.py/moodle/moodle/lib/environmentlib.php?rev=1.11&view=log environmentlib.php] script. All the checks are defined under one simple XML file and one mechanism to update it from http://download.moodle.org has been provided (using the new [http://cvs.sourceforge.net/viewcvs.py/moodle/moodle/lib/componentlib.class.php?rev=1.4&view=log componentlib.class.php] library.
# (N, C) datalib.php to support collations under MySQL. This will allow to control language specific ordering from Moodle but 1.6.0 won't offer support for it. Instead, MySQL table/filed collation can be altered "manually" if the default unicode collation isn't enough.
# (D,A) textlib.class to handle all those utf-compliant functions. It's working since 1.5.3. Based (wrapper) on [http://typo3.org/ Typo3] text handling libraries it offers support for conversion between charsets and a buch of functions like (substr, strtoupper, strpos...).
# (D,C) XML import/export (scorm, ims, backup/restore, glossary, quizzes...). Under UTF-8 mode, both utf8_encode() and utf8_decode() won't be needed anymore.
# (D,A) Excel Export: A new [http://cvs.sourceforge.net/viewcvs.py/moodle/moodle/lib/excellib.class.php?rev=1.2&view=log excellib.class.php] class wrapper has been built. It works with some [http://pear.php.net/ PEAR] libraries to be able to create UTF-16LE Excel files properly.
# (D,A) Modify every Excel generator to use the new library. This includes: grade/lib.php, course/grades.php, choice/report.php hotpot/report/default.php, quiz/report/analysis.php, quiz/report/overview.php, quiz/report/responses.ph and survey/download.php
# (D,A) Fixed the break_up_long_words() to work using the textlib functions.
# (W,A) Fixed the glossary to find properly the pivot (initial letter) under UTF8 (Skodak has some ideas here about the alphabet for each lang.)
# (D,A) Modify the rss_title() function to support UTF8 chars.
# (W,A) htmlentities() to s() migration everywhere.
# (W,A) uses of substr, strlen, strpos, strtoupper... to use the new textlib class that offers utf8 savvy string manipulation functions.
# (N,A) Modify documentation to let users know how they MUST create their DB before installing Moodle 1.6 explaining all the benefits for being UTF-8 enabled sice the beginning.
# (D,A) Modify the central installation script to:
#* Check DB encoding, warning if unicode hasn't been detected.
#* Execute the environmental checks.
# (D,A) Modify the Windows32 Complete Package installation script to:
#* Force DB creation under UTF-8.
#* Execute the environmental checks.
# (D,A) The wiki module - this is due to the use of htmlentities() without specifying the character set. DFWiki does not have any known problems apparently.
# (D,A) UTF-8 national chars could not be used in paths/foldernames. Unicode characters in filenames can now be enabled by setting $CFG->unicodecleanfilename=true in config.php, though this option is not recommended. Please note that unicode characters in filenames may be broken during zip/unzip process, native info-zip binaries do not work at all on Windows; please use internal zipping/unzipping.
# (N,A) GD support for UTF-8 strings. Perhaps it'll require some hacking + new fonts to be added (centrally or inside each lang pack).
# (D,C) RSS block. Working fine now with the new texlib.class.php library.
# (D,A) Languages list issues, not showing properly lang names. Not action required because now all those names are UTF-8 and they should work properly. I think it's an browser/font issue.
# (D,C) The Assingment module says that 0 words under some languages without word separators. A new configuration option has been added to count letters instead of words.
# (D,C) Modify the email_to_user() function to enable encoding of mails based on site setting and/or user preference. This is a must because a lot of mail clients/widgets don't support UTF-8 encodings. Done (email encoding now can be specified at site and user level plus support any charset (header + body).
# (N,C) Look for all the occurrences of "en" or 'en' is source code and change them to 'en_utf8' is necessary.
# (W,A) New lang edition interface for utf_8 lang packs. It should support dataroot lang packs, use 'en_utf8' as master language and "lock" the new langconfig.php file.
# (W,C) DB Migration with this functionalities:
#* Convert all the users/courses/site languages to their new alternative.
#* Recover from crash smoothly.
#* Handle and central tables and official modules. Contrib modules should implement their own script. See [[UTF-8 contrib]] for more info.
# (N,C) Modify the document_file() function to work properly (links to docs.moodle.org)
# (N,C) Modify the footer output to allow it to go to the proper (en, es...) wiki page in https://docs.moodle.org. A list of available languages can be harcoded, defaulting to en.
# (D,C) Review the RSS feeds creator to detect if conversion to UTF-8 is needed.
# (D,C) Analyse if we need the $SESSION->encoding. Removed from main CVS, 3rd party plugins must be updated anyway to use curent_curset() and $CFG->unicodedb to be fully utf8 and 1.6 compatible.
# (D,A) Delete all the get/print_string('thisencoding') and change them to the new current_charset() function.Seems finished.
# (D,C) Analyse and, if possible, implement a bit improved moodle_setlocale() function because of [[Table of locales|differences between Unix locales and Win32 locales]]. They should go to a new string inside each langconfig.php file and, after OS detection use the correct one. Done, 95% of Windows langs will work.
# (W,C) Implement one PEAR download utility if finally we cannot add it to standard distro (it's ready since some time ago under http://download.moodle.org/pear). Needed to generate Excel files and, potentially, it'll grow. Add it to credits.
# (D,C) Handling of passwords. After DB conversion, password hashes are updated to utf8 during next user login. First is tried hash of unicode plain text password, then the plain text is converted into 'oldcharset' defined in the new language pack and its hash is checked again.
# (D,A) Modify (and potentially upgrade) the MyPHPAdmin module in order to recognise new lang pack names. Done: just support to utf8 langs added.
# (N,C) Add one new parameter (xxx_original_encoding) to authentication methods in order to be able to convert from external sources (ldap, db...) encoding to utf8 if Moodle is running in that mode avoiding the current utf8_decode() implemented.
# (D,A) Modify the install.php script to be able to detect DB encoding and warn about it plus use the new environment stuff to perform tests.
# (D,A) Create a collection of '''installer.php''' (to avoid conflicts with old install.php) files to be stored under the install/lang directory and to be used exclusively in the installation process. Hack get_string() to support this files ONLY in installation and make a script to be able to build them daily from contents existing in other language files (i.e, no manual handling of them!). Also, perhaps, add the possibility of language download at the end of the installation script.

== Patches reference ==

Post here all the solutions you know if you consider that they'll be interesting to solve some of the pending items in the list above.
----
Patches to allow Japanese Language Moodles that function without garbling have been prepared and are available at at the following sites.

These patches are explained here
http://moodle.org/mod/forum/discuss.php?d=13558

Mr. Kashiwagi's "Supertak" Patch (described in the thread above)
http://www.supertak.com/down/sample.htm

Prof Kita's patches and rpms (based in part on Mr. Kashiwagi's)
http://t-kita.net/rpm/FC/moodle/ A read me file in English describing the rpm
http://t-kita.net/rpm/moodle/README-rpm-en.txt
A patch describing all the things that need to be done
http://t-kita.net/rpm/FC/moodle/patches/moodle-t-kita.patch
Many, or even most end-users (including myself = Tim) are not sufficiently confident making extensive patches, so our Moodles have been garbling in important areas (email/excel).

One interesting PHP-UTF8 reference: http://www.phpwact.org/php/i18n/utf-8#mail_functions

For item #8: may be for letter-index use "distinct" first letters from existing data, and not lang alphabet? it can help in multilanguage glossary... --[[User:Ne Nashev|Ne Nashev]] 13:53, 29 March 2006 (WST)

[[Category:Developer]]
[[Category:UTF-8|Scripts]]

Development:UTF-8 problems

2006-03-25T23:41:10Z

Nenashev: added one possible solution for password convertation problem

[[UTF-8 migration]] > Problems

==Problems (and solutions!)==

* Password field(s) can be encoded in anything, and it is encrypted using a one way md5 hash. This means that we can not reverse the md5, thus if a string was encoded in an arbitrary language, we can not do the proper DB migration for that. Possible solutions:
**auto generate new password and send to all users?
**add to passwords one more field - like "original password encoding", fill it while upgrading, and then at user loging in, before compare with hash make translation of entered password to login's original password encoding (by engine like iconv). Upgrade system may time to time perform check, and when all "original encoding" become to UTF-8 - can remove this column and related code. This will be long but soft convertation life...--[[User:Ne Nashev|Ne Nashev]] 07:41, 26 March 2006 (WST)
* Exercise - password - md5
* Lesson, lesson_default - password - md5
* Workshop - password - md5
* Quiz module, the use of field "uniqueid" in attempts - uniqueid is used to link to quiz_states table which is in turn linked to many quiz tables. dev - linked using uniqueid? stable - linked using id??
* Locales: What happens with locales once we have converted lang packs. Currently the process is adding the .UTF-8 suffix to them, but is this the best solution. Would be better to add support for one windows locale and other unix locale? Uhm...

[[Category:Developer]]
[[Category:UTF-8|Problems]]

Forum activity

2006-03-25T23:28:58Z

Nenashev: added link to Forum_development into see also section

{{Forums}}

This activity can be the most important – it is here that most discussion takes place. Forums may be structured in different ways, and can include peer rating of each posting. Generally, forum postings may be edited up to 30 minutes after posting. The postings can be viewed in a variety for formats, and can include attachments. By subscribing to a forum, participants will receive copies of each new posting in their email. A teacher can impose subscription on everyone if they want to.

Forums are divided into two main categories:

# '''General forums''' (found in section 0 of the course)
# '''Learning forums''' (the forums of the specific parts of the course: they are organized and numbered according to the course sections they appear in).

Forums are organised under following headings:

# '''Forum''' (the name of the forum)
# '''Description'''
# '''Discussions''' (the number of discussions started)
# '''Unread posts''' (the number of posts you have not read yet)
# '''Track''' (the 'yes/no' information about your choice whether or not track the unread posts - if your choice is negative, you will find an '-' sign instead of the number of the posts unread)
# '''Subscribed''' (the 'yes/no' information about your choice whether or not get the posts transferred to your mail box)
# '''RSS''' (the 'RSS' (Really Simple Syndication) button - please refer to [[RSS in Forums|RSS in forums]] for additional information

== See also ==

*[http://download.moodle.org/docs/using_moodle/ch4_forums.pdf Using Moodle Chapter 4: Using Forums, Chats and Dialogues]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=5367 The philosophy underlying "no editing after 30 minutes"] forum discussion
*[[Forum development]]

[[Category:Teacher]]
[[Category:Forum]]

[[es:Foros]]

User:Ne Nashev

2006-03-15T10:41:42Z

Nenashev:

#REDIRECT [[user:Nashev]]