MoodleDocs - User contributions [en]

Filters

2015-12-03T23:46:54Z

Jonwitts: /* Local configuration */

<p class="note">'''Please note:''' This page contains information for developers. You may prefer to read the [[:en:Filters| information about filters for teachers and administrators]].</p>

{{Moodle 2.0}}

'''Filters''' are a way to automatically transform content before it is output. For example
* render embedded equations to images (the TeX filter)
* Links to media files can be automatically converted to an embedded applet for playing the media.
* Mentions of glossary terms can be automatically converted to links.
The possibilities are endless. There are a number of standard filters included with Moodle, or you can create your own. Filters are one of the easiest types of plugin to create. This page explains how.

==Before you start==

Go to Site administration ▶ Plugins ▶ Filters ▶ Common filter settings and set Text cache lifetime to 0 ("No") while you do development. Otherwise, you will not be able to see the effects of your changes when you edit your filter's code. (You should also be using the other common developer settings, like developer debug, theme designer mode and so on.)

==Creating a basic filter==

During this tutorial, we will build a simple example filter. We will make one that adds the word 'hello' before every occurrence of the word 'world'.

1. Since our filter is not part of a module, we should put it inside the 'filter' folder. Therefore, we create a directory called 'filter/helloworld'.

2. Inside that folder, we create a file called 'filter.php'.

3. Inside that PHP file, we define a class called filter_helloworld, that extends the moodle_text_filter class.
<code php>
<?php
class filter_helloworld extends moodle_text_filter {
// ...
}
?>
</code>

4. Inside that class, we have to define one method, called 'filter'. This takes the HTML to be filtered as an argument. The method should then transform that, and return the processed text. Replace the '// ...' above with
<code php>
class filter_helloworld extends moodle_text_filter {
public function filter($text, array $options = array()) {
return str_replace('world', 'hello world!', $text);
}
}
</code>

That is basically all there is to it!

==Giving your filter a name==

To try the new filter, you first have to log in as Administrator and enable it by going to the page Administration ► Plugins ► Filters ► Manage filters.

When you do, you will find that your plugin does not have a name. We missed a step:

5. Inside the 'filter/helloworld' folder, create a folder called 'lang', and in there, create a folder called 'en'.

6. Inside there, create a file called 'filter_helloworld.php'. That is, you have just created the file 'filter/helloworld/lang/en/filter_helloworld.php'.

7. In that file, put
<code php>
<?php // $Id$
// Language string for filter/helloworld.

$string['filtername'] = 'Hello world!';
</code>

That may seem a little involved, just to give your filter a name, but it is just [[Places_to_search_for_lang_strings|the standard way Moodle stores language strings for plugins]].

==Trying out your filter==

We had just got to the [[Filters|filters administration screen]]. If you reload that page now, it should now show your filter with its proper name. Turn your filter on now.

Filters are applied to all text that is printed with the [[Output functions|output functions]] format_text(), and, if you have turned on that option, format_string(). So, to see your filter in action, add some content containing the word 'world' somewhere, for example, create a test course, and use the word in the course description. When you look at that course in the course listing, you should see that your filter has transformed it.

==Adding a global settings screen==

Some filters can benefit from some settings to let the administrator control how they work. Suppose we want to greet something other than 'world'. To add global settings to the filter you need to:

8. Create a file called 'filtersettings.php' inside the 'filter/helloworld' folder. Use standard 'settings.php' file in Moodle 2.6 and later.

9. In the 'filtersettings.php' file, put something like:
<code php>
$settings->add(new admin_setting_configtext('filter_helloworld/word',
get_string('word', 'filter_helloworld'),
get_string('word_desc', 'filter_helloworld'), 'world', PARAM_NOTAGS));
</code>

10. In the language file 'filter/helloworld/lang/en/filter_helloworld.php' add the necessary strings:
<code php>
$string['word'] = 'The thing to greet';
$string['word_desc'] = 'The hello world filter will add the word \'hello\' in front of every occurrence of this word in any content.';
</code>

11. Change the filter to use the new setting:
<code php>
class filter_helloworld extends moodle_text_filter {
public function filter($text, array $options = array()) {
global $CFG;
return str_replace($CFG->filter_helloworld/word,
"hello $CFG->filter_helloworld/word!", $text);
}
}
</code>

In standard Moodle, the censor, mediaplugin and tex filters all provide good examples of of how filters use global configuration like this.

==A note about performance==

One important thing to remember when creating a filter is that the filter will be called to transform every bit of text output using format_text(), and possibly also format_string(). That means that you have to be careful, or you could cause big performance problems. If you have to get data out of the database, try to cache it so that you only do a fixed number of database queries per page load. The Glossary filter is an example of this. (I am not sure how good an example ;-))

If your filter uses a special syntax or it is based on an appearance of
a substring in the text, it is recommend to perform a quick and cheap
<tt>strpos()</tt> search first prior to executing the full regex-based search and replace.

<code php>
/**
* Example of a filter that uses <a> links in some way.
*/
public function filter($text, array $options = array()) {

if (!is_string($text) or empty($text)) {
// Non-string data can not be filtered anyway.
return $text;
}

if (stripos($text, '</a>') === false) {
// Performance shortcut - if there is no </a> tag, nothing can match.
return $text;
}

// Here we can perform some more complex operations with the <a>
// links in the text.
}
</code>

==Local configuration==

In addition, in Moodle 2.0, filters can also have different configuration in each context. For example, the glossary filter could be changed so that in Forum A, you can choose to only link words from a particular glossary, say Glossary A, while in Forum B you choose to link words from Glossary B.

To do that sort of thing, you need to add a file called filterlocalsettings.php. In it, you must define a [[lib/formslib.php|Moodle form]] that is a subclass of filter_local_settings_form. In addition to the standard formslib methods, you also need to define a save_changes method. There is not a good example of this in the standard Moodle install yet. To continue our example:

12. Create a file called 'filterlocalsettings.php' inside the 'filter/helloworld' folder.

13. In the 'filterlocalsettings.php' file, put:
<code php>
class helloworld_filter_local_settings_form extends filter_local_settings_form {
protected function definition_inner($mform) {
$mform->addElement('text', 'word', get_string('word', 'filter_helloworld'), array('size' => 20));
$mform->setType('word', PARAM_NOTAGS);
}
}
?>
</code>

14. Extend the filter to use the new setting, if it is present. The filter must be able to work if the setting is not set, for example by falling back to the global or default setting in this case
<code php>
<?php
class filter_helloworld extends moodle_text_filter {
public function filter($text, array $options = array()) {
global $CFG;
if (isset($this->localconfig['word'])) {
$word = $this->localconfig['word'];
} else {
$word = $CFG->filter_helloworld/word;
}
return str_replace($word, "hello $word!", $text);
}
}
?>
</code>

==Two types of filter==

In the past, Moodle supported two different types of filter:
* Stand-alone filters like the one we created above. These live in a folder inside the 'filter' folder. For example, in 'filter/myfilter'. 'filter/tex' is an example of a core filter of this type.
* Filters that were part of an activity module. In this case, the filter code lives inside the 'mod/mymod' folder. 'mod/glossary' used to be an example of a core module with a filter.
The second option no longer exists in Moodle 2.5 and later. All filters live in the filter folder. Of course, a filter may depend on an associated other plugin, like mod_glossary. If so, you should declare that in the [[version.php]] file.

==Dynamic content==

From Moodle 2.7:
On (very few) pages - it is possible that page content is loaded by ajax *after* the page is loaded (e.g. equations in a glossary popup). In certain filter types (e.g. MathJax) javascript is required to be run on the output of the filter in order to do the final markup. For these types of filters, a javascript event is triggered when new content is added to the page (the content will have already been processed by the filter in php). The javascript for a filter can listen for these event notifications and reprocess the affected dom nodes.

To subscribe to the event:

// Listen for events triggered when new text is added to a page that needs
// processing by a filter.
Y.on(M.core.event.FILTER_CONTENT_UPDATED, this.contentUpdated, this);

To handle the event:

/**
* Handle content updated events - typeset the new content.
* @method contentUpdated
* @param Y.Event - Custom event with "nodes" indicating the root of the updated nodes.
*/
contentUpdated: function(event) {
var self = this;
Y.use('mathjax', function() {
self._setLocale();
event.nodes.each(function (node) {
node.all('.filter_mathjaxloader_equation').each(function(node) {
MathJax.Hub.Queue(["Typeset", MathJax.Hub, node.getDOMNode()]);
});
});
});
}

See: filter/mathjaxloader/yui/src/loader/js/loader.js

==See also==

* [[Filters schema]] - a page containing some ideas and thoughts about modifications to the filters system
* [[:en:Filters]] user documentation about filters.
* [https://moodle.org/plugins/browse.php?list=category&id=7 - List of filters in the Plugins database].

[[Category:Filter]]
[[Category:Plugins]]

Roles

2011-12-13T14:25:06Z

Jonwitts: /* Context */

==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 system prior to v1.7==

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.

=== Roles ===
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 similar 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)

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

[[Image:Moodle-contexts-1.8.png|right|thumbnail|200px|A diagram of the contexts in Moodle. Click on the diagram to see a more detailed view of it.]]

{| class="nicetable"
|-
! CONTEXT NAME
! CONTEXT AREA
! CONTEXTLEVEL
|-
| CONTEXT_SYSTEM
| the whole site
| 10
|-
| CONTEXT_USER
| another user
| 30
|-
| CONTEXT_COURSECAT
| a course category
| 40
|-
| CONTEXT_COURSE
| a course
| 50
|-
| CONTEXT_GROUP
| a group
| 60
|-
| CONTEXT_MODULE
| an activity module
| 70
|-
| CONTEXT_BLOCK
| a block
| 80
|}

Please note that CONTEXT_PERSONAL (present in 1.7-1.8) was never implemented and was removed in 1.9. CONTEXT_GROUP is also not implemented and can not be used.

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

(See [[Roles and modules#Context]] for more information.)

=== Capabilities ===
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.

=== Checking for capabilities ===
You can use the [[Roles_and_modules#has_capability_.28.24capability.2C_.24contextid.2C_.24kill.29|has_capability ()]] function for checking for capabilities in your code.

=== Capability conflicts ===
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.

===Capability-locality changes in v1.9===

When resolving conflicts between "allow" and "prevent" in v1.7 and v1.8 the locality of the capability is taken into account, although with less weight than the locality of the role assignment. In v1.9 the process has been simplified, we consider locality of the role assignment when dealing with allow/prevent conflicts, but ignore where the capability has been defined (as long as it applies to the context).

For example - for the situation where there is

* two roles assigned to one user in a context (eg student role and teacher role)
* one override on one of those roles ( eg student role), at the same context

then

* '''1.7/1.8''' The override used to ''always'' win over the settings from the combined roles.

* '''1.9''' The override is combined with the student role first. and then the roles are combined. This is more logical, as the override is acting like a modification to the student role.

For more details, see [http://tracker.moodle.org/browse/MDL-11218 MDL-11218]

==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:managecategory - 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 MDL-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):

<code php>
'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
)
),
</code>

* 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:

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

* or at the course level:

<code php>
$context = get_context_instance(CONTEXT_COURSE, $id);
</code>

* Then, whenever you want to check that the current user has rights to do something, call '''has_capability()''' like this:

<code php>
if (!has_capability('mod/forum:viewforum', $context)) {
print_error('nopermissiontoviewforum');
}
</code>

* 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:

<code php>
require_capability('mod/forum:viewforum', $context);
</code>

* 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 metacourse 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===
''Typically, for a manager in a business environment, they will want to be able to view reports, view grades for Quizzes, and view results from Surveys/Questionnaires for specific courses. They will also want to be able to view the list of enrolled students.''

Note that in Moodle 2.0, there is a manager role, but that is manager like a lesser admin. It is not manager like a manager in a business environment.

===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 separate 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]
#[[Stats_roles_1.7|Statistics]] [Penny]
#Fix Loginas
#Add category-level assigns [Yu]
#[[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==

*[[Hardening new Roles system]]
*[[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]
*** A short description by Tim Hunt of some new role related features in Moodle 2.0: [http://moodle.org/mod/forum/discuss.php?d=139641&parent=610871 Adding new roles as part of a module]

[[Category:Roles]]
[[Category:Interfaces]]

Roles

2011-12-13T14:20:20Z

Jonwitts: /* Context */

==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 system prior to v1.7==

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.

=== Roles ===
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 similar 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)

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

[[Image:Moodle-contexts-1.8.png|right|thumbnail|200px|A diagram of the contexts in Moodle. Click on the diagram to see a more detailed view of it.]]

CONTEXT NAME CONTEXT AREA CONTEXTLEVEL
#CONTEXT_SYSTEM -- the whole site -- 10
#CONTEXT_USER -- another user -- 30
#CONTEXT_COURSECAT -- a course category -- 40
#CONTEXT_COURSE -- a course -- 50
#CONTEXT_Group -- a group -- 60
#CONTEXT_MODULE -- an activity module -- 70
#CONTEXT_BLOCK -- a block -- 80

Please note that CONTEXT_PERSONAL (present in 1.7-1.8) was never implemented and was removed in 1.9. CONTEXT_GROUP is also not implemented and can not be used.

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

(See [[Roles and modules#Context]] for more information.)

=== Capabilities ===
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.

=== Checking for capabilities ===
You can use the [[Roles_and_modules#has_capability_.28.24capability.2C_.24contextid.2C_.24kill.29|has_capability ()]] function for checking for capabilities in your code.

=== Capability conflicts ===
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.

===Capability-locality changes in v1.9===

When resolving conflicts between "allow" and "prevent" in v1.7 and v1.8 the locality of the capability is taken into account, although with less weight than the locality of the role assignment. In v1.9 the process has been simplified, we consider locality of the role assignment when dealing with allow/prevent conflicts, but ignore where the capability has been defined (as long as it applies to the context).

For example - for the situation where there is

* two roles assigned to one user in a context (eg student role and teacher role)
* one override on one of those roles ( eg student role), at the same context

then

* '''1.7/1.8''' The override used to ''always'' win over the settings from the combined roles.

* '''1.9''' The override is combined with the student role first. and then the roles are combined. This is more logical, as the override is acting like a modification to the student role.

For more details, see [http://tracker.moodle.org/browse/MDL-11218 MDL-11218]

==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:managecategory - 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 MDL-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):

<code php>
'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
)
),
</code>

* 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:

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

* or at the course level:

<code php>
$context = get_context_instance(CONTEXT_COURSE, $id);
</code>

* Then, whenever you want to check that the current user has rights to do something, call '''has_capability()''' like this:

<code php>
if (!has_capability('mod/forum:viewforum', $context)) {
print_error('nopermissiontoviewforum');
}
</code>

* 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:

<code php>
require_capability('mod/forum:viewforum', $context);
</code>

* 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 metacourse 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===
''Typically, for a manager in a business environment, they will want to be able to view reports, view grades for Quizzes, and view results from Surveys/Questionnaires for specific courses. They will also want to be able to view the list of enrolled students.''

Note that in Moodle 2.0, there is a manager role, but that is manager like a lesser admin. It is not manager like a manager in a business environment.

===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 separate 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]
#[[Stats_roles_1.7|Statistics]] [Penny]
#Fix Loginas
#Add category-level assigns [Yu]
#[[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==

*[[Hardening new Roles system]]
*[[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]
*** A short description by Tim Hunt of some new role related features in Moodle 2.0: [http://moodle.org/mod/forum/discuss.php?d=139641&parent=610871 Adding new roles as part of a module]

[[Category:Roles]]
[[Category:Interfaces]]

User talk:Matt Gibson

2011-04-01T17:39:26Z

Jonwitts:

=== Configuration addition on [[Apache]] page ===

Hi Matt,
I'm slightly concerned that the 'a2enmod' command that you recommend appears to be peculiar to Debian Linux (I certainly don't have it on my SuSE install). Perhaps a note to this effect, or better yet a more general way of achieving this. I wasn't aware of this local caching FWIW. --[[User:Howard Miller|Howard Miller]] 16:00, 21 June 2006 (WST)

==Thank you==

Hi Matt, just wanted to say a big THANK YOU for all your [[Special:Contributions/Matt_Gibson|documentation contributions]] and also for filing lots of bugs - much appreciated :-) --[[User:Helen Foster|Helen Foster]] 08:40, 20 December 2007 (CST)

== HTTPS and UK Data Protection ==

Hi Matt, I had a query regarding your statements on the [[Masquerading]] page. I have added my question to the [[Talk:Masquerading]] page...

[[User:Jon Witts|Jon Witts]]

Moodle 2.0 release notes

2010-07-18T07:31:51Z

Jonwitts: /* System requirements */

{{Work_in_progress}}

Release date: '''July 20, 2010'''

Before the final release we will have a series of rapidly improving Preview releases. These are to allow a wider range of developers and contributors to test the code on copies of their production servers, help us tweak the interface and performance, and work on translations, modules and other third-party code (most of which will have to be rewritten significantly).

* [[Moodle 2.0 Preview 1 release notes]] - May 4, 2010
* [[Moodle 2.0 Preview 2 release notes]] - May 17, 2010
* [[Moodle 2.0 Preview 3 release notes]] - May 31, 2010
* [[Moodle 2.0 Preview 4 release notes]] - June 30, 2010
* [[Moodle 2.0 Preview 5 release notes]]

Moodle 2.0 contains a lot of large new features, some completely rewritten features, and hundreds of bug fixes. For full details (more than you probably want!), see [http://tracker.moodle.org/browse/MDL/fixforversion/10122 the full list of fixed issues in 2.0].

This page is a summary of the major things to look for (links and screenshots will be added over time).

==Major new features==

===Community hubs===

* Anybody can set up a Community Hub, which is a directory of courses for public use or for private communities. The code is implemented as separate GPL plugin for Moodle.
* Sites can register to any Community Hub (instead of just moodle.org)
* Teachers on registered sites can publish their full courses to Community Hubs, for download
* Teachers on registered sites can also advertise their courses on Community Hubs, for people to join
* Teachers on any site can search all public Community Hubs and download courses as templates for their own courses
* Users on any Moodle site can also search Community Hubs for courses (and communities of practice) to participate in. Initially we are encouraging ''''communities of teaching practice'''' but any sort of course can be listed.

===Repository support===

* Moodle now supports integration with external repositories of content, making it really simple to bring documents and media into Moodle via an AJAX interface that looks like a standard '''Open''' dialogue in desktop applications.
* Initial plugins in 2.0 include: Alfresco, Amazon S3, Box.net, File system on Server, Flickr, Google Docs, Mahara, MERLOT, Picasa, Recent Files, Remote Moodle sites, WebDAV servers, Wikimedia, Youtube. These are simple to develop, so many more are expected.
* You can also import files from your desktop or by specifying a URL.

===Portfolio support===

* Modules can now export their data to external systems, particularly useful for portfolios where snapshots of forums, assignments and other things in Moodle are useful to record in a journal or a portfolio of evidence
* Different formats are supported (currently LEAP2A, HTML, Images and Text, but others like PDF can be added)
* Initial plugins in 2.0 include: Box.net, Flickr, Google Docs, '''Mahara''' and Picasa.

===Completion===

* Teachers can now specify conditions that define when any '''activity''' is seen as completed by a student. For example, when a certain number of posts have been made, or a grade has been reached, or a choice has been made.
* Teachers can now specify conditions that define with any '''course''' is seen as completed by a student. Conditions include activity completion, but could also be by grade, date or a number of other criteria.
* Teachers and students can see reports that show the progress of any user within a course, or through a series of courses.

===Conditional activities===

* Access to activities can be restricted based on certain criteria, such as dates, grade obtained, or the completion of another activity.
* These can be chained together to enable progressive disclosure of the course content, if that is desired.

===Cohorts===
* Also known as "Site-wide groups", these are site-wide collections of users that can be enrolled into courses in one action, either manually or synchronised automatically

===Web services support===
* Support for standards-based web services across the entire Moodle code base, allowing the admin to expose particular functions of Moodle for use by:
** Administrative systems such as HR or SIS applications
** Mobile clients
* Framework contains a very high-level of security with a detailed token system and complete control over the range of functions exposed
* All defined functions are automatically available via:
** SOAP
** XML-RPC
** REST
** AMF (Flash)

===IMS Common Cartridge===
* Moodle can now import courses in IMS Common Cartridge format (commonly used by publishers)

===New blocks===
* Comments block - like a shoutbox, allows comments to be added to any page. Great for student feedback.
* Private files block - allows easy access to one's private file repository in Moodle (with quota support)
* Community block - keeps track of external courses one is interested in
* Completion block - reports on the completion status of your courses

==Major improvements to existing core features==

===Backup and restore===

* Completely rewritten Backup/Restore framework, no longer bound by memory (can work with '''any size course''').
* Completely new backup format.
* Improved interface.
* Backup can be made of whole courses, but also specific sections or activities.

===Blocks===
* Blocks are now consistently implemented on every page in Moodle
* No longer any limit to the block regions (in addition to left and right, put them at the top, center or bottom of pages)
* Any block can be made sticky (appears in all the contexts below, eg throughout a course).
* Blocks can be "docked" on the side of the screen (if the theme supports it)

===Blog===
* Support for comments on each blog entry
* Removal of group-level and course-level blogs (these are converted into forums on upgrade)
* Support for external blog feeds (synchronised to Moodle blog)

===Comments===
* User comments (Glossaries, Databases, Blogs, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available
* User activity reports will include all the comments made by that user

===Enrolment plugins===
* Major improvements in the handling of guests and guest accounts
* Support for multiple forms of enrolment at the same time
* More detailed control over enrolment in courses

===File handling===

* Full support for Unicode file names on all operating systems.
* Metadata about each file (author, date, license, etc) and what the file is used for are stored in the database.
* Duplicate files (for example, a large video file use in two different courses) are only stored once, saving disk space.
* Files are no longer just "uploaded to the course". Files are connected to the particular bit of Moodle content that uses them. (For example, a file may belong to a file resource, a forum post or a wiki page). Access to these files is then controlled by the same rules as as that bit of Moodle, increasing security.

===Gradebook===
* Details coming soon

===HTML editor===
* New editor based on TinyMCE
* Works on more browsers
* Resizable editing area
* Cleaner XHTML output
* Full integration with configured external repositories to import and embed media into text

===Messaging===
* All email sent by Moodle is now treated as a message
* A message overview panel allows users to control how messages are sent to them
* Initial message output plugins in Moodle 2.0 include: Email, Jabber and Popups

===My Moodle page===
* More customisable My Moodle page with new blocks for showing relevant information
* Admin can design (and optionally force) site-wide layouts for My Moodle
* My Moodle page given more prominence as the main "home page" for users

===Navigation===
* Standard "Navigation" block on every page showing contextual links, while allowing you to jump elsewhere quickly
* Standard "Settings" blocks on every page shows contextual settings as well as settings for anything else you have permissions for

===Ratings===
* User ratings (Glossaries, Databases, Forums, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available
* Aggregation of using ratings into activity grades is now standardised in all activities

===Roles and permissions===
* Improved and simplified AJAX interfaces for defining and assigning roles
* Improved and simplified interfaces for tweaking permissions in any given context
* New "Archetypes" concept replacing the "Legacy roles" concept.
* New archetype "manager" to define the role of most people with system-wide editing rights, separate from "admin" role.

===RSS feeds===
* All RSS feeds are now secured using a random per-user token in the URL
* Tokens can be updated by the user at any time (if they suspect a feed URL has been compromised)
* RSS feeds are now more accurate (eg they support forums with separate groups), and are generated efficiently whenever required

===Themes===
* Many new themes in the core distribution
* All HTML and JS ouput is now far more efficient (server-side caching) and consistent (tableless layout, new CSS, YUI Framework)
* Themes can change the HTML of the page if they wish
* Core support for custom menus in all themes (for example at the top of the page)

===Translation system===
* [http://lang.moodle.org/ New web portal] to make it easer for groups to collaborate on translating Moodle, and to keep their translations up-to-date.
* More efficient [[Development:Languages/AMOS|storage format for language strings]] should slightly improve performance.

===User profile pages===
* Site-wide user profile page can be customised by users with blocks, news, feeds and so on
* Course-specific user profile pages show course blocks and standard profile information, plus information for teachers of that course

==Major improvements to activity modules==

===Lesson===
* Refactored internal code
* Forms are now standard Moodle forms

===Quiz module and question bank===

* [[Development:quiz_navigation|Quiz navigation improvements for students]]
* [[Development:Flagging_questions_during_a_quiz_attempt|Flagging questions during a quiz attempt]]
* [[Development:Quiz_report_enhancements|Quiz report enhancements]] - Major improvements to the quiz reports, especially regrading and item analysis
* [[Development:Quiz_UI_redesign|Quiz editing interface improvements]]
* Different settings (open/close date, number of attempts, password, time limit) for each group or student (MDL-16478)
* [[Development:Administration page for question types|Administration page for question types]]
* [[Development:Moodle 2.0 question bank improvements|Question tagging and improved searching in the question bank]]
* MDL-8648 Essay questions can now be randomised by random questions

===Resource===
* All the resource types have been refactored into real modules, and cleaned up
** File - for displaying a file, possibly with supporting files (like a HTML mini-site)
** Folder - for displaying a collection of documents
** URL - for displaying a page with a given URL
** Page - for a single page, edited online using the HTML editor
** IMS - for showing a regular IMS content package
* Better XHTML-compliant support for frames, iframes and embedding in all these modules

===SCORM===

* New [[SCORM module]] settings - display attempt status, display course structure, force completed, force new attempt, lock after final attempt - allowing the behaviour dictated to the SCORM object by the authoring package to be changed MDL-11501
* New reporting interface including sortable/collapsible table with group select box and ability to download in Excel, ODS and text format MDL-21555

===Wiki===
* Completely re-written from scratch, based on NWIki from UPC
* Support for Mediawiki-style syntax, as well as Creole
* Interface improvements

===Workshop===

* Completely rewritten from scratch
* Vastly improved interface for managing stages and users

==System requirements==

Since Moodle 2.0 is such a major release, we are allowing ourselves some increases in the requirements.

* PHP must be 5.2.8 or later (it was released 08-Dec-2008)
* Databases should be one of the following:
** MySQL 5.0.25 or later (InnoDB storage engine highly recommended)
** PostgreSQL 8.3 or later
** Oracle 10.2 or later
** MS SQL 2005 or later
* Any standards-supporting browser from the past few years, for example:
** Firefox 3 or later
** Safari 3 or later
** Google Chrome 4 or later
** Opera 9 or later
** MS Internet Explorer 7 or later (Even [http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html Google don't support IE6 any more])
** etc

==Upgrading==

* When upgrading to Moodle 2.0, you must have Moodle 1.9 or later. if you are using an earlier version of Moodle (eg 1.8.x) then you need to upgrade to Moodle 1.9.x first.
* We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.

==For developers: API changes==

See [[Development:Migrating_contrib_code_to_2.0]]

* [[Development:DB_layer_2.0_migration_docs|Database layer changes]] - you will need to update your code.
* [[Development:Using_the_file_API|File handling changes]] - you will need to update your code.
* [[Development:Migrating your code code to the 2.0 rendering API|Rendering layer changes]] - should be mostly backwards compatible, but you are advised to upgrade your code.
* Require capability used to do an automatic require_login. It no longer does so. All pages must explicitly call require_login if they need it. MDL-19882
* [[Development:Moodle_2.0_question_type_API_changes|Changes to the question type API]]
* MNet has been refactored and tidied up - related third party code needs to be checked
* Changes and improvements to the [[Development:Local_customisation|Local customisation system]].
* Javascript
* YUI

<noinclude>==See also==
*[[Moodle 1.9 release notes]]

[[Category:Release notes]]
[[Category:Moodle 2.0]]

[[fr:Notes de mise à jour de Moodle 2.0]]
[[es:Notas de Moodle 2.0]]
</noinclude>

Moodle 2.0 release notes

2010-07-18T07:24:29Z

Jonwitts: /* System requirements */

{{Work_in_progress}}

Release date: '''July 20, 2010'''

Before the final release we will have a series of rapidly improving Preview releases. These are to allow a wider range of developers and contributors to test the code on copies of their production servers, help us tweak the interface and performance, and work on translations, modules and other third-party code (most of which will have to be rewritten significantly).

* [[Moodle 2.0 Preview 1 release notes]] - May 4, 2010
* [[Moodle 2.0 Preview 2 release notes]] - May 17, 2010
* [[Moodle 2.0 Preview 3 release notes]] - May 31, 2010
* [[Moodle 2.0 Preview 4 release notes]] - June 30, 2010
* [[Moodle 2.0 Preview 5 release notes]]

Moodle 2.0 contains a lot of large new features, some completely rewritten features, and hundreds of bug fixes. For full details (more than you probably want!), see [http://tracker.moodle.org/browse/MDL/fixforversion/10122 the full list of fixed issues in 2.0].

This page is a summary of the major things to look for (links and screenshots will be added over time).

==Major new features==

===Community hubs===

* Anybody can set up a Community Hub, which is a directory of courses for public use or for private communities. The code is implemented as separate GPL plugin for Moodle.
* Sites can register to any Community Hub (instead of just moodle.org)
* Teachers on registered sites can publish their full courses to Community Hubs, for download
* Teachers on registered sites can also advertise their courses on Community Hubs, for people to join
* Teachers on any site can search all public Community Hubs and download courses as templates for their own courses
* Users on any Moodle site can also search Community Hubs for courses (and communities of practice) to participate in. Initially we are encouraging ''''communities of teaching practice'''' but any sort of course can be listed.

===Repository support===

* Moodle now supports integration with external repositories of content, making it really simple to bring documents and media into Moodle via an AJAX interface that looks like a standard '''Open''' dialogue in desktop applications.
* Initial plugins in 2.0 include: Alfresco, Amazon S3, Box.net, File system on Server, Flickr, Google Docs, Mahara, MERLOT, Picasa, Recent Files, Remote Moodle sites, WebDAV servers, Wikimedia, Youtube. These are simple to develop, so many more are expected.
* You can also import files from your desktop or by specifying a URL.

===Portfolio support===

* Modules can now export their data to external systems, particularly useful for portfolios where snapshots of forums, assignments and other things in Moodle are useful to record in a journal or a portfolio of evidence
* Different formats are supported (currently LEAP2A, HTML, Images and Text, but others like PDF can be added)
* Initial plugins in 2.0 include: Box.net, Flickr, Google Docs, '''Mahara''' and Picasa.

===Completion===

* Teachers can now specify conditions that define when any '''activity''' is seen as completed by a student. For example, when a certain number of posts have been made, or a grade has been reached, or a choice has been made.
* Teachers can now specify conditions that define with any '''course''' is seen as completed by a student. Conditions include activity completion, but could also be by grade, date or a number of other criteria.
* Teachers and students can see reports that show the progress of any user within a course, or through a series of courses.

===Conditional activities===

* Access to activities can be restricted based on certain criteria, such as dates, grade obtained, or the completion of another activity.
* These can be chained together to enable progressive disclosure of the course content, if that is desired.

===Cohorts===
* Also known as "Site-wide groups", these are site-wide collections of users that can be enrolled into courses in one action, either manually or synchronised automatically

===Web services support===
* Support for standards-based web services across the entire Moodle code base, allowing the admin to expose particular functions of Moodle for use by:
** Administrative systems such as HR or SIS applications
** Mobile clients
* Framework contains a very high-level of security with a detailed token system and complete control over the range of functions exposed
* All defined functions are automatically available via:
** SOAP
** XML-RPC
** REST
** AMF (Flash)

===IMS Common Cartridge===
* Moodle can now import courses in IMS Common Cartridge format (commonly used by publishers)

===New blocks===
* Comments block - like a shoutbox, allows comments to be added to any page. Great for student feedback.
* Private files block - allows easy access to one's private file repository in Moodle (with quota support)
* Community block - keeps track of external courses one is interested in
* Completion block - reports on the completion status of your courses

==Major improvements to existing core features==

===Backup and restore===

* Completely rewritten Backup/Restore framework, no longer bound by memory (can work with '''any size course''').
* Completely new backup format.
* Improved interface.
* Backup can be made of whole courses, but also specific sections or activities.

===Blocks===
* Blocks are now consistently implemented on every page in Moodle
* No longer any limit to the block regions (in addition to left and right, put them at the top, center or bottom of pages)
* Any block can be made sticky (appears in all the contexts below, eg throughout a course).
* Blocks can be "docked" on the side of the screen (if the theme supports it)

===Blog===
* Support for comments on each blog entry
* Removal of group-level and course-level blogs (these are converted into forums on upgrade)
* Support for external blog feeds (synchronised to Moodle blog)

===Comments===
* User comments (Glossaries, Databases, Blogs, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available
* User activity reports will include all the comments made by that user

===Enrolment plugins===
* Major improvements in the handling of guests and guest accounts
* Support for multiple forms of enrolment at the same time
* More detailed control over enrolment in courses

===File handling===

* Full support for Unicode file names on all operating systems.
* Metadata about each file (author, date, license, etc) and what the file is used for are stored in the database.
* Duplicate files (for example, a large video file use in two different courses) are only stored once, saving disk space.
* Files are no longer just "uploaded to the course". Files are connected to the particular bit of Moodle content that uses them. (For example, a file may belong to a file resource, a forum post or a wiki page). Access to these files is then controlled by the same rules as as that bit of Moodle, increasing security.

===Gradebook===
* Details coming soon

===HTML editor===
* New editor based on TinyMCE
* Works on more browsers
* Resizable editing area
* Cleaner XHTML output
* Full integration with configured external repositories to import and embed media into text

===Messaging===
* All email sent by Moodle is now treated as a message
* A message overview panel allows users to control how messages are sent to them
* Initial message output plugins in Moodle 2.0 include: Email, Jabber and Popups

===My Moodle page===
* More customisable My Moodle page with new blocks for showing relevant information
* Admin can design (and optionally force) site-wide layouts for My Moodle
* My Moodle page given more prominence as the main "home page" for users

===Navigation===
* Standard "Navigation" block on every page showing contextual links, while allowing you to jump elsewhere quickly
* Standard "Settings" blocks on every page shows contextual settings as well as settings for anything else you have permissions for

===Ratings===
* User ratings (Glossaries, Databases, Forums, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available
* Aggregation of using ratings into activity grades is now standardised in all activities

===Roles and permissions===
* Improved and simplified AJAX interfaces for defining and assigning roles
* Improved and simplified interfaces for tweaking permissions in any given context
* New "Archetypes" concept replacing the "Legacy roles" concept.
* New archetype "manager" to define the role of most people with system-wide editing rights, separate from "admin" role.

===RSS feeds===
* All RSS feeds are now secured using a random per-user token in the URL
* Tokens can be updated by the user at any time (if they suspect a feed URL has been compromised)
* RSS feeds are now more accurate (eg they support forums with separate groups), and are generated efficiently whenever required

===Themes===
* Many new themes in the core distribution
* All HTML and JS ouput is now far more efficient (server-side caching) and consistent (tableless layout, new CSS, YUI Framework)
* Themes can change the HTML of the page if they wish
* Core support for custom menus in all themes (for example at the top of the page)

===Translation system===
* [http://lang.moodle.org/ New web portal] to make it easer for groups to collaborate on translating Moodle, and to keep their translations up-to-date.
* More efficient [[Development:Languages/AMOS|storage format for language strings]] should slightly improve performance.

===User profile pages===
* Site-wide user profile page can be customised by users with blocks, news, feeds and so on
* Course-specific user profile pages show course blocks and standard profile information, plus information for teachers of that course

==Major improvements to activity modules==

===Lesson===
* Refactored internal code
* Forms are now standard Moodle forms

===Quiz module and question bank===

* [[Development:quiz_navigation|Quiz navigation improvements for students]]
* [[Development:Flagging_questions_during_a_quiz_attempt|Flagging questions during a quiz attempt]]
* [[Development:Quiz_report_enhancements|Quiz report enhancements]] - Major improvements to the quiz reports, especially regrading and item analysis
* [[Development:Quiz_UI_redesign|Quiz editing interface improvements]]
* Different settings (open/close date, number of attempts, password, time limit) for each group or student (MDL-16478)
* [[Development:Administration page for question types|Administration page for question types]]
* [[Development:Moodle 2.0 question bank improvements|Question tagging and improved searching in the question bank]]
* MDL-8648 Essay questions can now be randomised by random questions

===Resource===
* All the resource types have been refactored into real modules, and cleaned up
** File - for displaying a file, possibly with supporting files (like a HTML mini-site)
** Folder - for displaying a collection of documents
** URL - for displaying a page with a given URL
** Page - for a single page, edited online using the HTML editor
** IMS - for showing a regular IMS content package
* Better XHTML-compliant support for frames, iframes and embedding in all these modules

===SCORM===

* New [[SCORM module]] settings - display attempt status, display course structure, force completed, force new attempt, lock after final attempt - allowing the behaviour dictated to the SCORM object by the authoring package to be changed MDL-11501
* New reporting interface including sortable/collapsible table with group select box and ability to download in Excel, ODS and text format MDL-21555

===Wiki===
* Completely re-written from scratch, based on NWIki from UPC
* Support for Mediawiki-style syntax, as well as Creole
* Interface improvements

===Workshop===

* Completely rewritten from scratch
* Vastly improved interface for managing stages and users

==System requirements==

Since Moodle 2.0 is such a major release, we are allowing ourselves some increases in the requirements.

* PHP must be 5.2.8 or later (it was released 08-Dec-2008)
* Databases should be one of the following:
** MySQL 5.0.25 or later (InnoDB storage engine highly recommended)
** PostgreSQL 8.3 or later
** Oracle 10.2 or later
** MS SQL 2005 or later
* Any standards-supporting browser from the past few years, for example:
** Firefox 3 or later
** Safari 3 or later
** Google Chrome 4 or later
** Opera 9 or later
** MS Internet Explorer 7 or later (Even [http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html Google don't support IE6 any more])
** In Windows installations at least, the webserver user must have write access to the Temp folder defined in your php set up for file uploads to function
** etc

==Upgrading==

* When upgrading to Moodle 2.0, you must have Moodle 1.9 or later. if you are using an earlier version of Moodle (eg 1.8.x) then you need to upgrade to Moodle 1.9.x first.
* We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.

==For developers: API changes==

See [[Development:Migrating_contrib_code_to_2.0]]

* [[Development:DB_layer_2.0_migration_docs|Database layer changes]] - you will need to update your code.
* [[Development:Using_the_file_API|File handling changes]] - you will need to update your code.
* [[Development:Migrating your code code to the 2.0 rendering API|Rendering layer changes]] - should be mostly backwards compatible, but you are advised to upgrade your code.
* Require capability used to do an automatic require_login. It no longer does so. All pages must explicitly call require_login if they need it. MDL-19882
* [[Development:Moodle_2.0_question_type_API_changes|Changes to the question type API]]
* MNet has been refactored and tidied up - related third party code needs to be checked
* Changes and improvements to the [[Development:Local_customisation|Local customisation system]].
* Javascript
* YUI

<noinclude>==See also==
*[[Moodle 1.9 release notes]]

[[Category:Release notes]]
[[Category:Moodle 2.0]]

[[fr:Notes de mise à jour de Moodle 2.0]]
[[es:Notas de Moodle 2.0]]
</noinclude>

User:Jon Witts/Biography

2010-07-11T19:14:24Z

Jonwitts: /* Education History */

=Jon Witts Biography=
==Work History==
*2007 - Current : Director of ICT at South Hunsley School
*2004 - 2007 : Learning Resource Centre Manager at South Hunsley School
*2003 - 2004 : Ran my own Cyber Café and IT consultancy Company
*2002 - 2003 : Audio Visual and IT Technician at Hull Time Based Arts
*2001 - 2002 : Administrative Assistant at Hull Time Based Arts

==Education History==

*2005 - 2008 : Foundation Degree, Design and Development of e-Learning, University of Huddersfield
*1997 - 2000 : BA Hons , Fine Art - Time Based Media, University of Humberside and Lincolnshire
*1996 - 1997 : BTEC, Fine Art Foundation, Barnfield College
*1994 - 1996 : A Level, Art, Maths and Physics, Luton Sixth Form College

User:Jon Witts/Biography

2010-07-11T19:10:47Z

Jonwitts: /* Work History */

2009-02-03T09:45:37Z

Jonwitts: New page: I work at a secondary school in the East Riding of Yorkshire in England as the Director of ICT. I like to help out in the forums if I can, but more often than not I will be asking for hel...

I work at a secondary school in the East Riding of Yorkshire in England as the Director of ICT.

I like to help out in the forums if I can, but more often than not I will be asking for help myslef! :-D