MoodleDocs - User contributions [en]

Internal enrolment

2008-12-10T14:00:01Z

Daniss: /* Enforcing enrolment key usage */

Location: Internal enrolment edit settings link in ''Administration > Courses > [[Enrolment plugins|Enrolments]]''

==Self-enrolment==
By default, students can enrol themselves on whatever courses they choose. They do so by clicking on the course name then answering yes to the question "You are about to enrol yourself as a member of this course. Are you sure you wish to do this?" You can restrict users from enrolling on whatever courses they choose by setting an [[Enrolment key|enrolment key]].

A trick to avoid the confirmation message is to make a link to the course with '&confirm=1' on the end after enrol.php e.g. <nowiki>http://moodle.org/course/enrol.php?id=50&confirm=1</nowiki> Which will take you straight to the course page and enrol you transparently.

==Role of key holder==

{{Moodle 1.8}}In Moodle 1.8.3 onwards the role of keyholder may be set. This only affects the screen that students will see when they attempt to enrol on a course where an enrolment key is specified. The screen will list anybody who is assigned to the specified role (in the course context) as contacts to request the enrolment key. If this is not set (the default) or there is nobody assigned to the role in a given course the "old" behaviour is used, which is to display the name of the first person with update privilege for the course.

==Enrolment key hint==

{{Moodle 1.9}}In Moodle 1.9.3 onwards, the enrolment key hint (the first character of the enrolment key) may be disabled by setting ''enrol_manual_showhint'' to No.

==Enforcing enrolment key complexity==

{{Moodle 1.9}}In Moodle 1.9.4 onwards, enrolment key complexity may be enforced according to the site password policy by setting ''enrol_manual_usepasswordpolicy'' to Yes. (The site password policy is set in ''Administration > Security > [[Site policies]]''.)

==Enforcing enrolment key usage==

{{Moodle 1.9}}In Moodle 1.9.4 onwards, the use of enrolment keys in new courses may be enforced by setting ''enrol_manual_requirekey'' to Yes. This will also result in teachers being prevented from removing enrolment keys from existing courses.

[[Category:Enrolment]]

[[fr:Inscription interne]]

Talk:Roadmap

2008-09-01T10:46:21Z

Daniss:

==Minimum PHP requirement==

Moodle 2.0 will require PHP 5.2.4 as a minimum (see: MDL-15410)

==Student Information API for version 2.0==

Also on a related point the student API which is down for version 2.0. Is there any more detail to here on this yet? Will this be part of the IMS Enterprise data model and therefore enrolments plug in or will someone be working on a Moodle SIF agent? In the UK SIF is likely to take off as the DfES via Becta are currently consulting on a UK SIF model and piloting SIF in Birmingham and Northern Ireland. I believe that SIF is used quite widely in the US?

== Wiki engine ==

I noticed there was some talk about making new wiki module for 1.9... what do "nWiki" and "DF wiki" refer to? I've searched online and haven't found a clear description of what these mean. I am curious if they are still based on MediaWiki. I would hate to see some of the great features of MediaWiki (mainly the scalability) be lost. When MediaWiki is configured with Memcached and Squid caching servers, they can serve thousands of requests per second: hard to beat! 
Thanks, 
-[[User:Sean Colombo|Sean Colombo]] 00:12, 13 January 2008 (CST)

None of the wikis are based on Mediawiki. Mediawiki is very difficult to use as a basis for a Moodle wiki, because of all the special features we need. [[User:Martin Dougiamas|Martin Dougiamas]] 22:10, 22 April 2008 (CDT)

== about nwiki ==

Seems that nwiki will be inside for 2.0.
Nwiki IMPLEMENTS the mediawiki markup, and the old features of the current wiki for backwards compatibility... and that is what makes it so difficult. Is really hard.

You migth get by the Using moodle wiki forum and we can discuss about it.
Cheers.
--[[User:Ludo (Marc Alier)|Ludo (Marc Alier)]] 11:14, 13 January 2008 (CST)

== About WS ? ==

Where fit the WS layer in the roadmap?

== IMS LIT 2.0 compliance ? ==

*Wimba is working with IMS to develop an activity module that acts as a consumer of the IMS LTI 2.0 standard...
*We in UPC (dfwikiteam) are working in a way to make the moodle course a IMS LTI 2.0 producer ...
shall this be included somewhere in the roadmap?--[[User:Ludo (Marc Alier)|Ludo (Marc Alier)]] 01:05, 9 April 2008 (CDT)

== Site-wide groups ==
Site-wide (or, preferrable, context-wide) groups is much needed improvement (see votes for MDL-11826), especially in large institutions. Can it be targeted to 2.0?

Yes, it would really help lot of people...
--[[User:Séverin Terrier|Séverin Terrier]] 16:57, 13 May 2008 (CDT)

MDL-15416 seems to have been tagged for 2.0 by Petr :) [[User:Matt Gibson|Matt Gibson]] 10:46, 19 May 2008 (CDT)

==Minted course profile plugin==
This was scheduled for 1.9, but didn't make it. Any plans to include it in 2.0? It seems to have vanished. [[User:Matt Gibson|Matt Gibson]] 10:47, 19 May 2008 (CDT)

== Instructor-led Training Session Management ==

In several of the projects we work on there is a very real need to manage instructor-led sessions by booking training rooms and assigning trainers. I've always felt that Moodle is so advanced in many areas but this is something that is not really catered for. Developing this will mean that Moodle can comfortably handle blended-learning.

There has been some fantastic work done on the Face-to-Face contrib module and the integration of the MRBS module. But in my experience, what's needed is actually a combination of the two systems that integrates to the Moodle calandar and other standard components.

I'd be happy to spec out the requirements and test in real environments.

Craig Meltzer
[http://moodle.org/user/view.php?id=34863&course=1]

==Subscribe at the thread level & Book Module==

I notice in the tracker http://tracker.moodle.org/browse/MDL-1626 there is a request for the ability for notification (subscription) at the thread level, not just the forum level.
It says it is in 2.0 in the tracker.
What does this mean? Is this definite, since it is not mentioned in the roadmap? Is it too ''small'' an enhancement to justify comment in the roadmap? To what level of detail does the roadmap get maintained?

I note there is a request for the book module to be in the core. http://tracker.moodle.org/browse/CONTRIB-283 But it does not have a fix version indicated. Does that mean the request is not considered significant to be included in 2.0?? --[[User:Derek Chirnside|Derek Chirnside]] 02:56, 6 July 2008 (CDT)

==Blog & Comments in 2.0==

This is a similar comment to above. There is a lot of talk about blogs on the various forums here in Moodle.org, and in particular the Moodle implmentation of them.

Particularly here: http://moodle.org/mod/forum/discuss.php?d=94623#p418128 and here: http://moodle.org/mod/forum/discuss.php?d=44830&mode=3

There is an issue tracker here: http://tracker.moodle.org/browse/MDL-8776 but there doesn't seem to be any sort of focus to the discussion in the details. From the roadmap: comments are coming. What about the other suggestions in the tracker? Where do we find out what is coming and what is planned? How are decisions arrived at?

I'm curious about the OU blogs as well. --[[User:Derek Chirnside|Derek Chirnside]] 03:13, 6 July 2008 (CDT)

==No longer called Activitiy locking==

Now called: Conditional activities. I like this terminology change. Activity locking is a little more draconican and control sounding. And there is good reason to avoid the term "Selective Release".

I'd really like it to be very very simple. A linear pathway being easy to construct, with any possible complex stuff hidden in an advanced tab. Most of what the lecturers do here is like that. --[[User:Derek Chirnside|Derek Chirnside]] 03:18, 6 July 2008 (CDT)

Development:lib/formslib.php Validation

2008-05-21T16:27:18Z

Daniss: /* moodleform::validation() */

{{Formslib}}

There are two ways to add validation in the forms lib.

== MoodleQuickForm::addRule() ==

You use this typically inside your moodleform::definition method. For example to set a field as required.

<pre>
$mform->addElement('text','shortname', get_string('shortname'),'maxlength="15" size="10"');
$mform->setHelpButton('shortname', array('courseshortname', get_string('shortname')), true);
$mform->setDefault('shortname', get_string('defaultcourseshortname'));
$mform->addRule('shortname', null, 'required', null, 'client');
$mform->setType('shortname', PARAM_MULTILANG);
</pre>

There is good documentation for this on the [http://pear.php.net/manual/en/package.html.html-quickform.intro-validation.php PEAR web site]

In Moodle formslib you can set certain rules' error message to null and a default error message will automatically be used. The default messages are defined in lang/{language}/form.php. Here are the English definitions :

<pre>
$string['err_alphanumeric']='You must enter only letters or numbers here.';
$string['err_email']='You must enter a valid email address here.';
$string['err_lettersonly']='You must enter only letters here.';
$string['err_maxlength']='You must enter not more than $a->format characters here.';
$string['err_minlength']='You must enter at least $a->format characters here.';
$string['err_nopunctuation']='You must enter no punctuation characters here.';
$string['err_nonzero']='You must enter a number not starting with a 0 here.';
$string['err_numeric']='You must enter a number here.';
$string['err_rangelength']='You must enter between {$a->format[0]} and {$a->format[1]} characters here.';
$string['err_required']='You must supply a value here.';
</pre>

== moodleform::validation() ==

Define a method validation on your moodleform child to make your own custom validation for the form. This is done on the client side. And data_submitted will return null until the function returns no errors. You return an array of errors if there is any error or an empty array if there are no errors.

<pre>
class course_edit_form extends moodleform {

function definition() {
blah blah;
}

/// perform some extra moodle validation
function validation($data) {
$errors= array();
if ($foundcourses = get_records('course', 'shortname', $data['shortname'])) {
if (!empty($data['id'])) {
unset($foundcourses[$data['id']]);
}
if (!empty($foundcourses)) {
foreach ($foundcourses as $foundcourse) {
$foundcoursenames[] = $foundcourse->fullname;
}
$foundcoursenamestring = implode(',', $foundcoursenames);
$errors['shortname']= get_string('shortnametaken', '', $foundcoursenamestring);
}
}

if (empty($data['enrolenddisabled'])){
if ($data['enrolenddate'] <= $data['enrolstartdate']){
$errors['enroldateendgrp'] = get_string('enrolenddaterror');
}
}
return $errors;
}
}
?>
</pre>

{{Moodle 1.9}}There is a new parameter $files in Moodle 1.9, it allows validation of uploaded files too.
<pre>
function validation($data, $files) {
$errors = parent::validation($data, $files);
if (empty($files['userfile'])) {
if (array_key_exists('url', $data)) {
$errors['url'] = get_string('required');
}
}
return $errors;
}
</pre>

Development:lib/formslib.php Validation

2008-05-21T12:41:04Z

Daniss: /* moodleform::validation() */

{{Formslib}}

There are two ways to add validation in the forms lib.

== MoodleQuickForm::addRule() ==

You use this typically inside your moodleform::definition method. For example to set a field as required.

<pre>
$mform->addElement('text','shortname', get_string('shortname'),'maxlength="15" size="10"');
$mform->setHelpButton('shortname', array('courseshortname', get_string('shortname')), true);
$mform->setDefault('shortname', get_string('defaultcourseshortname'));
$mform->addRule('shortname', null, 'required', null, 'client');
$mform->setType('shortname', PARAM_MULTILANG);
</pre>

There is good documentation for this on the [http://pear.php.net/manual/en/package.html.html-quickform.intro-validation.php PEAR web site]

In Moodle formslib you can set certain rules' error message to null and a default error message will automatically be used. The default messages are defined in lang/{language}/form.php. Here are the English definitions :

<pre>
$string['err_alphanumeric']='You must enter only letters or numbers here.';
$string['err_email']='You must enter a valid email address here.';
$string['err_lettersonly']='You must enter only letters here.';
$string['err_maxlength']='You must enter not more than $a->format characters here.';
$string['err_minlength']='You must enter at least $a->format characters here.';
$string['err_nopunctuation']='You must enter no punctuation characters here.';
$string['err_nonzero']='You must enter a number not starting with a 0 here.';
$string['err_numeric']='You must enter a number here.';
$string['err_rangelength']='You must enter between {$a->format[0]} and {$a->format[1]} characters here.';
$string['err_required']='You must supply a value here.';
</pre>

== moodleform::validation() ==

Define a method validation on your moodleform child to make your own custom validation for the form. This is done on the client side. And data_submitted will return null until the function returns no errors. You return an array of errors if there is any error or an empty array if there are no errors.

<pre>
class course_edit_form extends moodleform {

function definition() {
blah blah;
}

/// perform some extra moodle validation
function validation($data) {
$errors= array();
if ($foundcourses = get_records('course', 'shortname', $data['shortname'])) {
if (!empty($data['id'])) {
unset($foundcourses[$data['id']]);
}
if (!empty($foundcourses)) {
foreach ($foundcourses as $foundcourse) {
$foundcoursenames[] = $foundcourse->fullname;
}
$foundcoursenamestring = implode(',', $foundcoursenames);
$errors['shortname']= get_string('shortnametaken', '', $foundcoursenamestring);
}
}

if (empty($data['enrolenddisabled'])){
if ($data['enrolenddate'] <= $data['enrolstartdate']){
$errors['enroldateendgrp'] = get_string('enrolenddaterror');
}
}
return $errors;
}
}
?>
</pre>

{{Moodle 1.9}}There is a new parameter $files in Moodle 1.9, it allows validation of uploaded files too.
<pre>
function validation($data, $files) {
$errors = parent::validate($data, $files);
if (empty($files['userfile'])) {
if (array_key_exists('url', $data)) {
$errors['url'] = get_string('required');
}
}
return $errors;
}
</pre>

Development:NEWMODULE Adding capabilities

2008-04-07T16:49:33Z

Daniss: /* Create one access.php file in the <<NEWMODULE>>/db directory. */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

And follow the instruction on the monitor.

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it the definition of the $context variable

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T16:21:10Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

And follow the instruction on the monitor.

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it the definition of the $context variable

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T16:19:04Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

And follow the instruction on the monitor.

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it define the $context variable

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T16:18:37Z

Daniss: /* Visit the "notification page" of the Site Administration block */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

And follow the instruction on the monitor.

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it define the variable $context

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:42:33Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it define the variable $context

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:40:49Z

Daniss: /* Change the version number of your <<NEWMODULE>> */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
Just change the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of course, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it define the variable $context

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:40:26Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
just chenge the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of vcourse, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

In order to let it works, just add before it define the variable $context

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:37:07Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
just chenge the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of vcourse, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/support:confirm', $context)) {

In order to let it works, just add before it define the variable $context

global $COURSE;
if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:36:31Z

Daniss: /* Add to your code the right triggger */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
just chenge the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of vcourse, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Add to your code something like:

if (has_capability('mod/support:confirm', $context)) {

In order to let it works, just add before it define the variable $context

if (! $cm = get_record("course_modules", "id", $COURSE->id)) {
error("Course Module ID was incorrect");
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);

Development:NEWMODULE Adding capabilities

2008-04-07T14:33:51Z

Daniss: /* Visit the "notification page" of the Admin block */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
just chenge the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of vcourse, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Site Administration block==

==Add to your code the right triggger==

Development:NEWMODULE Adding capabilities

2008-04-07T14:33:21Z

Daniss: /* Change the version number of your <<NEWMODULE>> */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==
just chenge the version number of your <<NEWMODULE>> by editing the file mod/version.php. Of vcourse, you have to change it with a bigger one. :-)

==Visit the "notification page" of the Admin block==

==Add to your code the right triggger==

Development:NEWMODULE Adding capabilities

2008-04-07T14:30:58Z

Daniss: /* Create one access.php file in the <<NEWMODULE>>/db directory. */

In order to add a capabilities your <<NEWMODULE>> you have to:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==

Development:NEWMODULE Adding capabilities

2008-04-07T14:30:08Z

Daniss:

==Create one access.php file in the <<NEWMODULE>>/db directory.==

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

== Change the version number of your <<NEWMODULE>> ==

Development:NEWMODULE Adding capabilities

2008-04-07T14:29:21Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:28:50Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of these four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This defines the default selected radio button in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:27:34Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???

The element 'contextlevel' is ???

The element 'legacy' defines the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:27:02Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all,
just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:26:24Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.

It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:25:40Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:25:19Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
and you are supposed to iterate the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
close the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:24:28Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
iterating the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure described before and, at the end,
closing the main array with
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:23:51Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
iterating the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>'
for each <<CAPABILITYNAME>> you want to add
following the same structure and, at the end, closing the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:23:28Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
iterating the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, closing the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:23:12Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
iterating the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, closing the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:21:47Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),

iterate the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, close the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:21:27Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(

'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(

'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,

'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),

iterate the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, close the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:20:50Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(

'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(

'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,

'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),

iterate the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, close the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Adding capabilities

2008-04-07T14:19:48Z

Daniss:

Create one access.php file in the <<NEWMODULE>>/db directory.
It must contain
*the capabilities to be installed and
*the defaults for each standard role.

A model of what has to be added is:
$mod_glossary_capabilities = array(

'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(

'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,

'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),

iterate the array 'mod/<<NEWMODULE>>:<<PERMISSIONNAME>>' for each <<CAPABILITYNAME>> you want to add following the same structure and, at the end, close the array
)

The element 'riskbitmask' will be reflected in the list of icons of each row of the 'Override permissions'->roles page. You should add the right number of icon ranging from
*all four icons
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
*up to no icon at all, just removing the element 'riskbitmask' from the array 'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>'

The element 'captype' is ???
The element 'contextlevel' is ???
The element 'legacy' define the legacy default for that permission. It is an array and for each each element you are allowed to choose one (and only one) of this four elements: CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (if you don't set it). This define the default radio button selected in the 'Legacy roles' page.

Development:NEWMODULE Documentation

2008-04-04T17:36:34Z

Daniss:

{{Template:Work in progress}}

This first draft of Moodle Docs page about the creation of anew module is divided into the following sections:

*[[Development:NEWMODULE Tutorial]]
*[[Development:NEWMODULE Reference]]
*[[Development:NEWMODULE FAQ]]
*[[Development:NEWMODULE Adding capabilities]]

----

Danielle, did you know about [[Development:Modules]], which is linked to from [[Developer_documentation#Make_a_new_plugin]]? You may be better off editing that, rather than starting a new page. However don't let me discourage you. That documentation is very limited, and badly needs to be expanded, so it is absolutely brilliant that you want to work on it.--[[User:Tim Hunt|Tim Hunt]] 12:03, 28 March 2008 (CDT)

::Good point Tim! Anyway... I think we can use this as temporary root for Daniele's work and then, simply, move things to their final place. Let's see how this evolves. -- [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 12:33, 28 March 2008 (CDT)

----

[http://lyceum.open.ac.uk/temp/creating_moodle_modules.ppt My powerpoint about creating moodle modules] is a bit old (1.8) and maybe not that comprehensible but I use it when I'm trying to explain things to people. It includes a list of all the things you need to have in a module, except the ones I forgot (backuplib iirc is missing). [[User:sam marshall|sam marshall]] 12:52, 28 March 2008 (CDT)

::That's really great, Sam. For sure that presentation will help.Thanks! -- [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 13:08, 28 March 2008 (CDT)

Development:NEWMODULE Reference

2008-04-04T17:02:49Z

Daniss:

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== newmodule_add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== newmodule_delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== newmodule_update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.

== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== newmodule_user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== newmodule_user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== newmodule_get_post_actions (18) ==
== newmodule_get_view_actions (18) ==
== newmodule_cron (15) ==
== newmodule_reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== newmodule_print_recent_activity (11) ==
== newmodule_reset_course_form_defaults (10) ==
== newmodule_reset_course_form_definition (10) ==
Implementation of the function for printing the form elements that control
whether the course reset functionality affects the assignment.

== newmodule_get_user_grades (8) ==
== newmodule_grade_item_delete (8) ==
== newmodule_grade_item_update (8) ==
== newmodule_grades (8) ==
== newmodule_update_grades (8) ==
== newmodule_reset_gradebook (7) ==
== newmodule_scale_used (7) ==
== newmodule_scale_used_anywhere (6) ==
== newmodule_get_recent_mod_activity (5) ==
== newmodule_log_info (5) ==
== newmodule_print_overview (5) ==
== newmodule_print_recent_mod_activity (5) ==
== newmodule_refresh_events (5) ==
== newmodule_file_area (4) ==
== newmodule_file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-04T17:01:55Z

Daniss: /* user_complete (19) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== newmodule_update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.

== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== newmodule_user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
Implementation of the function for printing the form elements that control
whether the course reset functionality affects the assignment.

== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-04T17:01:22Z

Daniss: /* <<newmodule>>_update_instance (20) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== newmodule_update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.

== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
Implementation of the function for printing the form elements that control
whether the course reset functionality affects the assignment.

== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-04T17:01:05Z

Daniss: /* update_instance (20) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== <<newmodule>>_update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.

== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
Implementation of the function for printing the form elements that control
whether the course reset functionality affects the assignment.

== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:33:25Z

Daniss: /* reset_course_form_definition (10) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
Implementation of the function for printing the form elements that control
whether the course reset functionality affects the assignment.

== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:31:52Z

Daniss: /* reset_userdata (12) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
This function is used by the reset_course_userdata function in moodlelib.

This function will remove all posts from the specified newmodule and clean up any related data.

== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:27:12Z

Daniss: /* newmodule_get_participants (19) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== newmodule_get_participants (19) ==
Returns the users with data in one newmodule

(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:26:56Z

Daniss: /* get_participants (19) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== newmodule_get_participants (19) ==
Returns the users with data in one newmodule
(users with records in ???)

== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:22:54Z

Daniss: /* user_outline (19) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== get_participants (19) ==
== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
Return an outline of the user's interaction with the assignment.

The default method prints the grade and timemodified.

== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:22:07Z

Daniss: /* user_complete (19) */

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar.
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity

Deletes all database records, files and calendar events for this newmodule.
This is common to all assignment types.
== update_instance (20) ==
Updates a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will update the newmodule instance and return the id number
The due date is updated in the calendar
This is common to all assignment types.
== get_participants (19) ==
== user_complete (19) ==
Print complete information about the user's interaction with the newmodule

== user_outline (19) ==
== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:20:33Z

Daniss:

Development:NEWMODULE Reference

2008-04-03T18:17:52Z

Daniss:

Development:NEWMODULE Reference

2008-04-03T18:16:59Z

Daniss:

Development:NEWMODULE Reference

2008-04-03T18:15:55Z

Daniss:

Development:NEWMODULE Reference

2008-04-03T18:14:39Z

Daniss:

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

*add_instance (20)
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.

== add_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.

== delete_instance (20) ==
Deletes an assignment activity
*
* Deletes all database records, files and calendar events for this assignment.
* @param $assignment object The assignment to be deleted
* @return boolean False indicates error

== update_instance (20) ==
== get_participants (19) ==
== user_complete (19) ==
== user_outline (19) ==
== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==

Development:NEWMODULE Reference

2008-04-03T18:10:59Z

Daniss:

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

*add_instance (20)
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.

== delete_instance (20) ==
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.

== update_instance (20) ==
== get_participants (19) ==
== user_complete (19) ==
== user_outline (19) ==
== get_post_actions (18) ==
== get_view_actions (18) ==
== cron (15) ==
== reset_userdata (12) ==
== print_recent_activity (11) ==
== reset_course_form_defaults (10) ==
== reset_course_form_definition (10) ==
== get_user_grades (8) ==
== grade_item_delete (8) ==
== grade_item_update (8) ==
== grades (8) ==
== update_grades (8) ==
== reset_gradebook (7) ==
== scale_used (7) ==
== scale_used_anywhere (6) ==
== get_recent_mod_activity (5) ==
== log_info (5) ==
== print_overview (5) ==
== print_recent_mod_activity (5) ==
== refresh_events (5) ==
== file_area (4) ==
== file_area_name (4) ==
---
add_instance''' 
---
delete_instance 
---
update_instance 
---
get_participants 
---
user_complete 
---
user_outline 
---
get_post_actions 
---
get_view_actions 
---
cron 
---
reset_userdata 
---
print_recent_activity 
---
reset_course_form_defaults 
---
reset_course_form_definition 
---
get_user_grades 
---
grade_item_delete 
---
grade_item_update 
---
'''grades''' 
---
'''update_grades''' 
---
'''reset_gradebook''' 
---
'''scale_used''' 
---
'''scale_used_anywhere''' 
---
'''get_recent_mod_activity''' 
---
'''log_info''' 
---
'''print_overview''' 
---
'''print_recent_mod_activity''' 
---
'''refresh_events''' 
---
'''file_area''' 
---
'''file_area_name''' 
---

Development:NEWMODULE Reference

2008-04-03T18:06:02Z

Daniss:

[[Development:NEWMODULE Documentation|NEWMODULE Documentation]] > Reference
----
{{Template:Work in progress}}

This is a first draft of the list ot the functions more frequently used into Moodle modules. Between brakets the number of occurrences of each function in the following list of 20 modules: assignment, chat, choice, data, exercise, feedback, forum, glossary, hotpot, journal, label, lams, lesson, questionnaire, quiz, resource, scorm, survey, wiki, workshop.

*add_instance (20)
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.

*delete_instance (20)
*update_instance (20)
*get_participants (19)
*user_complete (19)
*user_outline (19)
*get_post_actions (18)
*get_view_actions (18)
*cron (15)
*reset_userdata (12)
*print_recent_activity (11)
*reset_course_form_defaults (10)
*reset_course_form_definition (10)
*get_user_grades (8)
*grade_item_delete (8)
*grade_item_update (8)
*grades (8)
*update_grades (8)
*reset_gradebook (7)
*scale_used (7)
*scale_used_anywhere (6)
*get_recent_mod_activity (5)
*log_info (5)
*print_overview (5)
*print_recent_mod_activity (5)
*refresh_events (5)
*file_area (4)
*file_area_name (4)
---
add_instance''' 
Create a new newmodule activity

Given an object containing all the necessary data,
(defined by the form in mod.html) this function
will create a new instance and return the id number
of the new instance.
The due data is added to the calendar
This is common to all assignment types.
---
delete_instance 
---
update_instance 
---
get_participants 
---
user_complete 
---
user_outline 
---
get_post_actions 
---
get_view_actions 
---
cron 
---
reset_userdata 
---
print_recent_activity 
---
reset_course_form_defaults 
---
reset_course_form_definition 
---
get_user_grades 
---
grade_item_delete 
---
grade_item_update 
---
'''grades''' 
---
'''update_grades''' 
---
'''reset_gradebook''' 
---
'''scale_used''' 
---
'''scale_used_anywhere''' 
---
'''get_recent_mod_activity''' 
---
'''log_info''' 
---
'''print_overview''' 
---
'''print_recent_mod_activity''' 
---
'''refresh_events''' 
---
'''file_area''' 
---
'''file_area_name''' 
---