MoodleDocs - User contributions [en]

User:Francois Marier

2009-06-15T22:44:56Z

Francois@catalyst.net.nz: Link to my other sites

Moodle developer at [http://www.catalyst.net.nz/moodle Catalyst IT]

* Blog: http://feeding.cloud.geek.nz
* Twitter: http://twitter.com/fmarier
* Identica: http://identi.ca/fmarier
* Ohloh: http://www.ohloh.net/accounts/fmarier

External Search block

2009-04-22T01:56:27Z

Francois@catalyst.net.nz: Add screenshots

This block is used to allow teachers to provide their students with an easy way of using an external search engine from within a course page.

[[Image:extsearch_block.png|center]]

=Installation=

# Unpack the module into your Moodle installation in order to create a <tt>blocks/extsearch</tt> directory
# Visit the <tt>/admin/index.php</tt> page to trigger the module installation.
# Change the default options in the block configuration. For example, you will need to provide [http://www.digitalnz.org/dashboard/api_key your own API key] if you want to enable the Digital NZ search functionality.

[[Image:extsearch_config.png|center]]

=See also=

* [http://moodle.org/mod/data/view.php?d=13&rid=2337 Download]

File:extsearch config.png

2009-04-22T01:55:53Z

Francois@catalyst.net.nz:

File:extsearch block.png

2009-04-22T01:55:12Z

Francois@catalyst.net.nz:

External Search block

2009-04-22T00:09:54Z

Francois@catalyst.net.nz: Link to the module and plugin page

This block is used to allow teachers to provide their students with an easy way of using an external search engine from within a course page.

=Installation=

# Unpack the module into your Moodle installation in order to create a <tt>blocks/extsearch</tt> directory
# Visit the <tt>/admin/index.php</tt> page to trigger the module installation.
# Change the default options in the block configuration. For example, you will need to provide [http://www.digitalnz.org/dashboard/api_key your own API key] if you want to enable the Digital NZ search functionality.

=See also=

* [http://moodle.org/mod/data/view.php?d=13&rid=2337 Download]

External Search block

2009-04-22T00:08:02Z

Francois@catalyst.net.nz: Installation instructions

This block is used to allow teachers to provide their students with an easy
way of using an external search engine from within a course page.

=Installation=

# Unpack the module into your Moodle installation in order to create a <tt>blocks/extsearch</tt> directory
# Visit the <tt>/admin/index.php</tt> page to trigger the module installation.
# Change the default options in the block configuration. For example, you will need to provide [http://www.digitalnz.org/dashboard/api_key your own API key] if you want to enable the Digital NZ search functionality.

Development:Gradebook improvements

2008-12-09T04:42:19Z

Francois@catalyst.net.nz: more flexible export plugins

{{Moodle 2.0}}

Same aspects of gradebook were not fully solved in 1.9.x, this page tries to summarize potential improvements

==Aggregation of hidden grades==
Overlook problem partially solve after the database freeze - workaround was to recalculate the grades on the fly so that users that can the hidden grades are ignored. This approach is expensive and can not be used in conditional activities, grade exports, etc.

Solution is to add new flag into grade categories - ''aggregate hidden grades''. Having two values for each grade would be too complex, selective agrragation should solve most of the problems and should be reasonably backwards compatible.

==Final grading in activities==

==Effectiveness of grading interface==

==Tracking of submission dates==

==Exports: more flexibility==

Two aspects of the 1.9 export plugin have been criticised by some of Catalyst's clients:

* the fact that grade exports are tied to a course
* the default user profile columns are not all needed and some custom ones would be necessary

Therefore I propose the following changes:
* removing the export plugin dependency on a single course by converting to an array of courses (see [http://tracker.moodle.org/browse/MDL-17420] )
* making the user-related columns customisable (see [http://tracker.moodle.org/browse/MDL-17346])

==See also==

* [[Development:Tim's_Gradebook_thoughts|Tim's Gradebook thoughts]].

[[Category:Developer]]

Face-to-face FAQ

2008-11-05T21:11:43Z

Francois@catalyst.net.nz: how to edit default email messages

{{Facetoface}}

Here is a collection of questions that were asked on the [http://moodle.org/mod/forum/view.php?id=7136 forum] or through other means.

==Where do I include the Manager's email address for notification?==

Using the Moodle 1.8 version of the Face-to-face module, the way we do this is through the "MSN messenger" field on the user profile page. So instead of storing your MSN user account, this field stores your manager's email address.

Starting with the Moodle 1.9 version of the Face-to-face module, a custom field called "Manager's email" is added to the user profile page.

==How do I setup a wait listed session?==

A 'wait-listed session' in the Face-to-face module is a session for which no date is currently set. Users can then register their interest in attending a Face-to-face course even if it's not offered at this time.

There is no way at this time to "exceed" the capacity of a given session but this can be approximated by adding a second session without a date on which users can sign-up if the other one is full.

See this [http://moodle.org/mod/forum/discuss.php?d=96118 forum thread] for more information.

==How can I use Face-to-face in a course?==
===Blended course===
Here is a blended, train the trainer course.
*Topic 1. The trainees receive initial information by 2 Lessons. They complete an off line assignment and email that to the instructor. There is a forum where the trainees are expected to participate and help each other.
*Topic 2. The trainees receive more information by a lesson, are asked to create outcomes for a training topic and then arrive at their first face to face lab. This lab is offered in two different locations at different dates and times.
*Topic 3. This is the Capstone. Here they take the work they started in the first lab and expand it. In a smaller face-to-face sessions they will get a chance to see and critique other trainee's lesson. The instructor will post all assignments for everyone to see and download.
*Topic 4. At a later time, trainees take a quiz and fill out a survey.
*Topic 5. They receive a certificate based upon their overall score.
[[Image:Face2Face in a course 1.png|center|frame|Blended course example]]

==How to modify the master copy of the confirmation emails?==

To modify the default message for any of the emails sent out, simply a local customisation to the appropriate language pack using the normal mechanism:

# Go to the Administration area
# Click on Language, then "Language editing"
# Select the desired "Current language"
# Click on "Edit words and phrases"
# In the "Choose file to edit" drop-down, scroll to the very bottom and select "facetoface.php (mod/facetoface)"

From there, you can change any of the strings you want.

Development:Admin reports

2008-09-09T06:23:28Z

Francois@catalyst.net.nz: typo in a heading

==Overview==

An admin report is a folder of code under admin/report. For example, you might make a folder in there called '''myreport'''.

In there, the only code you are required to have is an index.php file. This will normally display a simple HTML form for controlling the report, and, the code for displaying the report. You will probably also want a language file, which would be called lang/en_utf8/report_myreport.php following the example above.

In addition, you can add any other PHP code you like, and then link people to it from index.php.

So, the minimal code layout is:

admin/
...
report/
backups/
capability/
...
myreport/
lang/
en_utf8/
report_myreport.php
index.php
...
...

==What to do in index.php==

The simplest way to work this out is by example. You should look at some of the reports that ship with Moodle. [http://cvs.moodle.org/moodle/admin/report/capability/index.php?view=markup admin/report/capability], is a good one to start with. Let us go through that example to see what is there (I will put into italics the bits that are more advanced - the things that the capability report does, but which a simple report will not need to do.):
# Require some libraries. Admin reports will always need config.php and adminlib.php.
# Check the user is logged in and has appropriate permissions. ''(Normally admin reports are controlled by the 'moodle/site:viewreports' capability, the capability report is a special case.)''
# Get the parameters from the URL that control the report, and clean them up a bit.
# ''Include some JavaScript code that enhances the report for people with JavaScript turned on in their browser.''
# Log this request.
# Print the page header. Since this is an administration page, we need to do this using the admin_externalpage... functions. You probably just need to copy these three lines exactly, then replace every occurrence of 'capability' with your report name.
# Display a form to control the report.
# If the URL contains all the parameters needed to generate the report, do so, and display the results. ''(You don't need to understand the details of what the capability report is doing, because your report will do something different. However, the general structure will probably be the same: get some data out of the database, then display it.)''
# Print the footer, using the admin_externalpage... function.
# ''Define some functions, if that is the best way to structure the code of your report. You could, of course, create a separate lib.php file inside your report folder.''

==How your report gets included in the admin tree==

By default, your report will be included in the admin tree under the 'Reports' section, and it will only appear to people with the 'moodle/site:viewreports' capability. If the report is in the ''myreport'' folder, then the report name will be get_string("myreport", "report_''myreport''"). The report name, needed for the call to admin_externalpage_setup, will be "report''myreport''".

If you want more control over how your report appears, for example, if you want it to appear somewhere other than under Reports, or if you want it to be controlled by another capability, then you can create a settings.php file. For example, for the capability report, there is a settings.php file that contains:

<?php // $Id$
$ADMIN->add('''"roles"''', new admin_externalpage('reportcapability', get_string('capability', 'report_capability'), "$CFG->wwwroot/$CFG->admin/report/capability/index.php",'''"moodle/role:manage"'''));
?>

(The two non-standard bits there have been put into bold.)

==Strings you must define in you lang/en_utf8/report_''myreport''.php==

You just need to define

$string["''myreport''"] = 'What my report is called';

to make the report show up properly in the admin tree, but if your report does anything interesting, you will almost certainly need more.

==See also==

* [http://moodle.org/mod/data/view.php?d=13&rid=913 System images report] this is another very simple report, in contrib. Might be a good one to look at.

[[Category:Developer]]

Development:Activity Locking

2008-08-12T17:01:56Z

Francois@catalyst.net.nz: Download link for the Moodle 1.9 version of AL

Activity Locking is an external module which sets up conditions that a student must reach before they can start(unlock) a Moodle activity. These criterion generally include time spent, score or completed. The conditions can be applied to more than one activity or resource for a each lock.

=Overview=
This page is an attempt to consolidate and explain the available activity locking (AL) code that is present for Moodle 1.5 to 1.7. This page will hopefully help explain all the available versions and their respective features. Some of the reference here will overlap with the existing MoodleDoc page covering [[Conditional activities]].

=Types of activity locking code=
For the purpose of this MoodleDoc article: AL is any code that allows the user to make decisions on the next available resource or item the student will be able to use based on student events or quiz performance. There is some activity locking code that is very quick and dirty to simply lock future activities and then there is much more complex code based on the conditional activity though structure which attempts to progress the student through the course in a thought out progression based on activities and performance. Again we hope to clarify some of this here.

==AL Branch 0.1 (Bernard Boucher)==
Bernard started all this with a hack to lock quiz and resources in [http://moodle.org/mod/forum/discuss.php?d=2948#12825 october 2003]. The certificate based on a quiz score was added in [http://moodle.org/mod/forum/discuss.php?d=9766#59875 september 2004] with version 0.7. It was a great start!

== AL Branch 2.0 for Moodle 1.6 (Stuart Mayor)==
*This has been virtually a complete rewrite and as such there are areas of functionality the were available in older versions of AL that are not in this.

* Conditional locking: Lock based on a user's performance in previous activities. You can also choose to unlock and activity if a user scores less than a certain grade.
* Show activity completion: The checkbox that appears before each activity to show it have been done.
* A variation on this also hides future activities, see AL Branch 2.2 for Moodle 1.6 (John Gschnaidner-Chardelle Busch) below.
* Bernard Boucher reworked Stuart's version for Moolde 1.6, initially on June 20, 2006 and updated on July 10, 2006 posted [http://206.167.134.155/bb/authoring1/activityLocking2_0_for_1_6_july1006.zip '''Activity Locking V 2.0 for Moodle 1.6'''] on [http://moodle.org/mod/forum/discuss.php?d=46863#220125 Activity Locking v3 or v2 for testing only].

*Downloaded the ..1.6_July10006.zip and installed it on a clean 1.6.3 localhost Windows XP machine. The language file did not have all the required fields. Spent time editing the lock.php file (not good at it) adding lines. But it worked. --[[User:chris collman|chris collman]] 16:42, 20 October 2006 (CDT)

===Installation for 2.1 for Moodle 1.6(Stuart Mayor)===
'''activitylocking20051201.zip''' the initial version

* Firstly, you need the stable build of Moodle 1.6. This version of AL might work on earlier releases but I didn't write it with them in mind and I certainly can't support them.
Next, you need to modify one table in the database and add a new one (I use phpmyadmin for this).

*I downloaded a copy of the above zip ..20051201. Had to move the lang file from en to en_ut8f . Worked on my 1.6.3 localhost test course. --[[User:chris collman|chris collman]] 16:37, 20 October 2006 (CDT)

====Details of install====
* The table you need to modify is mdl_course_modules and you need to add the following fields:
completedbox TINYINT(1) UNSIGNED NOT NULL DEFAULT '0'
completedscore VARCHAR(255) NOT NULL
completedstyle VARCHAR(255) NOT NULL
lockedbox TINYINT(1) UNSIGNED NOT NULL DEFAULT '1'
lockedstyle VARCHAR(255) NOT NULL DEFAULT 'locked'
lockedvisible TINYINT(1) UNSIGNED NOT NULL DEFAULT '1'
delay INT(10) UNSIGNED NOT NULL DEFAULT '0'

* The table you need to create is as follows:
CREATE TABLE `mdl_course_locks` (
`id` int(10) unsigned NOT NULL auto_increment,
`courseid` int(10) unsigned NOT NULL default '0',
`locktype` varchar(10) NOT NULL default '',
`targetid` int(10) unsigned NOT NULL default '0',
`locks` longtext NOT NULL,
PRIMARY KEY (`id`)
) TYPE=MyISAM COMMENT='Contains locks for sections and modules';
* Lastly, you need to copy the following files from the zip file:
lib/moodlelib.php to moodle/lib/moodlelib.php
lib/locklib.php to moodle/lib/locklib.php
course/lib.php to moodle/course/lib.php
course/lock.php to moodle/course/lock.php
course/mod.php to moodle/course/mod.php
course/settings.html to moodle/course/settings.html
pix/t/open.gif to moodle/pix/t/open.gif
pix/t/closed.gif to moodle/pix/t/closed.gif
lang/en/lock.php to moodle/lang/en/lock.php

==AL Branch 2.2 for Moodle 1.6 (John Gschnaidner-Chardelle Busch and others)==
John's versionincludes the settings tab--making it possible to set the hide/visible options, as well as the completion (a checkmark in front of a resource/activity) options, says Chardelle.
* A variation on Stuart Mayor's 2.1, it hides topics dependent upon conditions set on specific activities/resources '''ALV2_1_debug.ZIP''' (John). Had bug which Benard tweaked out.
* A build of Stuarts Mayor's 2.1 it locks and/or hides specific activities depending upon conditions set on specific activities/resources. Had bug which Benard tweaked out.
* A tweak by Bernard Boucher on June 27, 2006 was posted [http://moodle.org/mod/forum/discuss.php?d=35488&parent=222516 moodle/lib/locklib.php file] and called '''locklib.zip''' seems to fix known bug in both the above downloads.

==AL Branch 2.4 for Moodle 1.6 (John Gschnaidner)==
Further development of the 2.2 as a hack (no installation function).
:
'''WARNING:'''
:Because of some changes, this version may '''not''' be completely compatible to previous versions!
Status:
:Released, but you still should try it '''before''' implementing it on a production server.
:
In this version:
* Supports module '''and''' section locks
* Parallel locking and completing modules '''and''' sections
* CSS style and checkbox for locking and completing
* Hide when locked
* Language support and help
* Readme for features and installation
* SQL commands for DB update
* Info on how to update the CSS style sheets

FYI: Did a download on a clean complete package install of 1.6.3 localhost Windows XP. Seemed to work. No editing neeed on lang/lock.php. After unpacking file (see table below) and droping into moodle folder, went to database and imported the MySQL script found in moodle/course/MySQL.sql . --[[User:chris collman|chris collman]] 16:32, 20 October 2006 (CDT)

==AL Branch 3.s for Moodle 1.6 (Stuart Mayor)==
Similar to the 2.x versions. Major difference is that a question to the student unlocks activities. Being actively developed and tested.

==AL Branch 3.1 for Moodle 1.7 (Bernard Boucher & Stuart Mayor)==
Bernard has updated AL for 1.7 and it is being tested--[[User:chris collman|chris collman]] 07:18, 12 March 2007 (CDT)

==CA Branch 1.0 for Moodle 1.5.2 (Borja Rubio Reyes)==
Details and discussed in the thread "[http://moodle.org/mod/forum/discuss.php?d=36697 NEW research on CONDITIONAL ACTIVITIES in Moodle]"

==Score Lock for Moodle 1.6x (John Gschnaidner)==
As announced, this is a ongoing development for Activity Locking v2.4, with a couple of new features.
For further information please refer to
:"[https://docs.moodle.org/en/Score_Lock moodle Docs: '''Score Lock''']"
Score Lock is scheduled for beta release until middle of September 2006.

= Table of Versions =
{| border="3" padding="4"
|+ Activity Locking updates
! -Version-
! Moodle version
! Who
! Status
! MySql Install
! Docs
! Download
! Teacher Interface
! Hide Option
! Completion Box Option
! Section Lock
! Quiz Question
! Comments
! Feature
! Bug
|-----
| AL 3.0
| 1.5.2
| Stuart Mayor
| not finished
|
|[http://moodle.org/mod/forum/discuss.php?d=46863]
| [http://moodle.org/file.php/5/moddata/forum/678/214752/Activity_Locking_20060317.7z]
|
|
|
|
| Yes
|
|
|
|-----
| AL 2.5 ?
| 1.9
| Chardelle Busch, ProMoodle.com
| Enhanced
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=92731]
| [http://promoodle.com/index.php?option=com_docman&task=doc_download&gid=9&Itemid=65]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.4
| 1.6
| John Gschnaidner
| released
| manual
|[http://moodle.org/mod/forum/discuss.php?d=50835]
| [http://moodle.org/file.php/5/moddata/forum/678/241994/ALv2.4.7z]
| Tabs
| Yes
| Yes
| Yes
| Yes
| looks good
|
| [http://moodle.org/file.php/5/moddata/forum/678/244338/locking.php]
|-----
| AL 2.3
| 1.6
| Stuart Mayor
| Testing
|
| [http://moodle.org/mod/forum/discuss.php?d=35488]
| [http://moodle.org/file.php/5/moddata/forum/678/164285/activitylocking20051201.zip]
|
|
|
|
| Yes
|
|
|
|-----
| AL 2.2
| 1.6
| Gschnaidner, Mayor, Busch
| Testing
|
| [http://moodle.org/mod/forum/discuss.php?d=47906]
|
| Tabs
|
|
|
| Yes
| almost
|
|
|-----
| AL 2.0
| 1.8.2+
| Stuart Mayor, Bernard Boucher
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=77907]
| [http://206.167.134.155/bb/authoring1/Activity_Locking_V2_0_for_182_Sept25_07.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.0
| 1.8.2
| Stuart Mayor, Bernard Boucher
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=77907]
| [http://206.167.134.155/bb/authoring1/Activity_Locking_V2_0_for_182_August13_07.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.0
| 1.8.1
| Stuart Mayor, Bernard Boucher
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=74477#p332097]
| [http://206.167.134.155/bb/authoring1/Activity_Locking_V2_0_for_181_June22_07.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.0
| 1.7.1
| Stuart Mayor, Bernard Boucher
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=65175#p300414]
| [http://206.167.134.155/bb/authoring1/Activity_Locking_V2_0_for_171_Feb1907.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.0
| 1.7
| Stuart Mayor, Chris Throup
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=65175#p300414]
| [http://moodle.org/file.php/5/moddata/forum/678/302505/Activity_Locking_for_Moodle_1.7_.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| AL 2.0
| 1.6
| Stuart Mayor, Bernard Boucher
| Updated
| Automatic
| [http://moodle.org/mod/forum/discuss.php?d=31627#152788]
| [http://206.167.134.155/bb/authoring1/activityLocking2_0_for_1_6_july1006.zip]
| Padlock Icons
| Yes
| Yes
| Yes
| No
| see above
|
|
|-----
| C A 1.0
| 1.5.2
| Borja Rubio Reyes, David Delgado
|
|
| [http://moodle.org/mod/forum/discuss.php?d=36697]
|
|
|
|
|
| Yes
|
|
|
|}

=General installation instructions DRAFT=
==Short instructions==
#Find and download the correct version of AL for your version of Moodle. This is a zip file.
#Extract the zipped file's folders and files in you Moodle root directory. This will put the right files in their proper directory.
#As Administrator, go to the admin block for the Moodle site. This should start the automatic install process.

==Tips and FAQs==
*Activity Locking (AL) is a non-standard Moodle feature. Testing on a Moodle that is similar to your production Moodle is advisible. For example, a localhost installation.
*Since all versions of AL change the Moodle MySQL file structure, it is advisable to do a backup before installing AL.
*Upgrading either Moodle or AL and things don't work? A common forum suggestion is to reinstall AL with the proper version that is designed for the Moodle version.
*AL installs but does not seem to lock? Be sure you are logged in as a student. Logging in as a teacher and then "viewing as as student" or changing roles to a student, will not give consistant results in Activity Locking.
*AL icons initially show in edit mode but then disappear. It has been reported that this occurs when AJAX is enabled in 1.8 - disable AJAX and they should reappear. (.../admin/settings.php?section=experimental)

=See Also=
*[[Adding_activity_locks]] will give the reader an idea of what one of the flavors of Activity Locking looks like for a student and teacher setting it up.

Please visit the Moodle Forum for more information concerning Activity Locking and Conditional Activities-

*[http://moodle.org/mod/forum/discuss.php?d=35488#220984: AL v2.1-M1.6] titled Activity Locking v2.1 (for Moodle 1.6)
*[http://moodle.org/mod/forum/discuss.php?d=46863: AL v3.0-Mx] titled Activity Locking v3
*[http://moodle.org/mod/forum/discuss.php?d=36697 AL v3.0-DD] titled NEW research on CONDITIONAL ACTIVITIES in Moodle
*[http://moodle.org/mod/forum/discuss.php?d=31627&parent=152788: AL v2.1 LALR] titled Latest Activity Locking Release started 19 October 2005
* http://moodle.org/mod/forum/view.php?id=4295
*[http://moodle.org/mod/forum/discuss.php?d=47906&parent=221613 AL v2.1 wH1.6] titled Re: Certificate for 1.6 with security in Activity Modules forum

There is a very specialized-limited type of activity locking under a lesson (activity) setting called dependency in 1.6. See: *https://docs.moodle.org/en/Adding/editing_a_lesson#Dependent_on .

[[Category:Developer]]

Face-to-face FAQ

2008-08-05T02:42:59Z

Francois@catalyst.net.nz: /* Where do I include the Manager's email address for notification? */ new custom field for Manager's email address

Development:CVS for developers

2008-05-22T00:12:08Z

Francois@catalyst.net.nz: /* Tips and Hints */ how to change password or ssh key

'''CVS''' is the Concurrent Versioning System, a commonly-used way of managing source code for large software projects. CVS keeps all versions of all files so that nothing is ever lost, and usage by different people is tracked. It also provides ways to merge code if two or more people are working on the same file. All code and all versions are stored on a central server (in the case of Moodle, at cvs.moodle.org). The [http://cvsbook.red-bean.com/cvsbook.html CVS book] holds more information about CVS than you need.

If you just want to download Moodle using CVS to run a site, then you probably don't need this page - please see [[CVS for Administrators]] instead.

==Joining the project as a developer==

So, you've been offered CVS write access to help us develop and maintain Moodle! Welcome aboard!

To be able to write changes into [http://cvs.moodle.org/ Moodle's CVS archive], you first need to have an account on the server. Only trusted developers get these accounts. To request access, go to the "Apply for CVS Access" tab on the CVS page on Moodle.org (http://moodle.org/cvs). Tell us what modules you'd like to access (e.g. a language module), and why. You'll receive notification in a day or so.

With that done, you should have all the permissions you need, so you just need to set up your machine and download the current source code so you can start working on it.

For the examples on this page, let's assume your username is '''myusername''' and your password is '''mypassword'''.

==CVS modules==

Within CVS, the word "modules" refers to separate collections of code. In Moodle we have the following modules within our repository:

* '''moodle''' - the main Moodle source code
* '''lang''' - all the language packs
* '''[[Development:contrib|contrib]]''' - user contributions and other assorted code in development
* '''mysql''' - a customised phpMyAdmin to plug into Moodle for database admin
* '''windows-cron''' - a small package that makes cron possible on Windows systems
* '''docs''' - various extra user-contributed documentation

Most people are working on the existing features in the moodle module, but many are also contributing new ideas in the contrib modules. Once code reaches a certain level of maturity in the contrib area, it can be migrated over into the main moodle tree.

==Basic CVS commands==

===CVS on Unix===

Moodle CVS uses ssh as a transport layer for security, so you will have to set a CVS_RSH environment variable in your Unix shell. It's best to put these commands in your .bashrc or .cshrc so you don't have to type it all the time:
setenv CVS_RSH ssh (for csh, tcsh etc)
export CVS_RSH=ssh (for sh, bash etc)

Next, you can check out the latest development version of Moodle using this (all one line). NOTE: Don't try to do run this first CVS command over an existing moodle installation: start fresh with a new directory!:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle

The command is similar for other CVS modules:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib

If you want to checkout a single plugin (attendance block as an example here) from contrib into the current directory, you can use:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance

Note that you will be prompted for mypassword for each command unless you set up authorized keys. Read [[Development:SSH_key|SSH Keys]] for more details on how to set those up.

Now, you should have a new 'moodle' directory. You can rename it and move it around if you like. Go into it:
cd moodle

All the latest Moodle files should be in there. You can now change files in your copy. To compare your files and directories against the main CVS copy on the server use cvs diff, e.g.:
cvs diff -c config-dist.php
cvs diff -c lang

To fetch the latest updates from the server use:
cvs update -dP

To copy your new files back to the server you would do something like:
cd lang/ca
cvs commit

You will be prompted to add some comments (depends on your default text editor). Please write a meaningful, descriptive comment and '''always include the name of any tracker issues that talk about the issue you are fixing''' (eg '''MDL-XXXX''').

After that your changes will be sent to the CVS server and stored in the repository. Done!

To save more time you can put default arguments into a file called .cvsrc in your home directory. For example, mine contains:
diff -c
update -dP

Try 'cvs help' for more details ...

===CVS on Mac OSX===

You can follow the same instructions as for Unix (above) in a terminal window. However, the cvs command is not installed by default in an OSX. You first need to install the XCode Tools. You should find this on your original installation disk. Failing that it can be downloaded (a fairly hefty download) from the Apple developer web site ([http://developer.apple.com]).

===CVS on Windows===

First, you need to download a completely fresh copy of Moodle using your developer account.

1. Get TortoiseCVS from tortoisecvs.org and install it, then reboot. (Tortoise is not currently supported on vista but [http://www.syntevo.com/smartcvs/index.html SmartCVS] works well).

2. Find or create a new folder somewhere where you want Moodle to be downloaded to.

3. Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.

4. Copy this text into the CVSROOT field (using your own username!):

:ext:myusername@cvs.moodle.org:/cvsroot/moodle

5. Under the "Module" field, type "moodle" to get the latest development version of Moodle, "contrib" to get the contributions directory, or "mysql" to get the MySQL Admin module.

6. Press the button: "OK" and everything should be downloaded.

A dialog box should show all the files being downloaded, and after a while you should have a complete copy of Moodle. After this first checkout, you can fetch the latest updated files from the CVS server:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Update".
# Sit back and watch the logs scroll by. Take note of conflicts that may occur if your local code has changes that conflict with the incoming versions - you will need to edit these files and resolve the conflicts manually.

After modifying files (you will notice their icons change from green to red!), you can commit them back to the CVS server like this:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Commit...".
# In the dialog box, type a clear description of the changes you are committing. '''Always include the name of any tracker issues related to what you are fixing''' (eg '''MDL-XXXX''').
# Click "OK". Your changes will be sent to the server.
# If you create a folder, BE CAREFUL about using the "CVS Add" option as it will add the folder to CVS without requiring a commit. Once added, the folder cannot be removed from CVS even though it will be pruned so long as it is empty.

Please note that as of April 15 2008, TortoiseCVS 1.10.6 might not work really well with Windows Vista. You could report bugs to TortoiseCVS site (hosted by SourceForge) or google "TortoiseCVS vista" for more details.

==CVS commit messages==

Every commit you make to CVS should have a commit message containing
* a tracker issue id like MDL-12345 (if necessary, create an issue before committing, the only exception is for very minor typos.)
* A brief description of the problem you are fixing. (If you are feeling lazy, you may be able to get away with copying and pasting the issue summary from the tracker.)
* If it is not immediately obvious, a brief summary of why this change fixes the problem. If a longer description is necessary, you may also want to add more information to the tracker issue, or Moodle Docs, but the code changes + commit message should provide enough clues to how the fix works on their own.

==Working with branches==

This diagram shows how the main moodle module branches into different versions over time.

[[Image:Cvstree.png|CVS tree]]

To see all the current tags and branches that are available, use this command on any old file (such as index.php in the top moodle directory):
cvs status -v index.php

Some tagging guidelines:
* Tag and branch names should always be all upper-case.
* Tags and branches should ALWAYS be applied to the entire module (all of Moodle). Don't tag individual files or directories.
* We don't allow renaming of tags because people may be relying on them, so get them right the first time!

===Trunk development===

The Trunk of CVS is the main development version of Moodle. In CVS it is also known as the HEAD, or default branch.

Moodle developers try to keep this stable as possible, but as it usually contains new code it probably has bugs and small instabilities.

Every now and then we decide the product has enough features to make a release. At this time, the trunk is tagged with a MOODLE_XX_BETA tag (in case we ever want to roll back to that point) and a new branch is formed for the release, called MOODLE_XX_STABLE.

A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs.

===Stable branches for each release===

As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it.

You can switch your local copy of Moodle to the STABLE version using the following command in Unix from the root directory:
cvs update -dP -r MOODLE_XX_STABLE

After that, all the commands described above will apply to that stable version. To return to the trunk version just issue:
cvs update -dPA

On Windows clients you should have a menu from which you can choose the branch.

Once the new STABLE branch really stabilises, a release can be declared. Packages are created for distribution and the branch will be tagged (by Martin Dougiamas) with a tag named: MOODLE_XXX

===Merging fixes===

All bug fixes in any STABLE branch should be merged back into the trunk so that they become available in future versions of Moodle. A floating tag called MOODLE_XX_MERGED needs to be maintained to keep track of the last merge. The procedure for such a merge is as follows (I'm using CVS on the Unix command line but the steps are the same for any CVS client):

[[Image:Merging.png|thumb|right|300px|This diagram summarises the process]]
1. I highly recommend keeping one checked out copy of each stable branch and the trunk/head version locally to make it easier to jump between them. Set them all up as virtual web sites on your development machine. I use directories like /moodle/18, /moodle/19 /moodle/dev etc.

2. Update to the latest stable version (I'll use XX in the example but it could be 18, 19 etc) for the relevant files, and do a cvs diff just to double-check exactly what you are checking in. Note you only need to update the files/directories you are working in, but sometimes it help to update everything anyway just to do a final check on the functionality using the web.

cd /moodle/XX/user
cvs update -dPA
cvs diff -c file1.php file2.php

3. If all looks OK, check in the fix to the stable branch. Make sure that the commit message contains the bug tracker ID (eg MDL-1111) and a decent description of your thoughts on the fix. If you don't specify a message in the command line, you'll be put into an editor to type one.

cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php

4. Go to the very latest trunk version and make sure it's up-to-date.

cd /moodle/dev/user
cvs update -dPA

5. Merge everything into your local copy of the trunk from your stable branch since the last merge. You can use the same sequence of (4) and (5) to merge the changes into other stable branches too (to backport the fix to the previous stable versions).

cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php

6. Carefully watch the update logs for conflicts, and fix every file that you see with a conflict. Afterwards, it may help to just run a diff to make sure the result is what you expected:

cvs diff -c file1.php file2.php

7. Check your merged local copy back into CVS trunk version

cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php

8. Go back to your branch version

cd /moodle/XX/user

9. Update the floating merge tag for the affected files (so that it matches MOODLE_XX_STABLE) so that this process can be repeated next time

cvs tag -RF MOODLE_XX_MERGED file1.php file2.php

Finally, the values for $version in all the Moodle version.php files within the stable branch should not be updated at all if possible (except the last digit if absolutely necessary). The reason is that someone updating from a very stable version to the next very stable version could miss database upgrades that happened on the trunk.

===Merging fixes with TortoiseCVS===
Situation: we did a fix on MOODLE_19_STABLE. We modified one file for this fix. This fix needs to be done on Moodle 1.8 and trunk(HEAD). All following CVS instructions will be applied on the file that we changed.

1. Update to the latest stable versions (HEAD included)

Right click on the moodle folder
CVS update
OK

2. On your MOODLE19 branch: commit your fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description"
OK

3. On your HEAD repository: merge the changes

Right Click on the file
CVS>
Merge...
Start: MOODLE_19_MERGED
End : MOODLE_19_STABLE
OK

4. If the resulting file have some conflicts, TortoiseCVS displays a red square on the file icon. Edit the file with your text editor and resolve the conflicts.

5. Run a diff to make sure the result is what you expected

Right Click on the file
CVS Diff
OK

6. Commit the fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description, merged from 19"
OK

We've commit MOODLE_19_STABLE and trunk. It's now time to backport the change on MOODLE_18_STABLE.
On your MOODLE18 branch: reproduce step 3 to 6.

7. On your MOODLE19 branch: update the floating merge tag for the affected file

Right Click on the file
CVS>
Tag...
Tag: MOODLE_19_MERGED
Select 'Move existing tag'
OK

On your MOODLE18 branch: reproduce step 7 (with Tag: MOODLE_18_MERGED).

===Feature branches for large changes===

Occasionally, there may be a very large feature that needs to be checked in so several people can work on it, but it is too unstable to be included in the main development trunk.

In these cases a short-term branch can be created to work on the feature, and then merged back into the main trunk as soon as possible. An example called MOODLE_19_WIDGET branch can be seen in the above diagram.

If you need to do this for your new WIDGET feature, follow these steps:

1. Discuss with other developers to make sure it's necessary!

2. Make a new tag on the trunk (for all of moodle) called MOODLE_XX_WIDGET_PRE

cvs tag -R MOODLE_XX_WIDGET_PRE

3. Create your branch called MOODLE_XX_WIDGET

cvs tag -Rb MOODLE_XX_WIDGET

4. Work in that branch until the feature is reasonably stable. Commit as necessary.

cvs commit

5. When ready, merge the whole branch into the trunk, fix conflicts, commit it to the trunk and then abandon the branch.

cvs update -dPA
cvs update -kk -j MOODLE_XX_WIDGET
cvs commit

Good luck, be careful and have fun!

==Who on earth is ...==

Some of the people committing to the Moodle codebase have non-boring account names on the CVS server. If you are ever looking at a CVS commit, and wondering "who on earth is this purpleblob person?" This information is now available at: [http://moodle.org/mod/cvsadmin/view.php?cid=1 Moodle developers with write access].

==Tips and Hints==
* [http://moodle.org/mod/cvsadmin/ Change your password or SSH key] (click on "Update my developer information")
* [[Tracking Moodle CVS with git]]
* [http://moodle.org/mod/forum/discuss.php?d=34472 Merging Custom Moodle Code With Stable Releases]
* [[Unmerged files]]: To see if you've forgotten to merge any file.
* [http://ximbiot.com/cvs/manual/ CVS Manual]
* [[Development:contrib|Introduction to the '''contrib''' area of CVS]]

==See also==

* [http://tracker.moodle.org/browse/MDLSITE-193 "All developers should switch to using the cvs.moodle.org alias"]
* [[CVS for Administrators]]

[[Category:Developer|CVS for developers]]
[[Category:Developer tools]]

[[es:CVS para desarrolladores]]
[[fr:CVS pour développeurs]]
[[pt:CVS_para_programadores]]

Face-to-face FAQ

2008-05-01T00:14:29Z

Francois@catalyst.net.nz: How do I setup a wait listed session?

{{Facetoface}}

Here is a collection of questions that were asked on the [http://moodle.org/mod/forum/view.php?id=7136 forum] or through other means.

==Where do I include the Manager's email address for notification?==

Currently, the way we do this is through the "MSN messenger" field on the user profile page. So instead of storing the MSN user account, this field stores your manager's email address.

We will hopefully change this to make use of the custom fields introduced in Moodle 1.8

==How do I setup a wait listed session?==

A 'wait-listed session' in the Face-to-face module is a session for which no date is currently set. Users can then register their interest in attending a Face-to-face course even if it's not offered at this time.

There is no way at this time to "exceed" the capacity of a given session but this can be approximated by adding a second session without a date on which users can sign-up if the other one is full.

See this [http://moodle.org/mod/forum/discuss.php?d=96118 forum thread] for more information.

Integrating Face-to-face sessions on the course page

2008-03-31T00:22:58Z

Francois@catalyst.net.nz: More explicit instructions, remove the patch

{{Facetoface}}

=Code to add=

To display the session dates directly on the course page, you must add a couple of lines to the print_section() function in course/lib.php:

} elseif ($mod->modname == 'facetoface') {
include_once($CFG->dirroot.'/mod/facetoface/lib.php');
echo facetoface_print_coursemodule_info($mod);

=Where to add the code=

In between this block:

if ($mod->modname == "label") {

and the matching else clause:

} else { // Normal activity

The code goes just above the 'else' line just shown.

On 1.9, it should be close to line 1347.

=Result=

It will look like this:

[[Image:Ftof01.png]]

Face-to-face FAQ

2008-03-27T22:26:28Z

Francois@catalyst.net.nz: Add sidebar

{{Facetoface}}

Here is a collection of questions that were asked on the [http://moodle.org/mod/forum/view.php?id=7136 forum] or through other means.

==Where do I include the Manager's email address for notification?==

Currently, the way we do this is through the "MSN messenger" field on the user profile page. So instead of storing the MSN user account, this field stores your manager's email address.

We will hopefully change this to make use of the custom fields introduced in Moodle 1.8

Face-to-face FAQ

2008-03-27T22:25:43Z

Francois@catalyst.net.nz: Where do I include the Manager's email address for notification?

Here is a collection of questions that were asked on the [http://moodle.org/mod/forum/view.php?id=7136 forum] or through other means.

==Where do I include the Manager's email address for notification?==

Currently, the way we do this is through the "MSN messenger" field on the user profile page. So instead of storing the MSN user account, this field stores your manager's email address.

We will hopefully change this to make use of the custom fields introduced in Moodle 1.8

Template:Facetoface

2008-03-27T22:24:04Z

Francois@catalyst.net.nz: add FAQ

<div class="sideblock right" style="width: 15em;">
<div class="header">[[Face-to-face module]]</div>
<div class="content">
* [[Face-to-face walk through|Walk through]]
* [[Creating a new Face-to-face session|Creating a new session]]
* [[Signing-up for a Face-to-face session|Signing-up for a session]]
* [[Integrating Face-to-face sessions on the course page|Integration with the course page]]
* [[Face-to-face FAQ|Frequently Asked Questions]]
</div>
</div>

Template:Facetoface

2008-02-26T23:00:30Z

Francois@catalyst.net.nz: Reduce width

Integrating Face-to-face sessions on the course page

2008-02-26T22:59:29Z

Francois@catalyst.net.nz: Add sidebar

{{Facetoface}}

To display the session dates directly on the course page, add the following
code to the print_section() function in course/lib.php:

--- /cvs/moodle18/course/lib.php 2007-10-05 20:19:29.000000000 +1300
+++ course/lib.php 2007-11-06 21:14:08.000000000 +1300
@@ -1382,6 +1382,10 @@
echo "</span>";
}

+ } elseif ($mod->modname == 'facetoface') {
+ include_once($CFG->dirroot.'/mod/facetoface/lib.php');
+ echo facetoface_print_coursemodule_info($mod);
+
} else { // Normal activity

//Accessibility: for files get description via icon.

It will look like this:

[[Image:Ftof01.png]]

Signing-up for a Face-to-face session

2008-02-26T22:59:10Z

Francois@catalyst.net.nz: Add sidebar

{{Facetoface}}

Students can sign-up for one of the sessions by clicking on the Face-to-face link in the course page (which brings them to the "upcoming sessions" page) and then clicking on the signup link next to the session they want.

Creating a new Face-to-face session

2008-02-26T22:59:01Z

Francois@catalyst.net.nz: Add sidebar

{{Facetoface}}

Once you have added the Face-to-face activity to a course, you can add new sessions (as a teacher in that course or an administrator) by:

* clicking on the Face-to-face activity to get to the page of "upcoming sessions"
* clicking on the "add session" link at the bottom of the table

==Why is the "add sessions" button not visible to non-admin teachers?==

Make sure your teachers have the following permission for that course:

mod/facetoface:editsessions

Note that if you installed the face-to-face module on a running system AFTER you created the course, the permissions may not have been passed down to the teacher.

Face-to-face walk through

2008-02-26T22:58:49Z

Francois@catalyst.net.nz: Add sidebar

{{Facetoface}}

''The following is the walk through of the implementation of the Face to Face module at Inland Revenue in New Zealand.''

'''Below''', when staff visit the PowerPoint course page they are presented with three separate classroom based PowerPoint courses (101, 201 & 301). Each is listed in its own topic on the same Moodle course page. The screen shots below only shows the first topic - PowerPoint 101.
[[Image:Ftof01.png]]

----
'''Below''', the staff member has clicked on the session offered on 15 August and is then asked to sign up or cancel. Note, in this screen shot the duration time has not been entered - this needs to be manually set as the booking can be for multiple days and varying time slots.
[[Image:Ftof02.png]]

----
'''Below''', the staff member has clicked on sign up and is asked to confirm their manager's email address. In the screen shot below this information is already known and the staff member needs only to confirm that it is correct.
[[Image:Ftof03.png]]

----
'''Below''', on-screen confirmation of the completed booking.
[[Image:Ftof04.png]]

----
'''Below''', the course page is now redrawn and in place of the upcoming session dates is the session they have booked.
[[Image:Ftof05.png]]
----
'''Below''', from here they can see, who else has booked on this session.
[[Image:Ftof06.png]]
----
'''Below''', and they can cancel their booking.
[[Image:Ftof07.png]]
----
'''Below''', they also receive an email message confirming the booking. This email message is re-sent with the header "Reminder" a settable number of days in advance of the session.
[[Image:Ftof08.png]]

Creating a new Face-to-face session

2008-02-26T22:52:02Z

Francois@catalyst.net.nz: add a note about permissions

Once you have added the Face-to-face activity to a course, you can add new sessions (as a teacher in that course or an administrator) by:

* clicking on the Face-to-face activity to get to the page of "upcoming sessions"
* clicking on the "add session" link at the bottom of the table

==Why is the "add sessions" button not visible to non-admin teachers?==

Make sure your teachers have the following permission for that course:

mod/facetoface:editsessions

Note that if you installed the face-to-face module on a running system AFTER you created the course, the permissions may not have been passed down to the teacher.

Face-to-face module

2008-02-26T22:46:38Z

Francois@catalyst.net.nz: Move contents to separate pages

{{Facetoface}}

Face-to-face activities are used to keep track of in-person trainings which require advance booking.

Each activity is offered in one or more identical sessions. These sessions can be given over multiple days.

Reminder messages are sent to users and their managers a few days before the session is scheduled to start. Confirmation messages are sent when users sign-up for a session or cancel.

== See also ==

* [http://moodle.org/mod/data/view.php?d=13&rid=995 Download]
* [http://moodle.org/mod/forum/view.php?id=7136 Forum]: get help and read annoucements
* [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&&pid=10033&component=10250&sorter/field=issuekey&sorter/order=DESC Bug tracker]

[[Category:Contributed code]]

Integrating Face-to-face sessions on the course page

2008-02-26T22:45:30Z

Francois@catalyst.net.nz: Add one of IRD's images

To display the session dates directly on the course page, add the following
code to the print_section() function in course/lib.php:

--- /cvs/moodle18/course/lib.php 2007-10-05 20:19:29.000000000 +1300
+++ course/lib.php 2007-11-06 21:14:08.000000000 +1300
@@ -1382,6 +1382,10 @@
echo "</span>";
}

+ } elseif ($mod->modname == 'facetoface') {
+ include_once($CFG->dirroot.'/mod/facetoface/lib.php');
+ echo facetoface_print_coursemodule_info($mod);
+
} else { // Normal activity

//Accessibility: for files get description via icon.

It will look like this:

[[Image:Ftof01.png]]

Integrating Face-to-face sessions on the course page

2008-02-26T22:44:25Z

Francois@catalyst.net.nz: Moved from "Face-to-face module"

Signing-up for a Face-to-face session

2008-02-26T22:44:07Z

Francois@catalyst.net.nz: Moved from "Face-to-face module"

Students can sign-up for one of the sessions by clicking on the Face-to-face link in the course page (which brings them to the "upcoming sessions" page) and then clicking on the signup link next to the session they want.

Creating a new Face-to-face session

2008-02-26T22:43:37Z

Francois@catalyst.net.nz: Moved from "Face-to-face module"

Face-to-face walk through

2008-02-26T22:42:21Z

Francois@catalyst.net.nz: Moved from "Face-to-face module"

''The following is the walk through of the implementation of the Face to Face module at Inland Revenue in New Zealand.''

'''Below''', when staff visit the PowerPoint course page they are presented with three separate classroom based PowerPoint courses (101, 201 & 301). Each is listed in its own topic on the same Moodle course page. The screen shots below only shows the first topic - PowerPoint 101.
[[Image:Ftof01.png]]

----
'''Below''', the staff member has clicked on the session offered on 15 August and is then asked to sign up or cancel. Note, in this screen shot the duration time has not been entered - this needs to be manually set as the booking can be for multiple days and varying time slots.
[[Image:Ftof02.png]]

----
'''Below''', the staff member has clicked on sign up and is asked to confirm their manager's email address. In the screen shot below this information is already known and the staff member needs only to confirm that it is correct.
[[Image:Ftof03.png]]

----
'''Below''', on-screen confirmation of the completed booking.
[[Image:Ftof04.png]]

----
'''Below''', the course page is now redrawn and in place of the upcoming session dates is the session they have booked.
[[Image:Ftof05.png]]
----
'''Below''', from here they can see, who else has booked on this session.
[[Image:Ftof06.png]]
----
'''Below''', and they can cancel their booking.
[[Image:Ftof07.png]]
----
'''Below''', they also receive an email message confirming the booking. This email message is re-sent with the header "Reminder" a settable number of days in advance of the session.
[[Image:Ftof08.png]]

Template:Facetoface

2008-02-26T22:41:03Z

Francois@catalyst.net.nz: increase block width

<div class="sideblock right" style="width: 20em;">
<div class="header">[[Face-to-face module]]</div>
<div class="content">
* [[Face-to-face walk through|Walk through]]
* [[Creating a new Face-to-face session|Creating a new session]]
* [[Signing-up for a Face-to-face session|Signing-up for a session]]
* [[Integrating Face-to-face sessions on the course page|Integration with the course page]]
</div>
</div>

Template:Facetoface

2008-02-26T22:40:34Z

Francois@catalyst.net.nz: Avoid linking to generic page names

<div class="sideblock right" style="width: 18em;">
<div class="header">[[Face-to-face module]]</div>
<div class="content">
* [[Face-to-face walk through|Walk through]]
* [[Creating a new Face-to-face session|Creating a new session]]
* [[Signing-up for a Face-to-face session|Signing-up for a session]]
* [[Integrating Face-to-face sessions on the course page|Integration with the course page]]
</div>
</div>

Template:Facetoface

2008-02-26T22:36:29Z

Francois@catalyst.net.nz:

<div class="sideblock right" style="width: 12em;">
<div class="header">[[Face-to-face module]]</div>
<div class="content">
* [[Walk through]]
* [[Creating a new session]]
* [[Signing-up for a session]]
* [[Integration with the course page]]
</div>
</div>

Face-to-face module

2008-02-20T05:21:43Z

Francois@catalyst.net.nz: First draft

Face-to-face activities are used to keep track of in-person trainings which require advance booking.

Each activity is offered in one or more identical sessions. These sessions can be given over multiple days.

Reminder messages are sent to users and their managers a few days before the session is scheduled to start. Confirmation messages are sent when users sign-up for a session or cancel.

= Creating a new session =

Once you have added the Face-to-face activity to a course, you can add new sessions (as a teacher in that course or an administrator) by:

* clicking on the Face-to-face activity to get to the page of "upcoming sessions"
* clicking on the "add session" link at the bottom of the table

= Signing-up for a session =

Students can sign-up for one of the sessions by clicking on the Face-to-face link in the course page (which brings them to the "upcoming sessions" page) and then clicking on the signup link next to the session they want.

= Integration with the course page =

To display the session dates directly on the course page, add the following
code to the print_section() function in course/lib.php:

--- /cvs/moodle18/course/lib.php 2007-10-05 20:19:29.000000000 +1300
+++ course/lib.php 2007-11-06 21:14:08.000000000 +1300
@@ -1382,6 +1382,10 @@
echo "</span>";
}

+ } elseif ($mod->modname == 'facetoface') {
+ include_once($CFG->dirroot.'/mod/facetoface/lib.php');
+ echo facetoface_print_coursemodule_info($mod);
+
} else { // Normal activity

//Accessibility: for files get description via icon.

= See also =

* [http://moodle.org/mod/data/view.php?d=13&rid=995 Download]
* [http://moodle.org/mod/forum/view.php?id=7136 Forum]: get help and read annoucements
* [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&&pid=10033&component=10250&sorter/field=issuekey&sorter/order=DESC Bug tracker]

Development:Roles

2007-08-23T05:09:59Z

Francois@catalyst.net.nz: /* Programming Interface */ remove extra bracket

{{Moodle 1.7}}
'''Roles and permissions''' is in Moodle 1.7 onwards.

==Definitions==

A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.

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

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

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

==The existing system==

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

==The new roles and capability system==

With v1.7 and greater, Moodle introduces a roles and capabilities system.

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

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

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

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

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

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

[[Image:Moodle-contexts-1.8.png|right|thumb|A diagram of the contexts in Moodle 1.8, based on the [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Click on the diagram to see a more detailed view of it.]]

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===Admins===

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

===Course Creators===

Course Creators will be assigned the default legacy course creator role in the system (site) context

===Teachers===

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

===Students===

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

===Guests===

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

==Capabilities==

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

===Core-level Capabilities===

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

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

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

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

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

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

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

==Metacourses==

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

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

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

==Problem areas we are working on ==

===Student view===

The "Student view" button has been removed completely.

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

===Teacher forum===

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

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

===Enrolment plugins===

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

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

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

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

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

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

1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.
<br style="clear:both;" />

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

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

For example click on an icon beside the sub heading "Course categories" and show/hide all table rows with the CLASS "course-category".
<br style="clear:both;" />

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

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

==See also==

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

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

[[fr:Developpement:Roles]]

User:Francois Marier

2007-08-23T02:39:44Z

Francois@catalyst.net.nz:

Moodle developer at [http://www.catalyst.net.nz Catalyst IT]

Development:Roles and modules

2007-08-23T02:38:14Z

Francois@catalyst.net.nz: /* Sample code */ According to the blurb about has_capability above, this should be $context->id and not $cm->id

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

==Introduction==

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

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

==Context==

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

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

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

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

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

inputs:

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

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

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

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

==Code rewrite==

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

==Sample code==

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

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

...

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

...

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

==Core API==

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

[[Category:Developer|Roles and modules]]
[[Category:Roles]]

Development:Roles

2007-08-22T23:46:49Z

Francois@catalyst.net.nz: /* Core-level Capabilities */ missing # in front of list item

{{Moodle 1.7}}
'''Roles and permissions''' is in Moodle 1.7 onwards.

==Definitions==

A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.

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

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

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

==The existing system==

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

==The new roles and capability system==

With v1.7 and greater, Moodle introduces a roles and capabilities system.

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

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

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

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

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

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

[[Image:Moodle-contexts-1.8.png|right|thumb|A diagram of the contexts in Moodle 1.8, based on the [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Click on the diagram to see a more detailed view of it.]]

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===Admins===

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

===Course Creators===

Course Creators will be assigned the default legacy course creator role in the system (site) context

===Teachers===

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

===Students===

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

===Guests===

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

==Capabilities==

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

===Core-level Capabilities===

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

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

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

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

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

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

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

==Metacourses==

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

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

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

==Problem areas we are working on ==

===Student view===

The "Student view" button has been removed completely.

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

===Teacher forum===

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

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

===Enrolment plugins===

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

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

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

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

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

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

1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.
<br style="clear:both;" />

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

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

For example click on an icon beside the sub heading "Course categories" and show/hide all table rows with the CLASS "course-category".
<br style="clear:both;" />

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

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

==See also==

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

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

[[fr:Developpement:Roles]]

Development:Roles

2007-08-22T23:37:51Z

Francois@catalyst.net.nz: /* The new roles and capability system */ typo

{{Moodle 1.7}}
'''Roles and permissions''' is in Moodle 1.7 onwards.

==Definitions==

A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.

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

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

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

==The existing system==

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

==The new roles and capability system==

With v1.7 and greater, Moodle introduces a roles and capabilities system.

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

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

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

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

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

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

[[Image:Moodle-contexts-1.8.png|right|thumb|A diagram of the contexts in Moodle 1.8, based on the [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Click on the diagram to see a more detailed view of it.]]

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===Admins===

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

===Course Creators===

Course Creators will be assigned the default legacy course creator role in the system (site) context

===Teachers===

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

===Students===

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

===Guests===

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

==Capabilities==

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

===Core-level Capabilities===

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

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

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

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

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

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

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

==Metacourses==

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

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

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

==Problem areas we are working on ==

===Student view===

The "Student view" button has been removed completely.

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

===Teacher forum===

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

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

===Enrolment plugins===

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

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

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

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

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

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

1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.
<br style="clear:both;" />

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

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

For example click on an icon beside the sub heading "Course categories" and show/hide all table rows with the CLASS "course-category".
<br style="clear:both;" />

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

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

==See also==

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

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

[[fr:Developpement:Roles]]