MoodleDocs - Contribucions de l'usuari [ca]

Themes 2.0 overflow problems

2010-10-27T08:36:22Z

UrsHunkler: Added some clarifications. Removed Tim's changes.

This document examines the overflow:hidden - fixed width problem currently plaguing several areas of Moodle 2.0 (as of October 26, 2010)

==The problem==

Content that is too wide for the main content area is not displayed correctly is obscured behind the side blocks or off-screen, and the browser doesn't scroll horizontally.

To see it, shrink your browser window and look at:

* http://moodle.org/mod/forum/discuss.php?d=32796

It is caused by '''oversized, unwrappable content''':

# Large images or other media of one form or another.
# Tables, any table that has numerous columns and/or large content in columns.
## Tabulated data
## Tables for internal layout (like the forum)
# Unwrappable content
## This is normally always user-entered text or images.
## Different browsers handle things differently.

==The technical description==

The cause is a combination of the fixed width that gets set on the core layout XHTML, and the overflow:hidden setting that is required by the layout.

The layout used in the base theme within Moodle is based on Matthew James Taylor's [http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm Holy grail layout] which is an excellent layout, however (and it does state this in the description of the layout) wide content is a known problem.

This problem starts on the very first div that contains content within the body *<div id="page-content">....</div>* which has the following style:

<code css>
#page-content {
clear:both;
float:left;
overflow:hidden;
position:relative;
width:100%;
min-width:900px;
}
</code>

Setting the width to 100% instantly boxes the displayable area to just the browsers internal display width, and then overflow:hidden ensures that any overflow is not visible.

This is required because the premise of this layout is to move everything out of the viewport and then move things back into the correct position and in doing this it goes as far as expanding content divs out to 200% width.

Because of this if we remove the width 100% and/or overflow hidden everything breaks because the page will ALWAYS expand beyond the browsers displayable area even if the content is easily displayed.

As far as I can see there is no way to avoid this problem while using this layout.

On the other hand there are very good reasons for using this layout:
* it is cross browser,
* columns are orderd 2,1,3 which is good for accessibility and search engine optimisation, and
* in EVERY other respect it works well

==Proposed solution 1 - Additional wrapper DIV ==

A couple of days ago I sat down with Martin and explained this to him and we looked into it and came up with the following three part solution:

# Wrap format_text output within a div with a class that allows us to manage overflow. The themes can then turn on overflow:auto for these areas to make sure that user content wraps correctly (eg forum post content).
# Convert places that use tables for layout to divs (eg forum posts) so that they wrap cleanly. Without this the large user content causes the table cells to grow too large, causing wrapping issues.
# Locate places where tables are likely to require horizontal scrolling and wrap them in divs with a class like `flexible-wrap` that sets an overflow:auto so that the table is scrollable if required.

===Advantages===

# A standard way for developers and themers to deal with these issues (can go in coding guidelines)
# Will remove the possibility for users to intentionally/accidentally destroy the interface by posting large content

===Possible problems===

# Because all format_text calls will be wrapped by this special div there might be regressions throughout Moodle - we will have to review the calls and possibly disable the new wrapping divs for some of them. (For example, quiz multiple choice options are processed by format_text, then output inside a Label. The wrapping div would break that horribly.)
# Some parts of Moodle can never be made to fit in a sensible width. For example the gradebook, and other reports.
# IE6/7 (and possibly IE 8/9?) render their scrollbars INSIDE an element rather than outside like most other browsers meaning that there is a *VERY* high chance there will be redundant scrollbars within some elements that don't actually require wrapping (on these browsers)
# Elements that require scrolling will have their own scrollbars and particularly in the case of tables this is likely to require scrolling the page vertically to locate the horizontal scrollbar, scrolling horizontally and then locating the desired row vertically again.
# Elements with a set width (e.g.style="width:2000px") greater than the content area will need to be wrapped in a div with the wrapping class as well.

==Proposed solution 2 - Source code order ==

Compromise, and use a 1, 3, 2 or 1, 2, 3 layout (with skip links for accessibility).

===Advantages===

# It can be made to work for all pages.
# We use a 1, 3, 2 at the OU, and it is reliable.

===Possible problems===

# Slightly less accessible (unless you are comparing with the current situation that actually chops off text for most users even before you start resizing fonts, and is therefore infinitely less accessible, of course).
# Hurts our pride to give up on a 2, 1, 3 layout.

==Proposed solution 3 - JavaScript ==

Add some JavaScript to the page, so that once everything has been laid out, it computes how wide the page needs to be to avoid truncation, and then changes the min-width: 900px to whatever width is needed to make the content fit.

===Advantages===

# Might be the easiest solution to implement.

===Possible problems===

# Ewwwwwww! This is clearly a horrible hack.
# JavaScript for layout is deeply evil.

==Proposed solution 4 - Admin theme ==

Use different page layouts for different needs. Admin/settings pages show very different content than the normal learning pages. All pages for admins and teachers where they change settings or edit content are shown with the admin theme. Two different page layouts would solve a lot of issues. In for example WordPress and Drupal the concept of the admin theme for admin/settings pages and the "nice" theme for content is standard.

# Use an "admin theme" with flexible width and a 1-2 layout for the admin and settings pages. The huge tables are mainly on the admin pages. Most table issues would be solved this way.
# Use the existing 2-1-3 fixed width layout for all learning pages.
# Change all tables in the forum layout and other modules if existent to div layouts.
# Create a filter to display a miniature of oversized media and open the original size in a bigger overlay on click. The maximum width can be a setting in the filter to fit different theme needs.

===Advantages===

# The pages with different needs get different layouts better fitting these needs.
# One optimized admin theme can be used with many different themes. Theme designers can focus on the content pages when they work on themes.
# The flexible width admin theme helps a lot when the content shall be displayed in any fixed width page layout.
# The different look of the admin theme signals: be careful - you are changing things which may seriously affect the system or the learning content.
# I use an flexible width admin theme I developed for some time now with all fixed width themes and solve the table width issues on admin/settings pages. It's always the same admin theme with very different content themes.

===Possible problems===

# The deeply nested forum threads issues are not solved with the admin theme.

==Opinions==

; Tim
: I vote for 2, or failing that 3. I think 1. will not work.

; Sam
: agree with Tim except I don't think 3 is likely to be reliable either.
: http://moodle.org/mod/cvsadmin/view.php?conversationid=5929

; Frank
: IMHO the only real problem is '''2.2.Tables for internal layout (like the forum)''' and possibly 3.2. (Which, by the way, only proves that tables for layout are a bad thing, [[User:Frank Ralf/Semantic HTML3]]). Any other ''oversized, unwrappable content'' will break the layout one way or another and should be the responsibility of the author. That said, I favor solution 2; any solution which requires JavaScript (3) only makes the situation even more complex. --[[User:Frank Ralf|Frank Ralf]] 14:41, 26 October 2010 (UTC)

; Urs
: I vote for 4.
: 3 is no option - from my experience using JavaScript to correct page issues breaks every once in a while.
: 2 does not solve the table width issue in fixed width themes.
: 1 seams to offer more problems than advantages.
: Please don't throw out the existing 2-1-3 page layout. In my opinion to skip it means much more than it "Hurts our pride to give up on a 2, 1, 3 layout.". By introducing an admin specific theme many issues can be solved. Additionally theme designers have less pages to work on.
: I thought all table based page layouts should have gone in Moodle 2.0.

Themes 2.0 overflow problems

2010-10-26T20:17:11Z

UrsHunkler: Add Proposed solution 4 and my opinion

This document examines the overflow:hidden - fixed width problem currently plaguing several areas of Moodle 2.0 (as of October 26, 2010)

==The problem==

Content that is too wide for the main content area is not displayed correctly is obscured behind the side blocks or off-screen, and the browser doesn't scroll horizontally.

To see it, shrink your browser window and look at:

* http://moodle.org/mod/forum/discuss.php?d=32796

It is caused by '''oversized, unwrappable content''':

# Large images or other media of one form or another.
# Tables, any table that has numerous columns and/or large content in columns.
## Tabulated data
## Tables for internal layout (like the forum)
# Unwrappable content
## This is normally always user-entered text or images.
## Different browsers handle things differently.

==The technical description==

The cause is a combination of the fixed width that gets set on the core layout XHTML, and the overflow:hidden setting that is required by the layout.

The layout used in the base theme within Moodle is based on Matthew James Taylor's [http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm Holy grail layout] which is an excellent layout, however (and it does state this in the description of the layout) wide content is a known problem.

This problem starts on the very first div that contains content within the body *<div id="page-content">....</div>* which has the following style:

<code css>
#page-content {
clear:both;
float:left;
overflow:hidden;
position:relative;
width:100%;
min-width:900px;
}
</code>

Setting the width to 100% instantly boxes the displayable area to just the browsers internal display width, and then overflow:hidden ensures that any overflow is not visible.

This is required because the premise of this layout is to move everything out of the viewport and then move things back into the correct position and in doing this it goes as far as expanding content divs out to 200% width.

Because of this if we remove the width 100% and/or overflow hidden everything breaks because the page will ALWAYS expand beyond the browsers displayable area even if the content is easily displayed.

As far as I can see there is no way to avoid this problem while using this layout.

On the other hand there are very good reasons for using this layout:
* it is cross browser,
* columns are orderd 2,1,3 which is good for accessibility and search engine optimisation, and
* in EVERY other respect it works well

==Proposed solution 1==

A couple of days ago I sat down with Martin and explained this to him and we looked into it and came up with the following three part solution:

# Wrap format_text output within a div with a class that allows us to manage overflow. The themes can then turn on overflow:auto for these areas to make sure that user content wraps correctly (eg forum post content).
# Convert places that use tables for layout to divs (eg forum posts) so that they wrap cleanly. Without this the large user content causes the table cells to grow too large, causing wrapping issues.
# Locate places where tables are likely to require horizontal scrolling and wrap them in divs with a class like `flexible-wrap` that sets an overflow:auto so that the table is scrollable if required.

===Advantages===

# A standard way for developers and themers to deal with these issues (can go in coding guidelines)
# Will remove the possibility for users to intentionally/accidentally destroy the interface by posting large content

===Possible problems===

# Because all format_text calls will be wrapped by this special div there might be regressions throughout Moodle - we will have to review the calls and possibly disable the new wrapping divs for some of them. (For example, quiz multiple choice options are processed by format_text, then output inside a Label. The wrapping div would break that horribly.)
# Some parts of Moodle can never be made to fit in a sensible width. For example the gradebook, and other reports.
# IE6/7 (and possibly IE 8/9?) render their scrollbars INSIDE an element rather than outside like most other browsers meaning that there is a *VERY* high chance there will be redundant scrollbars within some elements that don't actually require wrapping (on these browsers)
# Elements that require scrolling will have their own scrollbars and particularly in the case of tables this is likely to require scrolling the page vertically to locate the horizontal scrollbar, scrolling horizontally and then locating the desired row vertically again.
# Elements with a set width (e.g.style="width:2000px") greater than the content area will need to be wrapped in a div with the wrapping class as well.

==Proposed solution 2==

Compromise, and use a 1, 3, 2 or 1, 2, 3 layout (with skip links for accessibility).

===Advantages===

# It can be made to work for all pages.
# We use a 1, 3, 2 at the OU, and it is reliable.

===Possible problems===

# Slightly less accessible (unless you are comparing with the current situation that actually chops off text for most users even before you start resizing fonts, and is therefore infinitely less accessible, of course).
# Hurts our pride to give up on a 2, 1, 3 layout.

==Proposed solution 3==

Add some JavaScript to the page, so that once everything has been laid out, it computes how wide the page needs to be to avoid truncation, and then changes the min-width: 900px to whatever width is needed to make the content fit.

===Advantages===

# Might be the easiest solution to implement.

===Possible problems===

# Ewwwwwww! This is clearly a horrible hack.
# JavaScript for layout is deeply evil.

==Proposed solution 4==

Use different page layouts for different needs. Admin/settings pages show very different content than the normal learning pages. Two different page layouts would solve a lot of issues. In for example WordPress and Drupal the concept of the admin theme for admin/settings pages and the "nice" theme for content is standard.

# Use an "admin theme" with flexible width and a 1-2 layout for the admin and settings pages. The huge tables are mainly on the admin pages. Most table issues would be solved this way.
# Use the existing 2-1-3 fixed width layout for all learning pages.
# Change all tables in the forum layout and other modules if existent to div layouts.
# Create a filter to display a miniature of oversized media and open the original size in a bigger overlay on click. The maximum width can be a setting in the filter to fit different theme needs.

===Advantages===

# The pages with different needs get different layouts better fitting these needs.
# One optimized admin theme can be used with many different themes. Theme designers can focus on the content pages when they work on themes.
# The flexible width admin theme helps a lot when the content shall be displayed in any fixed width page layout.
# I use an flexible width admin theme I developed for some time now with all fixed width themes and solve the table width issues on admin/settings pages. It's always the same admin theme with very different content themes.

===Possible problems===

# I see only advantages.

==Opinions==

; Tim
: I vote for 2, or failing that 3. I think 1. will not work.

; Sam
: agree with Tim except I don't think 3 is likely to be reliable either.
: http://moodle.org/mod/cvsadmin/view.php?conversationid=5929

; Frank
: IMHO the only real problem is '''2.2.Tables for internal layout (like the forum)''' and possibly 3.2. (Which, by the way, only proves that tables for layout are a bad thing, [[User:Frank Ralf/Semantic HTML3]]). Any other ''oversized, unwrappable content'' will break the layout one way or another and should be the responsibility of the author. That said, I favor solution 2; any solution which requires JavaScript (3) only makes the situation even more complex. --[[User:Frank Ralf|Frank Ralf]] 14:41, 26 October 2010 (UTC)

; Urs
: I vote for 4.
: 3 is no option - from my experience using JavaScript to correct page issues breaks every once in a while.
: 2 does not solve the table width issue in fixed width themes.
: 1 seams to offer more problems than advantages.
: Please don't throw out the existing 2-1-3 page layout. In my opinion to skip it means much more than it "Hurts our pride to give up on a 2, 1, 3 layout.". By introducing an admin specific theme many issues can be solved. Additionally theme designers have less pages to work on.
: I thought all table based page layouts should have gone in Moodle 2.0.

Chameleon theme

2008-09-18T06:31:19Z

UrsHunkler: /* Troubleshooting */ add dialog is not opening info

{{Themes}}{{Moodle 1.6}}Chameleon is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

If you find that the styles don't save, check to make sure that the files in your theme folder
are set so that your webserver has permission to modify them.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

Some sample tags:

body {
background-colour #000000;
}

- alters the background for everything apart from the blocks and topic sections

div.sideblock div.header {
background-image: url(pix/header.jpg);
}

- alters the header area of the blocks on all pages to have an image

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in the Chameleon (i.e., not the system) ''config.php'' file and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Add the 'user_styles' sheet to the list of style sheets used. Note that it must be the last one in the list.

<pre>
////////////////////////////////////////////////////////////////////////////////
/// This file contains a few configuration variables that control
/// how Moodle uses this theme.
////////////////////////////////////////////////////////////////////////////////

$THEME->sheets = array('styles_color', 'styles_font', 'styles_layout', 'styles_moz', 'user_styles' );

/// This variable is an array containing the names of all the
/// stylesheet files you want included in this theme, and in what order
////////////////////////////////////////////////////////////////////////////////
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

===Shift click does not open the Chameleon dialog===

Please check that Chameleon is turned on by checking the line in ''config.php'':

$THEME->chameleonenabled = true;

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

== Tips and Tricks ==

=== How can I change the background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but the message pages to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field with your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

=== How can I change the background of the "chat" window with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images, hides the page header and adjusts some positioning. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but not the chat window to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field with your CSS code
* Scroll to the end of your code or to a place you consider best for the chat CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#mod-chat-index table.generaltable td.c0 {
background-image: none;
}
#mod-chat-gui_header_js-chatinput #header {
display: none;
}
#mod-chat-gui_header_js-chatinput #page {
background-image: none;
}
#mod-chat-gui_header_js-chatinput {
background-image: none;
}
#mod-chat-gui_header_js-users #header {
display: none;
}
#mod-chat-gui_header_js-users #page {
background-image: none;
}
#mod-chat-gui_header_js-users {
background-image: none;
}
body#mod-chat-view div#content {
padding-top: 0;
margin-top: 0;
margin-left: 0;
}
body#mod-chat-view table#layout-table td#middle-column {
padding-top: 30px;
}
</pre>

==See also==

*[http://br.youtube.com/watch?v=lxQkLHcvmoU Video showing how to use the interactive Moodle theme, Chameleon]
*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

Usuari:Urs Hunkler

2008-08-19T08:02:45Z

UrsHunkler: typo

[[Image:urs.png|left]]

I am a web designer with my company [http://unodo.de unodo] specializing in concept, design and development of Internet-based working and learning.

The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management.

Integration of the Moodle code and the theme [[Custom Corners]] brings some Web 2.0 design opportunities to Moodle. The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.

I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.

* [[Themes]]

--[[User:UrsHunkler|UrsHunkler]] 10:00, 18 August 2008 (WST)

Usuari:Urs Hunkler

2008-08-19T08:01:59Z

UrsHunkler: Actualize my description

[[Image:urs.png|left]]

I am a web designer with my company [http://unodo.de unodo] specializing in concept, design and development of Internet-based working and learning.

The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management.

Integration of the Moodle code and the theme [[Custom Corners]] brings some Web 2.0 design opportunities to Moodle. [[The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.

I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.

* [[Themes]]

--[[User:UrsHunkler|UrsHunkler]] 10:00, 18 August 2008 (WST)

Theme settings

2008-02-08T08:07:26Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Sideblock width ==
{{Moodle 1.8}}When you need to define the side column width for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.
</nowiki></pre></code>

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages showing sideblocks. If not set Moodle uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></pre></code>

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:07:10Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Sideblock width ==
{{Moodle 1.8}}When you need to define the side column width for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.
</nowiki></pre></code>

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages showing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></pre></code>

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:05:55Z

UrsHunkler:

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Sideblock width ==
{{Moodle 1.8}}When you need to define the side column width for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.
</nowiki></pre></code>

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></pre></code>

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:04:57Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}}When you need to define the side column width for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.
</nowiki></pre></code>

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></pre></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:04:21Z

UrsHunkler: /* Sideblock width */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}}When you need to define the side column width for your themes you can add the following settings to your theme config.php.

<code><pre><nowiki>
$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.
</nowiki></pre></code>

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:03:02Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}} When you need to define the side column width for your themes you can add the following settings to your theme config.php.

$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.

==Change column order==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T08:02:13Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}} When you need to define the side column width for your themes you can add the following settings to your theme config.php.

$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.

== Change column order ==
{{Moodle 1.8}}When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><nowiki>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
<nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]</nowiki>

Theme settings

2008-02-08T07:59:32Z

UrsHunkler: /* Change column order */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}} When you need to define the side column width for your themes you can add the following settings to your theme config.php.

$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.

== Change column order ==

{{Moodle 1.8}} When you need to change the column order for your themes you can add the following settings to your theme config.php.

<code><pre>
$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');
</pre></code>

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Theme settings

2008-02-08T07:58:04Z

UrsHunkler: /* Theme priority */

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}In Moodle 1.9 onwards, category themes may be set. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority==
{{Moodle 1.9}}In Moodle 1.9 onwards, the priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

== Sideblock width ==
{{Moodle 1.8}} When you need to define the side column width for your themes you can add the following settings to your theme config.php.

$THEME->block_l_min_width = 148;
$THEME->block_l_max_width = 148;
$THEME->block_r_min_width = 260;
$THEME->block_r_max_width = 260;

/// These values define the min and max width of the left and right
/// sibelocks in the course pages. If not set or false the standard
/// values are taken.

== Change column order ==
{{Moodle 1.8}} When you need to change the column order for your themes you can add the following settings to your theme config.php.

$THEME->layouttable = array('left', 'right', 'middle');

/// These values define the order of the columns for all
/// pages shoeing sideblocks. If not set Moodel uses the
/// default order:
/// $THEME->layouttable = array('left', 'middle', 'right');

==Hide activity type navigation==
{{Moodle 1.9}}In Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

==See also==
*[http://www.youtube.com/watch?v=mCVsJ3Wsoj8 Video demonstrating how to set a category theme in Moodle 1.9]

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Broken/Web services

2007-12-23T10:07:34Z

UrsHunkler: add :: with the option to plug in AMFPHP for Flash/Flex interfaces

This page is to decide on a STANDARD list of CORE web service functions that we should support in Moodle (by XMLRPC, REST and SOAP with the option to plug in AMFPHP for Flash/Flex interfaces) as an API for those writing code to work against Moodle.

Please add new functions if there's functionality you want that isn't covered (we can refactor/whittle at the end).

==add user==
I think we should require all data needed for a successful "first login" to Moodle without popping him out the profile page to fill in all missing required data. This may require extra inputs such as city, description ... (unsure of the full list depending of Moodle version ?).
Also password should be "required" if authentication method is "internal" .

INPUT:
firstname
lastname
email
idnumber
login
authentication method (optional , default= manual ?)

OPERATION:
Adds a new user to the user database

OUTPUT:
id or false

==delete user==
INPUT:
idnumber or
email or
id or
login

OPERATION:
User is marked as deleted
All it's role assignments are destroyed
OUTPUT:
true/false

==add course==
INPUT:
name
shortname
format (default topics)
idnumber

OPERATION:
Adds a new course to the course table

OUTPUT:
id or false

==delete course==
INPUT:
name OR
shortname OR
idnumber OR
id

OPERATION:
Deletes a course from the course table
What about associated ressources, roles ...

OUTPUT:
true or false

==enrol student to course==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname)
student unique id (Moodle's ID or idnumber or login or email)

OPERATION:
Assign student role to course

OUTPUT:
true or false

==unenrol student from course==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname)
student unique id (Moodle's ID or idnumber or login or email)

OPERATION:
remove student role from course

OUTPUT:
true or false

==assign role to course==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname)
user unique id (Moodle's ID or idnumber or login or email)
role id (teacher, non editing teacher, student (?) ...)

OPERATION:
assign given user a "standard" role to given course

OUTPUT:
true or false

==remove role from course==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname)
user unique id (Moodle's ID or idnumber or login or email)
role id (teacher, non editing teacher, student (?) ...)

OPERATION:
remove given user's "standard" role from given course

OUTPUT:
true or false

==get my courses==

INPUT:
user unique id (Moodle's ID or idnumber or login or email)

OPERATION:
return a "list" of course's id in which given user move given user has some role assigned

OUTPUT:
"array" of (course id, course shortname, course fullname, role id, role name, course url)
or false in case of error (bad user id)

==get last changes in my courses==

INPUT:
user unique id (Moodle's ID or idnumber or login or email)
course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)
timestamp - optional (default = time of last connexion in every course)

OPERATION:
return a "list" of changes (resource added/modified, new activities, etc.) for courses in which given user has some role assigned - since timestamp or last connexion in given course

OUTPUT:
"array" of (course id, course shortname, course fullname, role id, role name, url of the resource/activity, time of change)
or false in case of error (bad user/course id)

==get grades==

INPUT:
user unique id (Moodle's ID or idnumber or login or email)
course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)

OPERATION:
return a "list" of grades and statistics for the given student in the given course

OUTPUT:
"array" of grades records (name,maxgrade,grade,percent,weight,weighted,sortOrder)
and "array" of stats (gradeItems,allgrades, points,totalpoints, percent, weight, weighted;)
or false in case of error (bad user/course id or user not in course)

==get groups==

OPERATION:
return a "list" of group records in a given course (or site ?)

==get group members==

OPERATION:
return a "list" of ids for members of a group (within a course or global)

==enrol to group==

OPERATION:
add a new member to a group

==unenrol from group==

OPERATION:
remove membership from a group

==get events ==

OPERATION:
return a "list" of event's identifiers suitable from the "get event" operation

==get event==

OPERATION:
return in an "exportable" format (iCal, vCal ...)an event recorded in Moodle database (site, course, private ...)

==set event==

OPERATION:
add/modify an event in Moodle database (site, course, private ...)

Theme settings

2007-10-16T13:52:07Z

UrsHunkler: /* Theme settings */ setting for category themes added

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance.

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}
You can now set category themes. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority from Moodle 1.9 on ==
{{Moodle 1.9}}
The priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}
From Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Theme settings

2007-10-16T13:46:03Z

UrsHunkler: /* Session themes */ Page theme

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes)..

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}
You can now set category themes. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

==== Page theme ====
A page theme is for special page-only themes set by code.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority from Moodle 1.9 on ==
{{Moodle 1.9}}
The priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}
From Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Theme settings

2007-10-16T13:28:15Z

UrsHunkler: /* Category themes */ typo

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes)..

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
{{Moodle 1.9}}
You can now set category themes. There is an admin setting to turn this feature on/off under "Site Administration/Appearance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority from Moodle 1.9 on ==
{{Moodle 1.9}}
The priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}
From Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Theme settings

2007-10-16T13:27:39Z

UrsHunkler: /* Course themes */ Category themes

{{Themes}}
Location: ''Administration > Appearance > Themes > Theme settings''

== Theme settings ==

*''themelist'' - This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

*''allowuserthemes'' - If you enable this, then users will be allowed to set their own themes. User themes override site themes but not course themes.

*''allowcoursethemes'' - If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes)..

*''allowuserstohideblocks''- Allows users to display and hide blocks

*''showblocksonmodulepage'' -If activity module allows blocks, this will enable a pulldown list.

*''allowcategorythemes'' - If you enable this, then themes can be set at the category level (from Moodle 1.9 onwards).

== Theme types ==

==== Site themes ====
Site themes may be previewed and chosen via Administration >> Configuration >> [[Themes]].

==== User themes ====
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the [[user/edit|Edit profile]] page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

==== Course themes ====
If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

==== Category themes ====
You can now set category themes. There is an admin setting to turn this feature on/off under "Site Administration/Apperance/Themes/Theme settings". It is off by default as it does take a bit of processing overhead. If it is switched on then you will be able to select a theme when editing categories. The theme will then apply to all courses in that category or child categories and the category page itself.

==== Session themes ====
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

== Theme overview ==

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

== Theme priority from Moodle 1.9 on ==
{{Moodle 1.9}}
The priority of themes can be set. The order defines which theme wins when there are several set at different levels. You can set a variable in config.php called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('page', 'course', 'category', 'session', 'user', 'site');</nowiki></code>

==Hide activity type navigation==
{{Moodle 1.9}}
From Moodle 1.9 onwards, the activity type (e.g. Quizzes) crumb in the navigation bar may be hidden from students or all users.

[[Category:Themes]]

[[es:Configuración de temas]]
[[fr:Configuration des thèmes]]

Theme settings

2007-10-16T13:22:29Z

UrsHunkler: /* Theme proprity from Moodle 1.9 on */ typo

Theme settings

2007-10-16T13:16:08Z

UrsHunkler: /* Theme proprity from Moodle 1.9 on */ code setting

Theme settings

2007-10-16T13:14:29Z

UrsHunkler: /* Theme overview */ Theme priority from 1.9 on

Plantilla:Themes

2007-04-11T15:27:35Z

UrsHunkler: 1.8 theme upgrade page added

<div class="sideblock right">
<div class="header">[[Themes]]</div>
<div class="content">
* [[Theme basics]]
* [[Theme reference]]
* [[1.5 theme upgrade]]
* [[1.6 theme upgrade]]
* [[1.7 theme upgrade]]
* [[1.8 theme upgrade]]
* [[Theme config|Theme configuration]]
* [[Theme directory|Theme directory]]
* [[Theme scrapbook]]
* [[Theme sources|Sources]]
* [[Standards]]
* [[W3C validation]]
</div>
</div>

Header logo

2007-03-25T12:28:33Z

UrsHunkler: space removed

{{Scrapbook}}

To show your '''logo in the page header''', the file ''header.html'' in your theme folder requires editing.

In the file ''header.html'' you see the following lines (or similar):

<pre>
01: <?php if ($home) {
02: // This is what gets printed on the home page only
03: ?>
04: <div id="header-home">
05: <div class="headermain"><?php echo $heading ?></div>
06: <div class="headermenu"><?php echo $menu ?></div>
07: </div>
08: <?php } else if ($heading) {
09: // This is what gets printed on any other page with a heading
10: ?>
11: <div id="header">
12: <div class="headermain"><?php echo $heading ?></div>
13: <div class="headermenu"><?php echo $menu ?></div>
14: </div>
15: <?php } ?>
</pre>

The following code example shows a part from a header file with a logo. Please replace lines 5 and 12 above with lines 5 and 12 from the code example below. In particular, pay close attention to the statement <?php echo $CFG->httpswwwroot.'/theme/'.current_theme() ?>/image.jpg. Some theme designers have mistakenly used <?php echo "$CFG->wwwroot/theme/$CFG->theme/image.jpg" ?>. Using $CFG->theme gets the path for the site's default theme rather than the currently selected one. As a result, logos do not appear because they are not in the specified directory. $CFG->wwwroot images throw unsecure warning in IE when using loginhttps.

<pre>
01: <?php if ($home) {
02: // This is what gets printed on the home page only
03: ?>
04: <div id="header-home">
05: <div class="headermain"><img src="<?php echo
$CFG->themewww.'/'.current_theme() ?>/pix/big_logo.gif" width="300"
height="100" alt="mycompany" title="mycompany" id="logo" /></div>
06: <div class="headermenu"><?php echo $menu ?></div>
07: </div>
08: <?php } else if ($heading) {
09: // This is what gets printed on any other page with a heading
10: ?>
11: <div id="header">
12: <div class="headermain"><img src="<?php echo
$CFG->themewww.'/'.current_theme() ?>/pix/small_logo.gif" width="210"
height="70" alt="mycompany" title="mycompany" id="logo" /></div>
13: <div class="headermenu"><?php echo $menu ?></div>
14: </div>
15: <?php } ?>
</pre>

Moodle offers one header for all pages and a different header for the front/home page. You may, for example, make the header for your front page higher and place a bigger logo on it.

The logo position in the page header is defined in the CSS file ''styles_layout.css''. Please change the values for the CLASS <code>.headermain</code> and eventually for the IDs <code>#header</code> and <code>#header-home</code> if needed. You can find the definitions in the section header of the CSS file.

'''A tip for a fast jump to the header section of the CSS file:''' Select and copy the word "header" in the section list at the beginning of the file. Then call find in your program and paste "header" into the search dialogue. After you click "find" in your dialogue your program will find the start of the header section.

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Header logo

2007-03-25T12:27:34Z

UrsHunkler: links changed to show "themewww .'/'."

{{Scrapbook}}

To show your '''logo in the page header''', the file ''header.html'' in your theme folder requires editing.

In the file ''header.html'' you see the following lines (or similar):

<pre>
01: <?php if ($home) {
02: // This is what gets printed on the home page only
03: ?>
04: <div id="header-home">
05: <div class="headermain"><?php echo $heading ?></div>
06: <div class="headermenu"><?php echo $menu ?></div>
07: </div>
08: <?php } else if ($heading) {
09: // This is what gets printed on any other page with a heading
10: ?>
11: <div id="header">
12: <div class="headermain"><?php echo $heading ?></div>
13: <div class="headermenu"><?php echo $menu ?></div>
14: </div>
15: <?php } ?>
</pre>

The following code example shows a part from a header file with a logo. Please replace lines 5 and 12 above with lines 5 and 12 from the code example below. In particular, pay close attention to the statement <?php echo $CFG->httpswwwroot.'/theme/'.current_theme() ?>/image.jpg. Some theme designers have mistakenly used <?php echo "$CFG->wwwroot/theme/$CFG->theme/image.jpg" ?>. Using $CFG->theme gets the path for the site's default theme rather than the currently selected one. As a result, logos do not appear because they are not in the specified directory. $CFG->wwwroot images throw unsecure warning in IE when using loginhttps.

<pre>
01: <?php if ($home) {
02: // This is what gets printed on the home page only
03: ?>
04: <div id="header-home">
05: <div class="headermain"><img src="<?php echo
$CFG->themewww .'/'.current_theme() ?>/pix/big_logo.gif" width="300"
height="100" alt="mycompany" title="mycompany" id="logo" /></div>
06: <div class="headermenu"><?php echo $menu ?></div>
07: </div>
08: <?php } else if ($heading) {
09: // This is what gets printed on any other page with a heading
10: ?>
11: <div id="header">
12: <div class="headermain"><img src="<?php echo
$CFG->themewww .'/'.current_theme() ?>/pix/small_logo.gif" width="210"
height="70" alt="mycompany" title="mycompany" id="logo" /></div>
13: <div class="headermenu"><?php echo $menu ?></div>
14: </div>
15: <?php } ?>
</pre>

Moodle offers one header for all pages and a different header for the front/home page. You may, for example, make the header for your front page higher and place a bigger logo on it.

The logo position in the page header is defined in the CSS file ''styles_layout.css''. Please change the values for the CLASS <code>.headermain</code> and eventually for the IDs <code>#header</code> and <code>#header-home</code> if needed. You can find the definitions in the section header of the CSS file.

'''A tip for a fast jump to the header section of the CSS file:''' Select and copy the word "header" in the section list at the beginning of the file. Then call find in your program and paste "header" into the search dialogue. After you click "find" in your dialogue your program will find the start of the header section.

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Metacourse

2007-03-21T11:27:18Z

UrsHunkler: typo

A '''metacourse''' automatically enrolls participants from other "child" courses. For example, each time a student enrols in (or unenrols from) a course, they are enrolled/unenrolled from any metacourse(s) associated with it.

Please note that metacourse enrolments do not preserve groups and enrolment does not happen immediately.

==Metacourse setup==
Teachers are able to choose whether a course is a metacourse via the "Is this a metacourse?" (yes/no) menu option in the [[Course settings|course settings]]. In Moodle 1.5 and 1.6, if a meta course is chosen, the [[Students|students]] page changes from listing/searching for students to listing/searching for courses. In Moodle 1.7 "Child courses" appears in the teacher's administration block.

==Metacourse examples==
Metacourses may be used in a variety of ways:

* '''Scenario 1:''' X is a metacourse with Course 1 through 4 as normal courses with standard student enrollments. Students enrolling on these courses are automatically enrolled onto Metacourse X. This would be used, for example, when every student gets to choose one option from Courses 1-4 but Metacourse X is compulsory for all students taking one of those four options.

[[Image:Metacourses1_en.jpg|Standard Metacourse Usage]]

* '''Scenario 2:''' Metacourses 1-4 are linked to Y which is a normal course. Students enrolling on Course Y are automatically enrolled on Metacourses 1-4. This would be used, for example, when all five courses are intended to have exactly the same students.

[[Image:Metacourses2_en.jpg|Upsidedown Metacourse Usage]]

In both diagrams you can see students being enrolled normally into standard courses and then the entire student list of a course being added to the Metacourse.

* '''Scenario 3:''' One or more meta courses are used as a library of resources and activities. For example, the English department has collected material useful in writing papers. Teachers can direct or embed a link to a specific reference about citations, or how to select a topic for a paper or suggested reading compiled by students.

* '''Scenario 4:''' The metacourse feature can also be used "in reverse." Say you have a Diploma program that involves courses D1, D2, D3, and D4. In this case, you would create a "Diploma" course as a normal course (non-metacourse). You would then designate programs D1 through D4 as metacourses (plus completing the student enrollment task under Course Administration). When a student enrolls in "Diploma", he or she will be automatically enrolled in courses D1 through D4.

==See also==
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=48901 Metacourses?], [http://moodle.org/mod/forum/discuss.php?d=54389 Metacourses and Roles in 1.7] and [http://moodle.org/mod/forum/discuss.php?d=39438 Best reference for describing a metacourse] forum discussions

[[Category:Teacher]]
[[Category:Enrolment]]

[[es:Metacourses]]
[[fr:Méta-cours]]
[[ru:Метакурсы]]

Cron

2007-01-09T14:17:25Z

UrsHunkler: typo

Some of Moodle's modules require continual checks to perform tasks. For example, Moodle needs to check the discussion forums so it can mail out copies of posts to people who have subscribed.

The script that does all this is located in the admin directory, and is called cron.php. However, it can not run itself, so you need to set up a mechanism where this script is run regularly (eg every five or ten minutes). This provides a "heartbeat" so that the script can perform functions at periods defined by each module. This kind of regular mechanism is known as a '''cron service'''.

The cron.php script looks through all the module directories for cron.php files and runs them. These files can contain cleanup functions, email functions or anything that needs to be run on a regular basis. For example, cron will trigger the system to create the backups of courses at the time specified in the administration settings. It also triggers any messaging module or forum email notifications, but not all functions are called each time the cron runs. Some functions, such as unenrolling students who have not logged in or deleting old copies of log files, are only run occasionally. The cron.php file has a section which will randomly call these core tasks approximately 1 in 5 times the cron runs.

Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.

The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.

First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''

If cron is called from the command line by any user logged in to your Moodle it will create a temporary admin environment in order to run and then log the user out. You can disable command line running of cron by disabling the appropriate section in the cron.php file.

Now, you need to set up some of way of running the script automatically and regularly.

==On Windows systems==

The simplest way is to use this little package [http://moodle.org/download/modules/moodle-cron-for-windows.zip moodle-cron-for-windows.zip] which makes this whole thing very easy by installing a small Windows service. Run it and forget about it! :-)

On the other hand, if you are having trouble with moodle-cron-for-windows package, you can use wget for windows and setup a scheduled task. Just follow these steps:

# Download a compiled version of wget for windows from Heiko Herold's wget for windows page (http://xoomer.virgilio.it/hherold/) or Bart Puype's wget for windows page (http://users.ugent.be/~bpuype/wget/). If you use Heiko Herold's package, copy all of the .DLL files to your C:\Windows\system32 directory.
# Copy the wget.exe file to c:\windows (this makes sure wget is always in the search path).
# Go to Start >> Control Panel >> Scheduled Tasks >> Add Scheduled Task.
## Click "Next" to start the wizard:
## Click in the "Browse..." button and browse to C:\windows\wget.exe and click "Open"
## Type "Moodle Cron" as the name of the task and select "Daily" as the schedule. Click "Next".
## Select "12:00 AM" as the start time, perform the task "Every Day" and choose today's date as the starting date. Click "Next".
## Enter the username and password of the user the task will run under (it doesn't have to be a priviledged account at all). Make sure you type the password correctly :-). Click "Next".
## Mark the checkbox titled "Open advanced properties for this task when I click Finish" and click "Finish".
## In the new dialog box, type the following in the "Run:" text box:<pre><nowiki>
C:\windows\wget.exe -q -O NUL http://my.moodle.site/moodle/admin/cron.php
</nowiki></pre>
## Replace "my.moode.site" above with the name of your site.
## Click on the "Schedule" tab and there in the "Advanced..." button.
## Mark the "Repeat task" checkbox and set "Every:" to 5 minutes, and set "Until:" to "Duration" and type "23" hours and "59" minutes.
## Click "OK" and you are done.

A third option, if wget is also causing difficulties, is to use php.exe (command line binary). If you are using the windows installer package, you already have this. Follow the sceduled tasks instructions above, but in the 'run' box, enter

php cron.php

and in the 'Start in:' box type the path to your moodle admin directory e.g.

C:\path-to-moodle\admin\

You can test that your scheduled task can run successfully by clicking it with the right button and chosing "Run". If everything is correctly setup, you will briefly see a DOS command window while wget/php executes and fetches the cron page and then it disappears.

If you refresh the scheduled tasks folder, you will see the Last Run Time column (in detailed folder view) reflects the current time, and that the Last Result column displays "0x0" (everything went OK). If either of these is different, then you should recheck your setup.

==On web hosting services==

Your web-based control panel may have a web page that allows you to set up this cron process.

If you are using CPanel, login then look for the heading "Advanced" on the page. Click on Cron Jobs -> Advanced (unix style). Enter the following for the cron to run every 30 minutes.

Email address for output: emailaddress@mydomain.con
Minute:*/30
Hour:*
Day:*
Month:*
Weekday:*
Command: wget -q -O /dev/null http://www.mydomain.com/moodle/admin/cron.php

Click Commit Changes. Check your email for the output. An example is shown below:

[[Image:Cpanel-cron-setup.JPG]]

For other systems, look for a button called "Cron jobs". In there you can put the same sort of Unix commands as listed below.

==Using the command line on Unix==

There are different command line programs you can use to call the page from the command line. Not all of them may be available on a given server.

For example, you can use a Unix utility like 'wget':

wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

Note in this example that the output is thrown away (to /dev/null).

A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:

php <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

The same thing using lynx:

lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null

Note in this example that the output is thrown away (to /dev/null).

Alternatively you could use a standalone version of PHP, compiled to be run on the command line. The advantage with doing this is that your web server logs aren't filled with constant requests to cron.php. The disadvantage is that you need to have access to a command-line version of php.

/opt/bin/php /web/moodle/admin/cron.php

==Using the crontab program on Unix==

All that Cpanel does is provide a web interface to a Unix utility known as crontab. If you have a command line, you can set up crontab yourself using the command:

crontab -e

and then adding one of the above commands like:

*/5 * * * * wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

The first five entries are the times to run values, followed by the command to run. The asterisk is a wildard, indicating any time. The above example means run the command ''wget -q -O /dev/null...'' every 5 minutes (*/5), every hour (*), every day of the month (*), every month (*), every day of the week (*).

* [http://linuxweblog.com/node/24 A basic crontab tutorial]
* [http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Online version of the man page]

Usually, the "crontab -e" command will put you into the 'vi' editor. You enter "insert mode" by pressing "i", then type in the line as above, then exit insert mode by pressing ESC. You save and exit by typing ":wq", or quit without saving using ":q!" (without the quotes). Here is an [http://www.unix-manuals.com/tutorials/vi/vi-in-10-1.html intro] to the 'vi' editor.

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?] forum discussion

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

[[es:Cron]]
[[fr:Cron]]
[[nl:Cron]]

Usuari:Urs Hunkler

2006-11-28T19:48:01Z

UrsHunkler: changed picture link

[[Image:urs.png|left]]

I am a web designer specializing in Internet-based working and learning. And I am a Moodle Partner with my company [http://unodo.de unodo].

The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management.

The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.

I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.

* [[Themes]]

--[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)

Chameleon theme

2006-10-20T06:18:40Z

UrsHunkler: /* How can I change the background of the "chat" window with Chameleon? */ typo

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

== Tips and Tricks ==

=== How can I change the background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but the message pages to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field with your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

=== How can I change the background of the "chat" window with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images, hides the page header and adjusts some positioning. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but not the chat window to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field with your CSS code
* Scroll to the end of your code or to a place you consider best for the chat CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#mod-chat-index table.generaltable td.c0 {
background-image: none;
}
#mod-chat-gui_header_js-chatinput #header {
display: none;
}
#mod-chat-gui_header_js-chatinput #page {
background-image: none;
}
#mod-chat-gui_header_js-chatinput {
background-image: none;
}
#mod-chat-gui_header_js-users #header {
display: none;
}
#mod-chat-gui_header_js-users #page {
background-image: none;
}
#mod-chat-gui_header_js-users {
background-image: none;
}
body#mod-chat-view div#content {
padding-top: 0;
margin-top: 0;
margin-left: 0;
}
body#mod-chat-view table#layout-table td#middle-column {
padding-top: 30px;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T06:18:20Z

UrsHunkler: /* How can I change the background of the "messages" with Chameleon? */ typo

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

== Tips and Tricks ==

=== How can I change the background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but the message pages to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field with your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

=== How can I change the background of the "chat" window with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images, hides the page header and adjusts some positioning. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but not the chat window to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the chat CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#mod-chat-index table.generaltable td.c0 {
background-image: none;
}
#mod-chat-gui_header_js-chatinput #header {
display: none;
}
#mod-chat-gui_header_js-chatinput #page {
background-image: none;
}
#mod-chat-gui_header_js-chatinput {
background-image: none;
}
#mod-chat-gui_header_js-users #header {
display: none;
}
#mod-chat-gui_header_js-users #page {
background-image: none;
}
#mod-chat-gui_header_js-users {
background-image: none;
}
body#mod-chat-view div#content {
padding-top: 0;
margin-top: 0;
margin-left: 0;
}
body#mod-chat-view table#layout-table td#middle-column {
padding-top: 30px;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T05:01:18Z

UrsHunkler: Added "Tips and Tricks" section

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

== Tips and Tricks ==

=== How can I change the background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but the message pages to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

=== How can I change the background of the "chat" window with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images, hides the page header and adjusts some positioning. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but not the chat window to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the chat CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#mod-chat-index table.generaltable td.c0 {
background-image: none;
}
#mod-chat-gui_header_js-chatinput #header {
display: none;
}
#mod-chat-gui_header_js-chatinput #page {
background-image: none;
}
#mod-chat-gui_header_js-chatinput {
background-image: none;
}
#mod-chat-gui_header_js-users #header {
display: none;
}
#mod-chat-gui_header_js-users #page {
background-image: none;
}
#mod-chat-gui_header_js-users {
background-image: none;
}
body#mod-chat-view div#content {
padding-top: 0;
margin-top: 0;
margin-left: 0;
}
body#mod-chat-view table#layout-table td#middle-column {
padding-top: 30px;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T04:59:40Z

UrsHunkler: How can I change the background of the "chat" window with Chameleon?

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

=== How can I change the background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but the message pages to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

=== How can I change the background of the "chat" window with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images, hides the page header and adjusts some positioning. You may change the properties to get different colours or whatever you want.

* You may click anywhere on any page but not the chat window to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the chat CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#mod-chat-index table.generaltable td.c0 {
background-image: none;
}
#mod-chat-gui_header_js-chatinput #header {
display: none;
}
#mod-chat-gui_header_js-chatinput #page {
background-image: none;
}
#mod-chat-gui_header_js-chatinput {
background-image: none;
}
#mod-chat-gui_header_js-users #header {
display: none;
}
#mod-chat-gui_header_js-users #page {
background-image: none;
}
#mod-chat-gui_header_js-users {
background-image: none;
}
body#mod-chat-view div#content {
padding-top: 0;
margin-top: 0;
margin-left: 0;
}
body#mod-chat-view table#layout-table td#middle-column {
padding-top: 30px;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T04:53:48Z

UrsHunkler: /* How can I change background of the "messages" with Chameleon? */

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

=== How can I change background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You may change the properties to get different colours or whatever you want.

* You may click anywhere on the page to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T04:53:19Z

UrsHunkler: /* How can I change background of the "messages" with Chameleon? */ typo

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

=== How can I change background of the "messages" with Chameleon? ===

Not in the way you are used with a click on the page area you want to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You can change the properties to get different colours or whatever you want.

* You may click anywhere on the page to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T04:52:28Z

UrsHunkler: /* How can I change background of the "messages" with Chameleon? */ typos

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

=== How can I change background of the "messages" with Chameleon? ===

Not in the way you are used with the click on the page area to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You can change the properties to get different colours or whatever you want.

* You may click anywhere on the page to open the Chameleon dialogue
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the selectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Chameleon theme

2006-10-20T04:51:02Z

UrsHunkler: change message CSS with Chameleon

{{Moodle 1.6}}
'''Chameleon''' is an interactive Moodle theme. You are welcome to try it at the [http://chameleon-theme.unodo.de/ Chameleon theme test site] - please login with username and password "chameleon".

==How does Chameleon change its colours?==

* Shift-click anywhere on the page to open a floating window showing all elements under the mouse
* Click on elements in the list to create a CSS selector - one or as many as you need
* Click on the "Set Styles" button and set the styles of your choice
* View the changes immediately

Chameleon allows almost complete control over styling elements in Moodle. It makes working with themes easier for theme designers and opens up a wide range of experimental uses for interface designers. Just change and work with the changed page and go on optimizing your theme whilst you work with Moodle.

Chameleon makes use of [[Ajax]] technologies.

==Which tags to change==

The easy way to find this out is to use [[Firefox]] with the [[Web developer extension]] installed. You can then press Ctrl-Shift-Y to change your mouse cursor to crosshairs so that whatever you hover over, it displays the CSS information (e.g. div#content) in the status bar at the bottom of the browser page.

When changing tags, be aware that chameleon sometimes doesn't see things if you initially add them via free-edit. Use the built-in editor in the 'set styles' or 'overview' section first, then use free-edit to alter them.

==Saving your changes==

As you work, you have the option to save changes in a temporary file, or save them to the theme CSS file on the server. All temporarily saved changes may be reverted.

==Once your theme is completed==

Chameleon does a lot of work behind the scenes as the page loads. This extra work can slow down the display of the page, particularly as your theme files grow bigger. Once your theme is completed and there is no need to be running the Chameleon interface, you may disable the interactive theme by editing the line in ''config.php'':

$THEME->chameleonenabled = true;

and changing <code>true</code> to <code>false</code>.

Now, no extra code will be run on page load and your customised theme will behave exactly like any other Moodle theme. (Please note that this only applies to editing users - a non-editing user will never have any of the extra code running when they view a page.)

==Alternative uses==

In addition to creating a complete theme, Chameleon may also be used to help make changes to your existing theme. Simply experiment with Chameleon until you have achieved the change you desire, then copy the css in the "Free Edit" tab to a style sheet in your theme folder.

== Adding the Chameleon "engine" to your theme ==

You may add the Chameleon engine to any existing theme as follows:

* Copy the "ui" folder from the Chameleon theme folder to your theme folder.

* Copy the two files ''temp_user_styles.css'' and ''user_styles.css'' from your Chameleon folder to your theme folder. Set write permissions for these two files that PHP can write the changed CSS properties to the files. You may choose to delete all CSS properties in these files if you want to start from scratch.

* Add the include line in ''header.html'' (line 9):

<pre>
7 <link rel="shortcut icon" href="<?php echo
$CFG->wwwroot.'/theme/'.current_theme() ?>/favicon.ico" />
8
9 <?php include('ui/chameleon.php'); ?>
10 <?php include("$CFG->javascript"); ?>
11 </head>
12
</pre>

* Add the Chameleon vars in ''config.php'' and set them (line 99 to 109):

<pre>
89
90 $THEME->makenavmenulist = false;
91
92 /// By setting this to true, then you will have access to a
93 /// new variable in your header.html and footer.html called
94 /// $navmenulist ... this contains a simple XHTML menu of
95 /// all activities in the current course, mostly useful for
96 /// creating popup navigation menus and so on.
97
98
99 $THEME->chameleonenabled = true;
100
101 /// By setting this to false it disables editing of the stylesheets
102 /// this saves the overhead of loading chameleon on each page
103 /// viewed by a user who can edit pages. it is recommended to
104 /// set this to false once you're satisfied with your theme.
105
106 $THEME->chameleonteachereditenabled = false;
107
108 /// If you use chameleon as a course theme setting this to true
109 /// will allow teachers on that course to edit the theme.
110
</pre>

Then you can start working on your CSS for any Moodle page from your browser.

You can see and add CSS properties of the two files ''temp_user_styles.css'' and ''user_styles.css''. You can't see or change the CSS properties in your other CSS files in your theme folder.

==Troubleshooting==

=== Your changes are lost on page reload ===

The user settings or write permissions of the two CSS files "user_styles.css" and "temp_user_styles.css" must be set in a way that Moodle can write the changed CSS to these files.

# When you are able to change the owner of these files please do that. Your web server will run under a specific user like "nobody" or "www-data". Please change the owner of these CSS files to the owner your web server runs with.
# When you can't change the file owner please change the write permissions of these files. The easy way is to give write permissions to "group" and "others".

If you can please change the owner because it is more secure than giving write permission to anybody.

=== How can I change background of the "messages" with Chameleon? ===

Not in the way you are used with the click on the page area to change. Some areas of Moodle are not accessible with Chameleon. You may add the message CSS selectors and their properties below in Chameleon with copy and paste. The CSS below mainly disables background images. You can change the properties to get different colours or whatever you want.

* You may click anywhere on the page to open the Chameleon dialog
* Click on the "Free Edit" button to open the edit field of your CSS code
* Scroll to the end of your code or to a place you consider best for the message CSS
* Copy the slectors/properties below and paste them into the edit field
* Save as usual with "Save Temp" if you want to check the changes first or with "Save Server"

<pre>
body#message-user {
background-image: none;
}
body#message-messages {
background-image: none;
}
body#message-send {
background-image: none;
}
body#message-user div#content {
margin-top: 0;
padding-top: 0;
}
body#message-user div#header {
display: none;
}
</pre>

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=37674 Chameleon - an interactive Moodle theme] forum discussion
*[http://moodle.org/mod/forum/discuss.php?d=37680 Link font size bigger] forum discussion illustrating an alternative use

[[Category:Administrator]]
[[Category:Developer]]
[[Category:Themes]]

Table of locales

2006-09-30T15:52:24Z

UrsHunkler: /* Support in operating systems */ start webserver after locale install

__NOTOC__
==Introduction==
'''Definition:''' (from [http://en.wikipedia.org/wiki/Locale Wikipedia]) Locale is a set of parameters that defines the user's language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier.

Currently such locales are named differently under Unix-based and Win32-based platforms so we need to have them defined separately to allow Moodle to use them as necessary. For each '''lang package''' available for Moodle, we must specify the '''locale''' value (Unix locale) and the ''localewin''' value (Win32 locale). Both those strings should be (no mandatory) defined inside each Moodle 1.6 and upwards langpack to be able to display locale strings properly.

The general syntax for locales is:

language[_country][.charset]

(with information under brackets being optional)

While the '''.charset''' part seems to work properly under Unix, it seems that is not working under Win32 (at least from PHP), and strings returned from some PHP functions aren't in the charset specified but in some sort of default charset. Let's call it '''localewincharset'''. This forces us to convert from this charset to the current_charset() being used by the user.

==Support in operating systems==
Just in case you freshly installed some new locales and they don't seem to work don't forget to restart your webserver.

===openSUSE===
* SUSE linux 10.1 contains all necessary locales in default installation

===Ubuntu based===
The default installation contains only limited number of locales. You can generate all locales on server from command line:

sudo ln -s /usr/share/i18n/SUPPORTED /var/lib/locales/supported.d/all
sudo locale-gen

===Debian based===
The default installation contains only a limited number of locales. You can generate the locales you need on your server from the command line. Login as root and execute:

dpkg-reconfigure locales

choose the ones you need and press OK, next select the default locale for your server and press OK.

===FreeBSD===
All 5.x and later versions should already contain a large number of supported locales with utf-8 charset.

===MS Windows===
There is no way to add new locales, see following table for list of supported locales.

==Table==

So, for each 1.6 Moodle language pack, we'll describe below this columns:
* '''package_name:''' name of the language pack as showed in http://download.moodle.org/lang16/.
* '''lang_name:''' name of the language as showed in http://download.moodle.org/lang16/.
* '''locale:''' locale string to be used under Unix platforms. This will be stored in each language '''langconfig.php''' file.
* '''localewin:''' locale string to be used under Win32 platforms. This will be stored in each language '''langconfig.php''' file.
* '''localewincharset:''' charset in which PHP is retrieving information from locale-dependent functions (strftime...). This will allow us to convert such strings to the final charset properly. This will be stored in each language '''langconfig.php''' file.

<table align="center" border="1" cellpadding="5">
<tr>
<th>'''package_name'''</th>
<th>'''lang_name'''</th>
<th>'''locale'''</th>
<th>'''localewin'''</th>
<th>'''localewincharset</th></tr>
<tr>
<td>af_utf8</td>
<td>Afrikaans</td>
<td>af_ZA.UTF-8</td>
<td>Afrikaans_South Africa.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>sq_utf8</td>
<td>Albanian</td>
<td>sq_AL.UTF-8</td>
<td>Albanian_Albania.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>ar_utf8</td>
<td>Arabic</td>
<td>ar_SA.UTF-8</td>
<td>Arabic_Saudi Arabia.1256</td>
<td>WINDOWS-1256</td></tr>
<tr>
<td>eu_utf8</td>
<td>Basque</td>
<td>eu_ES.UTF-8</td>
<td>Basque_Spain.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>be_utf8</td>
<td>Belarusian</td>
<td>be_BY.UTF-8</td>
<td>Belarusian_Belarus.1251</td>
<td>WINDOWS-1251</td></tr>
<tr>
<td>bs_utf8</td>
<td>Bosnian</td>
<td>bs_BA.UTF-8</td>
<td><span style="color:red">Serbian (Latin)</span></td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>bg_utf8</td>
<td>Bulgarian</td>
<td>bg_BG.UTF-8</td>
<td>Bulgarian_Bulgaria.1251</td>
<td>WINDOWS-1251</td></tr>
<tr>
<td>ca_utf8</td>
<td>Catalan</td>
<td>ca_ES.UTF-8</td>
<td>Catalan_Spain.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>hr_utf8</td>
<td>Croatian</td>
<td>hr_HR.UTF-8</td>
<td>Croatian_Croatia.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>zh_cn_utf8</td>
<td>Chinese (Simplified)</td>
<td>zh_CN.UTF-8</td>
<td>Chinese_China.936</td>
<td>CP936</td></tr>
<tr>
<td>zh_tw_utf8</td>
<td>Chinese (Traditional)</td>
<td>zh_TW.UTF-8</td>
<td>Chinese_Taiwan.950</td>
<td>CP950</td></tr>
<tr>
<td>cs_utf8</td>
<td>Czech</td>
<td>cs_CZ.UTF-8</td>
<td>Czech_Czech Republic.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>da_utf8</td>
<td>Danish</td>
<td>da_DK.UTF-8</td>
<td>Danish_Denmark.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>nl_utf8</td>
<td>Dutch</td>
<td>nl_NL.UTF-8</td>
<td>Dutch_Netherlands.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>en_utf8</td>
<td>English</td>
<td>en.UTF-8</td>
<td>English_Australia.1252</td>
<td>-empty string-</td></tr>
<tr>
<td>en_us_utf8</td>
<td>English (US)</td>
<td>-parent en_utf8 used-</td>
<td>-parent en_utf8 used-</td>
<td>-parent en_utf8 used-</td></tr>
<tr>
<td>et_utf8</td>
<td>Estonian</td>
<td>et_EE.UTF-8</td>
<td>Estonian_Estonia.1257</td>
<td>WINDOWS-1257</td></tr>
<tr>
<td>fa_utf8</td>
<td>Farsi</td>
<td>fa_IR.UTF-8</td>
<td>Farsi_Iran.1256</td>
<td>WINDOWS-1256</td></tr>
<tr>
<td>fil_utf8</td>
<td>Filipino</td>
<td>ph_PH.UTF-8</td>
<td><span style="color:red">Filipino_Philippines.1252</span></td>
<td><span style="color:red">WINDOWS-1252</span></td></tr>
<tr>
<td>fi_utf8</td>
<td>Finnish</td>
<td>fi_FI.UTF-8</td>
<td>Finnish_Finland.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>fr_utf8</td>
<td>French</td>
<td>fr_FR.UTF-8 ''or''<br />fr_CH.UTF-8 ''or''<br />fr_BE.UTF-8</td>
<td>French_France.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>fr_ca_utf8</td>
<td>French (Canada)</td>
<td>fr_CA.UTF-8</td>
<td>-parent fr_utf8 used-</td>
<td>-parent fr_utf8 used-</td></tr>
<tr>
<td>ga_utf8</td>
<td>Gaelic</td>
<td>ga.UTF-8</td>
<td><span style="color:red">Gaelic; Scottish Gaelic</span></td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>gl_utf8</td>
<td>Gallego</td>
<td>gl_ES.UTF-8</td>
<td>Galician_Spain.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>ka_utf8</td>
<td>Georgian</td>
<td>ka_GE.UTF-8</td>
<td><span style="color:red">Georgian_Georgia.65001</span></td>
<td>-empty string-</td></tr>
<tr>
<td>de_utf8</td>
<td>German</td>
<td>de_DE.UTF-8</td>
<td>German_Germany.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>de_du_utf8</td>
<td>German (Personal)</td>
<td>de_DE.UTF-8</td>
<td>-parent de_utf8 used-</td>
<td>-parent de_utf8 used-</td></tr>
<tr>
<td>el_utf8</td>
<td>Greek</td>
<td>el_GR.UTF-8</td>
<td>Greek_Greece.1253</td>
<td>WINDOWS-1253</td></tr>
<tr>
<td>he_utf8</td>
<td>Hebrew</td>
<td>he_IL.utf8</td>
<td>Hebrew_Israel.1255</td>
<td>WINDOWS-1255</td></tr>
<tr>
<td>hi_utf8</td>
<td>Hindi</td>
<td>hi_IN.UTF-8</td>
<td><span style="color:red">Hindi.65001</span></td>
<td>-empty string-</td></tr>
<tr>
<td>hu_utf8</td>
<td>Hungarian</td>
<td>hu.UTF-8</td>
<td>Hungarian_Hungary.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>is_utf8</td>
<td>Icelandic</td>
<td>is_IS.UTF-8</td>
<td>Icelandic_Iceland.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>id_utf8</td>
<td>Indonesian</td>
<td>id_ID.UTF-8</td>
<td>Indonesian_indonesia.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>it_utf8</td>
<td>Italian</td>
<td>it_IT.UTF-8</td>
<td>Italian_Italy.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>ja_utf8</td>
<td>Japanese</td>
<td>ja_JP.UTF-8</td>
<td>Japanese_Japan.932</td>
<td>CP932</td></tr>
<tr>
<td>kn_utf8</td>
<td>Kannada</td>
<td>kn_IN.UTF-8</td>
<td><span style="color:red">Kannada.65001</span></td>
<td>-empty string-</td></tr>
<tr>
<td>km_utf8</td>
<td>Khmer</td>
<td>km_KH.UTF-8</td>
<td><span style="color:red">Khmer.65001</span></td>
<td>-empty string-</td></tr>
<tr>
<td>ko_utf8</td>
<td>Korean</td>
<td>ko_KR.UTF-8</td>
<td>Korean_Korea.949</td>
<td>EUC-KR</td></tr>
<tr>
<td>lt_utf8</td>
<td>Lithuanian</td>
<td>lt_LT.UTF-8</td>
<td>Lithuanian_Lithuania.1257</td>
<td>WINDOWS-1257</td></tr>
<tr>
<td>lv_utf8</td>
<td>Latvian</td>
<td>lat.UTF-8</td>
<td>Latvian_Latvia.1257</td>
<td>WINDOWS-1257</td></tr>
<tr>
<td>ml_utf8</td>
<td>Malayalam</td>
<td>ml_IN.UTF-8</td>
<td><span style="color:red">Malayalam_India.x-iscii-ma</span></td>
<td><span style="color:red">x-iscii-ma</span></td></tr>
<tr>
<td>ms_utf8</td>
<td>Malaysian</td>
<td>id_ID.UTF-8</td>
<td><span style="color:red">Indonesian_indonesia.1252</span></td>
<td><span style="color:red">WINDOWS-1252</span></td></tr>
<tr>
<td>mi_tn_utf8</td>
<td>Maori (Ngai Tahu)</td>
<td>mi_NZ.UTF-8</td>
<td><span style="color:red">Maori.1252</span></td>
<td><span style="color:red">WINDOWS-1252</span></td></tr>
<tr>
<td>no_utf8</td>
<td>Norwegian</td>
<td>no_NO.UTF-8</td>
<td>Norwegian_Norway.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>undefined</td>
<td>Norwegian (Primary)</td>
<td>no_NO.UTF-8</td>
<td>-parent no_utf8 used-</td>
<td>-parent no_utf8 used-</td></tr>
<tr>
<td>nn_utf8</td>
<td>Nynorsk</td>
<td>nn_NO.UTF-8</td>
<td>Norwegian-Nynorsk_Norway.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>pl_utf8</td>
<td>Polish</td>
<td>pl.UTF-8</td>
<td>Polish_Poland.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>pt_utf8</td>
<td>Portuguese</td>
<td>pt_PT.UTF-8</td>
<td>Portuguese_Portugal.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>pt_br_utf8</td>
<td>Portuguese (Brazil)</td>
<td>pt_BR.UTF-8</td>
<td>Portuguese_Brazil.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>ro_utf8</td>
<td>Romanian</td>
<td>ro_RO.UTF-8</td>
<td>Romanian_Romania.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>ru_utf8</td>
<td>Russian</td>
<td>ru_RU.UTF-8</td>
<td>Russian_Russia.1251</td>
<td>WINDOWS-1251</td></tr>
<tr>
<td>sr_utf8</td>
<td>Serbian</td>
<td>sr_CS.UTF-8</td>
<td>Serbian (Cyrillic)_Serbia and Montenegro.1251</td>
<td>WINDOWS-1251</td></tr>
<tr>
<td>sk_utf8</td>
<td>Slovak</td>
<td>sk_SK.UTF-8</td>
<td>Slovak_Slovakia.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>sl_utf8</td>
<td>Slovenian</td>
<td>sl_SI.UTF-8</td>
<td>Slovenian_Slovenia.1250</td>
<td>WINDOWS-1250</td></tr>
<tr>
<td>so_utf8</td>
<td>Somali</td>
<td>so_SO.UTF-8</td>
<td><span style="color:red">not found!</span></td>
<td><span style="color:red">not found!</span></td></tr>
<tr>
<td>es_utf8</td>
<td>Spanish (International)</td>
<td>es_ES.UTF-8</td>
<td>Spanish_Spain.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>es_es_utf8</td>
<td>Spanish (Spain)</td>
<td>es_ES.UTF-8</td>
<td>-parent es_utf8 used-</td>
<td>-parent es_utf8 used-</td></tr>
<tr>
<td>sv_utf8</td>
<td>Swedish</td>
<td>sv_SE.UTF-8</td>
<td>Swedish_Sweden.1252</td>
<td>WINDOWS-1252</td></tr>
<tr>
<td>tl_utf8</td>
<td>Tagalog</td>
<td>tl.UTF-8</td>
<td><span style="color:red">not found!</span></td>
<td><span style="color:red">not found!</span></td></tr>
<tr>
<td>th_utf8</td>
<td>Thai</td>
<td>th_TH.UTF-8</td>
<td>Thai_Thailand.874</td>
<td>WINDOWS-874</td></tr>
<tr>
<td>tr_utf8</td>
<td>Turkish</td>
<td>tr_TR.UTF-8</td>
<td>Turkish_Turkey.1254</td>
<td>WINDOWS-1254</td></tr>
<tr>
<td>uk_utf8</td>
<td>Ukrainian</td>
<td>uk_UA.UTF-8</td>
<td>Ukrainian_Ukraine.1251</td>
<td>WINDOWS-1251</td></tr>
<tr>
<td>vi_utf8</td>
<td>Vietnamese</td>
<td>vi_VN.UTF-8</td>
<td>Vietnamese_Viet Nam.1258</td>
<td>WINDOWS-1258</td></tr>
</table>

'''Note:''' Some locales for windows <span style="color:red">in red</span> could be incorrect (technically or geographically but they are the only way I've found to show dates properly in my XP box). Also some other coloured cells must be revised because they are not working.

== References ==

=== Windows===

* Win32 Language names: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_language_strings.asp
* Win32 Country names: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_country_strings.asp
* Win32 Codepage codes: http://www.microsoft.com/globaldev/reference/wincp.mspx
* Languages and codepages: http://www.science.co.il/Language/Locale-Codes.asp
* More languages and codepages: http://code.cside.com/3rdpage/windows/
* Languages and locales: http://www.livio.net/main/charset.asp
* Table of language identifiers: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp

===Unix===

* Unix Language names: http://www.loc.gov/standards/iso639-2/englangn.html (639-2 is used only if 639-1 doesn't exist, see the "Locale Name Guide" below).
* Unix Country names: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
* Unix Charset codes: http://www.w3.org/International/O-charset-list.html

===Other Information===

* Locale Name Guide: http://openi18n.org/docs/text/LocNameGuide-V10.txt
* FAQ about ISO 639: http://www.loc.gov/standards/iso639-2/faq.html
* One initiative from Unicode: http://www.unicode.org/cldr/index.html
* Weekdays and Months: http://www.domesticat.net/misc/monthsdays.php

[[es:Tabla de locales]]

[[Category:Developer]]
[[Category:Language]]
[[Category:UTF-8]]

Broken/Roles

2006-09-20T05:58:15Z

UrsHunkler: /* Proposal for interface enhancement */ several typos

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

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

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

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

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

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

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

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

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

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

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Broken/Roles

2006-09-20T05:56:56Z

UrsHunkler: /* Proposal for interface enhancement */ typo

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. The scetches below are not worked out proposals. Theier 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 differnt coloured coulmns 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 tooltip function would be able to give the user valuable information about the meaning.
<br style="clear:both;" />

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Broken/Roles

2006-09-19T21:22:22Z

UrsHunkler: /* Proposal for interface enhancement */ typo

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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: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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. The scetches blow are not worked out proposals. Theier 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 differnt coloured coulmns 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 tooltip function would be able to give the user valuable information about the meaning.
<br style="clear:both;" />

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Broken/Roles

2006-09-19T21:17:33Z

UrsHunkler: /* Proposal for interface enhancement */ enhancements

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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: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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. The scetches blow are not worked out proposals. They only 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 differnt coloured coulmns 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 tooltip function would be able to give the user valuable information about the meaning.
<br style="clear:both;" />

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Broken/Roles

2006-09-19T21:08:34Z

UrsHunkler: /* Proposal for interface enhancement */ typos

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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: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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. (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 visible differnt coulmns 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 tooltip function would be able to give the user valuable information about the meaning.
<br style="clear:both;" />

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Broken/Roles

2006-09-19T21:05:57Z

UrsHunkler: Add section "interface proposals"

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

==Definitions==

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

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===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/blog:view - read blogs
#moodle/blog:create - write new blog posts
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use
#moodle/blog:manageentries - edit/delete all blog entries
#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: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:update - update user settings : 1) user/edit.php
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).
#moodle/user:viewhiddendetails - view user details marked as "hidden"
#moodle/calendar:manageownentries - create/edit/delete
#moodle/calendar:manageentries - create/edit/delete
#moodle/role:assign - assign roles to users
#moodle/role:override - can override role capabilities (depending on context)
#moodle/role:manage - create/edit/delete roles, set capability permissions for each role
#moodle/role:unassignself - unassign yourself from your own roles
#moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden
#moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]
#moodle/question:export - exports questions (course level?)
#moodle/question:managecateory - add/delete/edit question categories (course level?)
#moodle/question:manage - add/edit/delete a question (course level)

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

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

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

#Assignment
##mod/assignment:view- reading the assignment description
##mod/assignment:submit - turn assignment in
##mod/assignment:grade - grading, viewing of list of submitted assignments
#Chat
##mod/chat:chat - allows a user to participate in this chat
##mod/chat:readlog - allows a user to read past chat session logs
##mod/chat:deletelog - allows a user to delete past chat logs
#Choice
##mod/choice:choose - make a choice
##mod/choice:readresponses - read all responses
##mod/choice:deleteresponses - deletes all responses
##mod/choice:downloadresponses - download responses
#Database
##mod/data:viewentry - reads other people's entry
##mod/data:viewentriesfromallgroups
##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:viewforum
##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:view - read entries
##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:view
##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
##mod/resource:view
#Scorm
##mod/scorm:view
##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:view - basic capability needed to view wiki content
##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:view - basic capability needed to enter workshop
##mod/workshop:participate - original student, allows user to submit and assess
##mod/workshop:manage - original teacher, user can manage others
##(Waiting on new Workshop)

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

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

(more soon)

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

===Proposal for interface enhancement===
Martin asked some questions, here are my answers. (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. The picture shows that the user can keep a much better overview when the list is divided into visible differnt coulmns 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 tooltip function would be able to give the user valuable information about the meaning.
<br style="clear:both;" />

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

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

Fitxer:03 moodle define roles tooltip pre.png

2006-09-19T20:07:32Z

UrsHunkler:

Fitxer:03 moodle define roles tooltip.png

2006-09-19T20:07:10Z

UrsHunkler:

Fitxer:02 moodle define roles collapsed pre.png

2006-09-19T20:06:47Z

UrsHunkler:

Fitxer:02 moodle define roles collapsed.png

2006-09-19T20:06:24Z

UrsHunkler:

Fitxer:01 moodle define roles structured.png

2006-09-19T20:05:33Z

UrsHunkler:

Fitxer:01 moodle define roles structured pre.png

2006-09-19T20:04:01Z

UrsHunkler:

Chameleon theme

2006-06-29T10:15:44Z

UrsHunkler: /* Troubleshooting */ text