MoodleDocs - User contributions [en]

Password salting

2013-05-13T18:31:26Z

Hchathi: /* What is password salting? */

{{Security}}
==What is password salting?==

Passwords are stored in Moodle in a hashed form. Previously MD5 hashing was used, however in Moodle 2.5 onwards, new passwords are hashed using bcrypt.

[http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Password salting] is a way of making password hashing more secure by adding a random string of characters to passwords before their hash is calculated, which makes them harder to reverse (the longer the random string, the harder you make it).

==Enabling password salting==

To set a password salt, add the following line to your [[Configuration file|config.php file]]:

$CFG->passwordsaltmain = 'some long random string here with lots of characters';

The random string of characters should be a mix of letters, numbers and other characters. The [http://dev.moodle.org/gensalt.php Moodle Salt Generator] may be used to obtain a suitable long random string. A string length of at least 40 characters is recommended.

''Note'': For security reasons the only way to enable password salting is by editing config.php - there is no way to do so in the Moodle interface.

''Tip'': Keep a note of your password salt somewhere other than config.php to prevent the situation of your password salt being lost and all site users having to go through password recovery to reset their passwords.

==Changing the salt==

If for any reason you wish to change the salt, the old salt must be retained in config.php in addition to the new salt.

<code>passwordsaltmain</code> should be changed to <code>passwordsaltalt1</code> (note that the exact expressions must be used) for the old salt as follows:

$CFG->passwordsaltalt1 = 'old long random string';
$CFG->passwordsaltmain = 'new long random string';

If you change your salt again in the future, you must retain all the previous salts for some time (until every user has logged in at least once, so they start using the new salt). You can use $CFG->passwordsaltalt2, $CFG->passwordsaltalt3, etc. to keep up to 20 previous salts.

''Warning: If you change the salt and do not retain the old one in config.php you will no longer be able to login to your site!''

==Disabling password salting==

'''Note''': Not Recommended! Once enabled, you should leave password salt enabled.

To disable password salting in Moodle, you can delete, comment out, or change the value of passwordsaltmain to "empty"

// EXAMPLE: set to empty string
$CFG->passwordsaltmain = <nowiki>''</nowiki>;

// EXAMPLE: comment out
/*
$CFG->passwordsaltmain = <nowiki>''</nowiki>;
*/

However, you are not done! You '''must also move the old salt to an "alt" value''', just like the "changing the salt" description, above:

$CFG->passwordsaltalt1 = 'old long random string';
$CFG->passwordsaltmain = <nowiki>''</nowiki>;

==Importing users from another site==

If you import users from another Moodle site which uses a password salt, you need to add the other site's salt to config.php too. Upto 20 alternate salts may be added

$CFG->passwordsaltalt1, $CFG->passwordsaltalt2, ... $CFG->passwordsaltalt20

==How does password salting work?==

When a password is checked, the code looks for <code>CFG->passwordsaltmain</code>. If set, salt is appended to user's password before calculating the hash.

If the unsalted hash of a user's password validates, it is assumed that the salt was set for the first time since the last time the user logged in. The user's password is upgraded, using the salt. '''The password is salted during the first login after the salt was set in config.php.'''

If neither the unsalted hash, or the salted hash validates, the code looks for up to 20 alternate salts.

If you change salts, in order not to orphan existing user accounts, you must enter the old salt into one of the alternate slots.

When a user who has an "old salt" password logs in, the first test of their authentication with the new salt will fail... then the code will test any alternate salts, looking for one that allows the password to be proven valid.

If a user is deemed valid, the system will upgrade the user's hashed password to the latest salt.

[[cs:Solení hesel]]
[[de:Kennwortverschlüsselung (Salt)]]
[[es:report/security/report_security_check_passwordsaltmain]]
[[fr:Salage de mot de passe]]
[[it:report/security/report_security_check_passwordsaltmain]]
[[nl:report/security/report_security_check_passwordsaltmain]]
[[ja:パスワードSALT]]
[[ru:Зашумление паролей]]

Development talk:Modules and plugins replacement proposal

2011-03-22T14:50:16Z

Hchathi: /* Comments */ new section

Some minor suggestions from Tim (so much for the request not to comment yet):

* This may be a version 2.0 feature, but simple links from the database entries to the place on AMOS where people need to go to translate this plugin, and back again.
* In terms of which version of core Moodle the plugins works with, there are big advantages if this information can remain in version.php, where it is readable by the Moodle install code. The MnP database could automatically read the data out of there to display on the web, like AMOS gets strings out of version control.

In the database schema:
* Rather than separate local_contrib_plugin_contributor.creator/active columns, would it be better to have a single contributortype column? Easier to extend in future.
* Should userid be in local_contrib_review or local_contrib_review_outcome?
* If there a good reason for using 'softwareversion' in names? moodleversion would make it clearer. Of course, that is less generic.
* should local_contrib_review_outcomes have a machine-readable column that holds a status like pass/fail, as well as the text in review?
* Do you really need hierarchical categories. They are a pain in SQL, and they add UI complexity. I think one-level categories may be fine, particularly if you have tags as well.

In terms of display, it would be nice if you could use group icons from using Moodle (like core-developer, Partner, PHM) when displaying users. It would be useful if people could see that a review was by a core developer.

I had not realised that the file API did not support local plugins. See https://github.com/moodle/moodle/blob/master/pluginfile.php#L738

Would a capability like "new entries from this user approved automatically" and "new versions from this user approved automatically" be worthwhile? I believe the current system overloads the approve capability for this, which causes pain.

--[[User:Tim Hunt|Tim Hunt]] 09:17, 12 January 2011 (UTC)

Hi Tim,
Thanks for the early feedback, all good suggestions/observations.
In response to the points you have raised:
* AMOS links make VERY good sense and I'm sure I'll be able to easily fit them in.
* Good suggestion, I still have to talk to Martin about how things will be stored, however where practical if possible it would be great if we could utilise version.php
* Interesting idea, I had separated the two as the creator may no longer be active (passed the responsibility onto others). Perhaps if active is made contributortype that would allow us to extend in the future (primary or owner being an obvious extension).
* userid I think should be local_contrib_review, there will be a record created there for each individual review which will consist of the general review stored within that record, and then several criteria reviews stored in local_contrib_review_outcome. Does that make sense? Remembering of course this is all very fresh and it may be me misunderstanding something here.
* Yes, softwareversion isn't the greatest I did refrain from calling it moodleversion to keep the project more easily diversable, however I have yet to talk to Martin about that prospect... not too sure what he will want but I'll leave that one up to him.
* In regards to local_contrib_review_outcome I was intending to you the core rating system for that, however it would require core changes presently. If the rating system isn't used then it will certainly need that column. Also I will have to at some point consider performance, I haven't looked at the ratings internal but if it isn't joinable in a friendly way then it may be worth duplicating that information in the local_contrib_review_outcome table for quicker lookups.
* Group icons === awesome idea which I will be sure to work in.
* Haha quite right it does support files, I've updated the doc now. I had given it a quick glance and misread the above else thinking anything with an underscore entered there..... just another reason I should read more carefully. Thanks for pointing that out.
* Yes to both the capability suggestions, there had been talk about automating that some how and capabilities for it would be perfect.

Again thank you, I'll amend the rest of the doc shortly.

Cheers

--[[User:Sam Hemelryk|Sam Hemelryk]] 09:48, 12 January 2011 (UTC)

== Initial comments from David ==

* overall - sounds good! :-)
* re links to AMOS - easy to implement now as AMOS already supports permalinks to its filter so it is easy to construct URL that leads the user directly to a page where a given component on a given branch is translated
* what I miss in the document is a mention of some webservices support. We will either need webservice layer or maybe better just a script that generates plugins info into a big XML file. Such file will describe all the plugins and the location of their sources. This file will be then fetch regularly by Moodle sites' plugin_manager that will allow remote update/installation via the web. I am willing to work on this part once we branch MOODLE_20_STABLE, though there is no spec yet, sorry. The goal is to allow simple installations of extensions from the Moodle admin interface - similarly to what Wordpress does
* that XML file would be used by AMOS, too, so that it knows what plugins and their branches it should track

--[[User:David Mudrak|David Mudrak]] 10:57, 12 January 2011 (UTC)

Hi David

Thanks for looking it over and having a think about it. I've been working on the proposal again today and building it up more and more.

In reply to your points:

* Awesome that AMOS has a predictable link structure, it certainly will be cool to integrate the two system.
* There is now information about RSS feeds and web services that the new system will be able to process. The idea of having everything available from the admin interface of your Moodle installation is great. I'm not too sure presently what Martins plans for undertaking such work are, however he did ask for it to be provisioned where/if possible within this new system.
* I would like to talk to you at some point after Martin is back to find out how we could best integrate this system with AMOS. It'd be great to see where we could take it and I'm sure you'd have the best idea about what is possible there. I'll get in touch with you after I've talked to Martin and organise a time to discuss it.

Cheers

--[[User:Sam Hemelryk|Sam Hemelryk]] 08:40, 13 January 2011 (UTC)

Why did you just strip local_ from the front of all the table names. I thought that all DB tables were meant to start with the frankenstyle plugin name?--[[User:Tim Hunt|Tim Hunt]] 10:26, 19 January 2011 (UTC)

: Hi Tim, I removed ''local_'' after finding the 28 character table name limit imposed by XMLDB. I choose to remove ''local_'' rather than using cryptic names. --[[User:Sam Hemelryk|Sam Hemelryk]] 06:56, 21 January 2011 (UTC)

:: I know the 28 character table name limit is a pain, but we all have to live with it. I still don't see why you should be able to break the coding guidelines. I was specifying something yesterday, and eventually I was able to find table names that fitted and were sensible.

:: Also, while you claim your table names are non-crypic becuase they are long, actually, while trying to think of better names, I completely misunderstood what the collection thing was about. I thought it was for dealing with the situation where you have, for example, a block and an admin report that, while being separate plugins, rely on each other, so you want to offer them for download as a single package. However, when I read the detail of the document, I find that is wrong. So, collection is not only a long word, it is also ambiguous.

:: Anyway, here are my suggestion to get you within the limit:

:: review_criterion -> review_test. collection -> set (does not really solve the ambiguous naming, but at least is short. I think a significant part of your problem is that this concept overlaps very heavily with tags, but presumably you want tags to be crowd-sourced). Then I would cop out and just use an abbreviation for version, say ver or vers. That solves the rest of your problems.

1234567890123456789012345678
local_contrib_plugin
local_contrib_vers
local_contrib_vers_download
local_contrib_category
local_contrib_contributor
local_contrib_set
local_contrib_set_plugin
local_contrib_software_vers
local_contrib_supported_vers
local_contrib_review
local_contrib_review_test
local_contrib_review_outcome
local_contrib_awards
local_contrib_plugin_awards
1234567890123456789012345678

::I think the best solution to the ambiguity of what some of the table names means is better table comments. At the moment, some of the comments only make sense if you have read the full spec, which will not be try for people who are just looking at the code.--[[User:Tim Hunt|Tim Hunt]] 08:43, 21 January 2011 (UTC)

Hi Tim, thanks for the feedback.

The 28 character table name limit is a bit of a pain, but I do see your point and happy to add ''local_'' back into the mix and refactor the table names as suggested.

Your observations regarding collections are correct, it is very similar to tags however only those with the required capabilities will be able to manage/add to them. The name collections is perhaps a bit vague and as it will be way to long I think using ''set'' instead is a good idea.

I will also go through and revise the table comments :)

Cheers --[[User:Sam Hemelryk|Sam Hemelryk]] 01:41, 24 January 2011 (UTC)

== typo? ==

* ''''Version control systems and downloads''''

With this new system we will start collecting information about the version control system that the contributor is using. We gather this information for each version of a plugin that is created and are able to collect some or all of the following: ''''the new of the vcs system''''...

the new ''what'' of ''what'' system?
--[[User:Joseph Rézeau|Joseph Rézeau]] 17:14, 2 February 2011 (UTC)

Thanks Joseph, I've corrected that now.
It should have read ''some or all of the following: the vcs system (git, cvs, svn, other), ...''
<br />Cheers
<br />--[[User:Sam Hemelryk|Sam Hemelryk]] 03:53, 4 February 2011 (UTC)

== Contrib packages (aka, bundling multiple plugins together) ==

This is just a reminder about the current contrib-packages that we are building since ages ago. Is going to be some way to group different plugins and build one package automatically? I think it can help in a lot of situations. Not critical, but interesting IMO. You can ask Anthony about how that is being handled now and how it could be integrated in the new M&P stuff.

[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 20:29, 2 February 2011 (UTC)

:: Thanks for the reminder Eloy, I had originally talked to Martin about this in the very early discussions about this system but will raise it with him again. It wouldn't be too hard to do something there I'm sure (depending on how far down the rabbit hole we choose to go).
:: --[[User:Sam Hemelryk|Sam Hemelryk]] 03:55, 4 February 2011 (UTC)

== Proposal to change status field in local_contrib_vers ==

Please note that Moodle 2.0 now defines MATURITY_xxx constants in setuplib.php that are used to mark a maturity level of core or a plugin (alpha, beta, rc, stable). I suggest to use these constants instead of a string for the fields 'status' in local_contrib_vers. In the future, plugins are expected to define things like

$module->maturity = MATURITY_STABLE;

in their version.php and this value will be used at the plugins report, too. NULL value means 'unknown'. You may also consider changing the name of the field to 'maturity'.

Alternatively, we could use both. New 'maturity' field for the integer constant value and 'status' for additional comment. --[[User:David Mudrak|David Mudrak]] 09:47, 8 March 2011 (UTC)

== Comments ==

It would be nice if users who aren't logged in could see plugin comments (MDLSITE-1255) --[[User:Hubert Chathi|Hubert Chathi]] 14:50, 22 March 2011 (UTC)

User:Hubert Chathi

2011-03-08T16:40:34Z

Hchathi: New page: See my [http://moodle.org/user/profile.php?id=706541 Moodle profile page] for more information.

See my [http://moodle.org/user/profile.php?id=706541 Moodle profile page] for more information.

Development talk:Scheduled Tasks Proposal

2011-03-08T16:38:47Z

Hchathi:

== Pseudo code proposal ==

''This is just a rough idea to provoke thought:--[[User:Tim Hunt|Tim Hunt]] 11:06, 9 December 2009 (UTC)''

<code php>
<?php
function handle_cron($maxprocesstime) {
$timestart = time();

$runid = cron_record_starting_processing($timenow);

while (($timenow = time()) < $timestart + $maxprocesstime) {
try {
$task = cron_get_next_task($timenow);
cron_acquire_lock($task);
$next = $task->execute($timenow);
cron_record_task_success($task, $next, $timenow);
cron_release_lock($task);

} catch (Exception $e) {
cron_record_task_failure($task, $timenow, $e);
}
}

cron_record_ending_processing($runid, $timenow);
}

/**
* Instances of this class are rows in the scheduled_tasks table.
*/
abstract class scheduled_task {
protected $id;
protected $plugin; // = 'mod_quiz', 'qtype_multichoice'.
protected $function;
protected $lastruntime;
protected $nextscheduledtime;
protected $priority; // LOW, MEDIUM, HIGH, or, a number like nice 19, or something.

protected abstract function get_start_end_times($timenow);

protected abstract function schedule_next($timenow);

public function execute($timenow) {
$file = get_plugin_dir($this->plugin) . '/cron.php';
if (!is_readable($file)) {
throw new cron_exception('required file does not exist.');
}
if (include_once($file)) {
throw new cron_exception('required file could not be included.');
}
list($start, $end) = next_times($timenow);
$this->$function($start, $end);
return $this->schedule_next();
}
}

class one_off_task extends scheduled_task {
protected abstract function get_start_end_times($timenow) {
return array(null, $timenow);
}

protected abstract function schedule_next($timenow) {
return null;
}
}

class catchup_task extends scheduled_task {
protected $desiredinterval; // seconds

protected abstract function get_start_end_times($timenow) {
return array($lastruntime, $timenow);
}

protected abstract function schedule_next($timenow) {
return $timenow + $desiredinterval;
}
}

class every_day_task extends scheduled_task {
protected $swtichovertime; // Seconds after midnight.
protected $runtime; // Seconds after midnight.
// For now this code assumes $runtime > $swtichovertime, but that is just me
// being lazy. It can be fixed.

protected abstract function get_start_end_times($timenow) {
$midnight = get_midnight_before($this->nextscheduledtime);
$previousmidnight = get_previous_midnight($midnight);
$starttime = $previousmidnight + $swtichovertime;
$endtime = $midnight + $swtichovertime;
return array($starttime, $endtime);
}

protected abstract function schedule_next($timenow) {
$midnight = get_midnight_before($this->nextscheduledtime);
$nextmidnight = get_following_midnight($midnight);
return $nextmidnight + $this->runtime;
}
}

class weekly_task extends scheduled_task {
// ...
}

/* Approximate database tables.

scheduled_tasks
id AUTOINCREMENT
type varchar
plugin varchar
function varchar UNIQUE
lastruntime int
nextscheduledtime int
priority int
custom1 int
custom2 int
customextra text

scheduled_task_locks
id int auto
function fk unique
locktime int
*/
</code>

== Proposed database changes ==

We will be implementing a scheduled tasks system in our product, but we need a couple of extra features. In the interest of interoperability and not reinventing cron too many times, here are the features that we need, and the database changes that would be required:
* plugins need to define multiple cron jobs on-the-fly (one of our plugins will allow the user to schedule several tasks with different schedules), and allow plugins to modify those tasks
* ability to specify that a task should run n times, or until [date]

For the first requirement, I'd like to add a taskcode field to the DB, to allow plugins to identify the different tasks that it creates. The callfunction would then be called with taskcode as an argument.

For the second requirement, I think that we can roll the onceoff_tasks table into the main tasks table, and just add extra fields for number of times remaining and/or end date. So onceoff tasks would just be a task with the number of runs remaining set to 1, nextruntime set to the time that it should run, and the cron fields set to (empty? or "*"?). With the taskcode field, we wouldn't need the customdata field -- the task can use the taskcode field to identify the task, and load customdata from its own table.

Here is my proposed table, with changes highlighted:

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|'''taskcode''' (new)
|varchar(50)
|a plugin-specific identifier for the task, used to differentiate between multiple tasks for the same plugin
|-
|callfunction
|varchar(200) <strike>(unique)</strike>
|the function to call. <strike>Must be unique, as it will be used for the locking.</strike>
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|minute
|varchar(25)
|
|-
|hour
|varchar(25)
|
|-
|day
|varchar(25)
|
|-
|month
|varchar(25)
|
|-
|dayofweek
|varchar(25)
|
|-
|'''runsremaining''' (new)
|integer
|Number of times that the task will run
|-
|'''enddate''' (new)
|integer
|Task will not run after this date
|-
|customised
|integer(1)
|0 or 1 - whether this time differs from what is in code
|}

Since we can now have multiple tasks with the same callfunction, we can't enforce that it be unique. So we can either use (taskcode,callfunction) or (plugintype,pluginname,taskcode) as the key for locking.

Also, do we need a field to specify which file the callfunction is in?

--[[User:Hubert Chathi|Hubert Chathi]] 14:45, 8 March 2011 (UTC)

: Looks reasonable. I wonder if taskname would be better than taskcode?--[[User:Tim Hunt|Tim Hunt]] 16:28, 8 March 2011 (UTC)

Yeah, I started with taskname, then thought taskcode might be better. I don't mind either way. --[[User:Hubert Chathi|Hubert Chathi]] 16:38, 8 March 2011 (UTC)

Development talk:Scheduled Tasks Proposal

2011-03-08T16:38:14Z

Hchathi:

2009-10-09T20:40:34Z

Hchathi: /* Why CONTEXT_MYPAGE? */

Development talk:My Moodle 2.0

2009-10-09T20:35:28Z

Hchathi: /* Why CONTEXT_MYPAGE? */

User:Hubert Chathi/Custom Context Levels

2009-09-11T14:51:40Z

Hchathi: New page: == Custom context levels database == For adding custom context levels, rather than trying to assign level numbers and hoping to not have collisions, I propose that we add a database table ...

== Custom context levels database ==
For adding custom context levels, rather than trying to assign level numbers and hoping to not have collisions, I propose that we add a database table to map a context level name to the context level number. If we allow various plugins to define context levels, then we can create a table (which I've called mdl_context_levels) that has the following fields:
* id - the standard record ID
* name (VARCHAR(255?)) - the name of the context level
* component (VARCHAR(255?)) - the name and type of the component that defined the context level

The context level number would be id + 1000 (or another sufficiently large number to guarantee that we won't collide with any Moodle context levels). So if my block "foo" defines the custom context level "bar", then its context level number would be get_field('context_levels', 'id', 'name', 'bar', 'component', 'block_foo')+1000.

Building on the patch that I've already uploaded to MDL-20045, I would then add some methods to context_level_base to get the custom context levels (draft -- not finalized):

<code php>
private static $customctxlevels;

private static function load_custom_context_levels() {
if (!isset(context_level_base::$customctxlevels)) {
$ctxlevel = get_records('context_levels');
context_level_base::$customctxlevels = array();
foreach($ctxlevel as $rec) {
context_level_base::$customctxlevels[$rec->component][$rec->name] = $rec->id + 1000;
}
}
}

static function get_custom_context_level($name, $component) {
context_level_base::load_custom_context_levels();

return context_level_base::$customctxlevels[$component][$name];
}
</code>

This provides an API to look up the context level number for a custom context level.

I would also add the following code to the get_all_contexts method:
<code php>
// find all the components that have defined context levels
context_level_base::load_custom_context_levels();
$components = array();
foreach (array_keys(context_level_base::$customctxlevels) as $component) {
require (get_component_directory($component).'/db/access.php');
foreach (${$component.'_contextlevels'} as $name=>$object) {
$contextlevel = context_level_base::get_custom_context_level($name, $component);
context_level_base::$allcontextlevels[$contextlevel] = $object;
$object->level = $contextlevel;
}
}
</code>

(see below for how {component}/db/access.php is used)

== Adding records to context_levels table ==

In addition to this, we would need code to create the records in the context_levels table. My prototype code uses a new variable in the {component}/db/access.php file (currently used to define custom capabilities). e.g., in my blocks/foo/db/access.php file, I would have a variable: "block_foo_contextlevels = array('bar' => new context_level_foo_bar());" (where context_level_foo_bar is a subclass of context_level_base).

The code for loading the custom context levels:
<code php>
/**
* Loads the context level definitions for the component (from file). If no
* context levels are defined for the component, we simply return an empty
* array.
* @param string $component - examples: 'moodle', 'mod_forum', 'block_quiz_results'
* @return array array of contexts levels
*/
function load_context_level_def($component='moodle') {
$defpath = get_component_directory($component).'/db/access.php';

$contexts = array();
if (file_exists($defpath)) {
require($defpath);
if (isset(${$component.'_contextlevels'})) {
$contexts = array_keys(${$component.'_contextlevels'});
}
}

return $contexts;
}
</code>

And I've added code to the update_capabilities function:
<code php>
$filectxlvl = load_context_level_def($component);
$strcomp = str_replace('/','_',$component);
$oldctxlvl = get_records('context_levels', 'component', $strcomp, '', 'name');
foreach ($filectxlvl as $contextlevel) {
if (!isset($oldctxlvl[$contextlevel])) {
$level = new object;
$level->name = $contextlevel;
$level->component = $strcomp;

if (!insert_record('context_levels', $level, false, 'id')) {
return false;
}
}
}
// FIXME: remove old context levels
// what needs to be cleaned up?
// - contexts (and kill all sub-contexts?)
// - role assignments
</code>

curriculum mapping

2009-02-10T19:04:50Z

Hchathi: /* What is curriculum mapping? */ Add more details about what it is

== What is curriculum mapping? ==
"Curriculum mapping" is a tool that many schools are using to record class curriculum. It is (real-time) record of what is being taught and how it is being taught. Curriculum maps can be used to, for example, figure out if students were introduced to material that they should have been in previous terms, or for parents to see what is happening in the classroom.

*[http://en.wikipedia.org/wiki/Curriculum_mapping Wikipedia article]

'''This page, at this time, is just a "stub" that others can add to as we brainstorm what we would like Moodle to do.'''

== A Moodle Curriculum Mapping component? ==
There is currently no component for Moodle designed for curriculum mapping. This page is dedicated towards spawning the development of such a component.

== Basic roles of a Moodle curriculum mapping component ==
'''Note: Not all teachers who are mapping will be using Moodle for their courses.''' Also, it is important that the curriculum mapping module be accessible to teachers and administrators other than the teacher whose course is being mapped.

=== Components for teacher input ===
* Allow teachers to enter brief descriptions of each unit of their class.
* A field for keywords (probably linked from a set of standard keywords).
* The ability to include the approximate time duration of the unit.
* The ability to check off which of the required "state standards" (a list provided by the school/government of the curriculum to be covered by the course).
* The ability to enter the grade level of the class, and multiple grade levels for some classes.

=== Search components ===
* The ability for an administrator or parent to see "what should Janie be learning now in her [input subject] class?
* The ability for a teacher to ask "what classes besides mine are covering [input keyword/topic]?

=== Components for reports ===
* The ability to generate a calendared report of topics covered.

=== Back-end requirements ===
* The ability to import "state standards" (a list provided by the school/government of the curriculum to be covered by the course).

== Commercial Curriculum Mapping services ==
* [http://www.rubicon.com/AtlasCurriculumMapping.html Atlas Curriculum Mapping]

MNet FAQ

2008-12-12T14:18:59Z

Hchathi: added note about not working on lighttpd

{{stub}}==What is MNET?==

MNET is the mechanism in Moodle for connecting to other Moodle (or Mahara) sites. It's short for "Moodle Network". See [[Moodle Network]] for more information.

==It doesn't work. What do I do now?==

Always make sure you have the latest version possible of Moodle. There have been a lot of fixes. Then make sure that you have debugging turned on (Site Administration > Server > Debugging). This will greatly increase the chance of the underlying problem being reported.

Note that MNET currently does not currently work on lighttpd. (MDL-14638) This should be fixed in lighttpd 1.5 when it is released.

==See also==

* Using Moodle [http://moodle.org/mod/forum/view.php?id=6976 Moodle Network forum]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=105301 Overview of public key] forum discussion

[[Category:MNET]]
[[Category:FAQ]]