MoodleDocs - User contributions [en]

File:Simple calculated first question text.jpg

2012-05-09T05:24:49Z

Trobb: uploaded a new version of "File:Simple calculated first question text.jpg": Spelling of 'height' corrected.

show the question text of my first Simple calcualted question

Development:Survey 2 brainstorm

2011-05-05T22:32:24Z

Trobb: /* General features of the Module */

This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.

==General features of the Module==
* translate previously built survey1, feedback and questionnaire at installation time
* upload exported feedback or questionnaires (survey1 doesn't export questionnaires templates)
* save instances of survey2 as a template to reuse it or export it
* import saved survey2 templates
* support for groups and groupings
* custom user survey2 page layout (custom html and css, as it already is in database module)
* download of submissions in txt, xls and ods
* conditional branching
* handle more than one input form layout (and find a way to allow this or that layout to this or that user).
* order survey fields in editing mode
* group fields in the page layout with fieldset
* relations between tables (Example: one record for the profile of my company one related record for each intervention request submitted by my company)
* email submissions to students/teachers/both/none
* email submissions to address specified in a designated question field (for surveys not requiring login)
* for text fields, simple data checking ('must be numeric', 'must contain X character', 'must have exact length n', etc.)
* full web accessibility features to the same level as elsewhere in Moodle e.g. labels on text fields, fieldsets on groups of radio buttons & checkboxes.
* gradebook integration (to allow simple polls to control conditional activities)

==Instance settings page==
* Access section: 20 types of survey, distinguished by:
:-> ppl who is allowed to R/O,
:-> ppl who is allowed to R/W,
:-> ppl who is allowed to delete a record
The reationale is: once a record has been submitted by a user, who is allowed to see it (R/O access)?, who is allowed to edit it (R/W access)?, who is allowed to delete it?

Combining all the options the come out 20 cases are defined as follows where:
:ALL means, all the people accessing the survey;
:GROUP means people belonging to the group of the user who submitted the record;
:OWNER is the user who submitted the record;
:NONE is none.
{| class="nicetable"
|-
! type
! R/O
! R/W
! delete
|-
| 1
| ALL
| ALL
| ALL
|-
| 2
| ALL
| ALL
| GROUP
|-
| 3
| ALL
| ALL
| OWNER
|-
| 4
| ALL
| ALL
| NONE
|-
| 5
| ALL
| GROUP
| GROUP
|-
| 6
| ALL
| GROUP
| OWNER
|-
| 7
| ALL
| GROUP
| NONE
|-
| 8
| ALL
| OWNER
| OWNER
|-
| 9
| ALL
| OWNER
| NONE
|-
| 10
| ALL
| NONE
| NONE
|-
| 11
| GROUP
| GROUP
| GROUP
|-
| 12
| GROUP
| GROUP
| OWNER
|-
| 13
| GROUP
| GROUP
| NONE
|-
| 14
| GROUP
| OWNER
| OWNER
|-
| 15
| GROUP
| OWNER
| NONE
|-
| 16
| GROUP
| NONE
| NONE
|-
| 17
| OWNER
| OWNER
| OWNER
|-
| 18
| OWNER
| OWNER
| NONE
|-
| 19
| OWNER
| NONE
| NONE
|-
| 20
| NONE
| NONE
| NONE
|}

* option: allow/deny save without submission (save and restart)
* option: anonymous survey or named responses
* option: allow access to records any time/after you've submitted/after close date/never
* opening and closing submission dates
* number of maximun allowed submission
* option whether to show results immediately after submission, or a thank you message with link to results.

==Field level settings==
* type of field (char(n), text, number, alphanumeric, boolean, date, picture, file, email, url...) with type check at submit time (and number of digit check for char(n) fields). This information may not be used at field definition time but is useful for data verification/check.

(Example: Please, enter your card ID: _______ This field should be defined, for instance, as char(7))
* option: mandatory/non mandatory field
* free text description field for further description and advices to the completer
*define a range of valid answers for fields allowing this (see next examples)
(Example 1:
Please, enter your seniority. (limited between 0 and 50 years)

Example 2:
Date of birth: (limited between 18 and 100 years ago))
*define fields default to be loaded at "new record" display time
*optional "other" text field for drop down menu/radio button/check box. (see next example)
(Example for drop down:

Where were you born? <code><select name="dropdown_14" size="1"><option value="1" selected="selected">Spain</option><option value="2" >France</option><option value="3" >other, please specify</option></select> <input type="text" name="dropdown_14_other" size="10" maxlength="10" value="" /></code>

If you choose "other" in the drop down menu the field will be enabled and become mandatory, otherwise it will be disabled.
)
* custom question numbers
* question name to name columns header in the downloaded document

==Question types==

Question types should be plug-ins so that they can be extended locally if required. The following list covers types which exist in at least one of the current survey modules.

* radio buttons (horizontal & vertical display)
* short text entry
* long text entry
* checkbox
* drop down menu
* customisable likert scale for rating
* date (Example: When were you born?)

===New question types===
* short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
* time
(Example:
When do you usually take breakfast?
)
* "static text"/"read only" fields (auto filled by the software) like, current_date, user_name, record_ID, counter...
* allocation (Drag and drop)
* ranking

==Result display==

* report per survey, per user and per question
* report about non-respondent users
* choose for a question whether to display results as
** a table
** a bar chart
** a pie chart

==Question management==

* questions can be copied within an activity
* question sets can be created as templates for re-use [maybe later]
* question sets can be used across multiple courses [maybe later]
* questions can be re-ordered within an activity
* question sets can be combined to create a template
* questions can be deleted from an activity, but there should be an "are you sure" check first.

==Answer Piping & Conditional Questions==

*Allow follow on questions related to the previous.
*Do You Smoke? Yes/No If Yes is selected a conditional question appears, How Many per Day, if No is selected move on to question 6 appears

*Answer Piping such as:
*Q1 Which dog breed do you prefer?
*Labrador
*Spaniel
*Collie
*Other

*Q2 In question 1 you stated you prefer the (Q1 Answer) as a breed, what do you like about it. [Where (Q1 Answer) is replaced with the chosen answer such as 'Labrador'
*Temperament
*Looks
*Colour
*Other

Development:Survey 2 brainstorm

2011-05-05T22:31:23Z

Trobb: /* General features of the Module */

This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.

==General features of the Module==
* translate previously built survey1, feedback and questionnaire at installation time
* upload exported feedback or questionnaires (survey1 doesn't export questionnaires templates)
* save instances of survey2 as a template to reuse it or export it
* import saved survey2 templates
* support for groups and groupings
* custom user survey2 page layout (custom html and css, as it already is in database module)
* download of submissions in txt, xls and ods
* conditional branching
* handle more than one input form layout (and find a way to allow this or that layout to this or that user).
* order survey fields in editing mode
* group fields in the page layout with fieldset
* relations between tables (Example: one record for the profile of my company one related record for each intervention request submitted by my company)
* email submissions to students/teachers/both/none
* email submissions to address specified in a designated question field (for surveys not requiring login)
* simple data checking ('must be numeric', 'must contain X character', 'must have exact length n', etc.)
* full web accessibility features to the same level as elsewhere in Moodle e.g. labels on text fields, fieldsets on groups of radio buttons & checkboxes.
* gradebook integration (to allow simple polls to control conditional activities)

==Instance settings page==
* Access section: 20 types of survey, distinguished by:
:-> ppl who is allowed to R/O,
:-> ppl who is allowed to R/W,
:-> ppl who is allowed to delete a record
The reationale is: once a record has been submitted by a user, who is allowed to see it (R/O access)?, who is allowed to edit it (R/W access)?, who is allowed to delete it?

Combining all the options the come out 20 cases are defined as follows where:
:ALL means, all the people accessing the survey;
:GROUP means people belonging to the group of the user who submitted the record;
:OWNER is the user who submitted the record;
:NONE is none.
{| class="nicetable"
|-
! type
! R/O
! R/W
! delete
|-
| 1
| ALL
| ALL
| ALL
|-
| 2
| ALL
| ALL
| GROUP
|-
| 3
| ALL
| ALL
| OWNER
|-
| 4
| ALL
| ALL
| NONE
|-
| 5
| ALL
| GROUP
| GROUP
|-
| 6
| ALL
| GROUP
| OWNER
|-
| 7
| ALL
| GROUP
| NONE
|-
| 8
| ALL
| OWNER
| OWNER
|-
| 9
| ALL
| OWNER
| NONE
|-
| 10
| ALL
| NONE
| NONE
|-
| 11
| GROUP
| GROUP
| GROUP
|-
| 12
| GROUP
| GROUP
| OWNER
|-
| 13
| GROUP
| GROUP
| NONE
|-
| 14
| GROUP
| OWNER
| OWNER
|-
| 15
| GROUP
| OWNER
| NONE
|-
| 16
| GROUP
| NONE
| NONE
|-
| 17
| OWNER
| OWNER
| OWNER
|-
| 18
| OWNER
| OWNER
| NONE
|-
| 19
| OWNER
| NONE
| NONE
|-
| 20
| NONE
| NONE
| NONE
|}

* option: allow/deny save without submission (save and restart)
* option: anonymous survey or named responses
* option: allow access to records any time/after you've submitted/after close date/never
* opening and closing submission dates
* number of maximun allowed submission
* option whether to show results immediately after submission, or a thank you message with link to results.

==Field level settings==
* type of field (char(n), text, number, alphanumeric, boolean, date, picture, file, email, url...) with type check at submit time (and number of digit check for char(n) fields). This information may not be used at field definition time but is useful for data verification/check.

(Example: Please, enter your card ID: _______ This field should be defined, for instance, as char(7))
* option: mandatory/non mandatory field
* free text description field for further description and advices to the completer
*define a range of valid answers for fields allowing this (see next examples)
(Example 1:
Please, enter your seniority. (limited between 0 and 50 years)

Example 2:
Date of birth: (limited between 18 and 100 years ago))
*define fields default to be loaded at "new record" display time
*optional "other" text field for drop down menu/radio button/check box. (see next example)
(Example for drop down:

Where were you born? <code><select name="dropdown_14" size="1"><option value="1" selected="selected">Spain</option><option value="2" >France</option><option value="3" >other, please specify</option></select> <input type="text" name="dropdown_14_other" size="10" maxlength="10" value="" /></code>

If you choose "other" in the drop down menu the field will be enabled and become mandatory, otherwise it will be disabled.
)
* custom question numbers
* question name to name columns header in the downloaded document

==Question types==

Question types should be plug-ins so that they can be extended locally if required. The following list covers types which exist in at least one of the current survey modules.

* radio buttons (horizontal & vertical display)
* short text entry
* long text entry
* checkbox
* drop down menu
* customisable likert scale for rating
* date (Example: When were you born?)

===New question types===
* short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
* time
(Example:
When do you usually take breakfast?
)
* "static text"/"read only" fields (auto filled by the software) like, current_date, user_name, record_ID, counter...
* allocation (Drag and drop)
* ranking

==Result display==

* report per survey, per user and per question
* report about non-respondent users
* choose for a question whether to display results as
** a table
** a bar chart
** a pie chart

==Question management==

* questions can be copied within an activity
* question sets can be created as templates for re-use [maybe later]
* question sets can be used across multiple courses [maybe later]
* questions can be re-ordered within an activity
* question sets can be combined to create a template
* questions can be deleted from an activity, but there should be an "are you sure" check first.

==Answer Piping & Conditional Questions==

*Allow follow on questions related to the previous.
*Do You Smoke? Yes/No If Yes is selected a conditional question appears, How Many per Day, if No is selected move on to question 6 appears

*Answer Piping such as:
*Q1 Which dog breed do you prefer?
*Labrador
*Spaniel
*Collie
*Other

*Q2 In question 1 you stated you prefer the (Q1 Answer) as a breed, what do you like about it. [Where (Q1 Answer) is replaced with the chosen answer such as 'Labrador'
*Temperament
*Looks
*Colour
*Other

Development:Survey 2 brainstorm

2011-05-05T22:27:04Z

Trobb: /* General features of the Module */

This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.

==General features of the Module==
* translate previously built survey1, feedback and questionnaire at installation time
* upload exported feedback or questionnaires (survey1 doesn't export questionnaires templates)
* save instances of survey2 as a template to reuse it or export it
* import saved survey2 templates
* support for groups and groupings
* custom user survey2 page layout (custom html and css, as it already is in database module)
* download of submissions in txt, xls and ods
* conditional branching
* handle more than one input form layout (and find a way to allow this or that layout to this or that user).
* order survey fields in editing mode
* group fields in the page layout with fieldset
* relations between tables (Example: one record for the profile of my company one related record for each intervention request submitted by my company)
* email submissions to students/teachers/both/none
* email submissions to address specified in a designated question field (for surveys not requiring login)
* full web accessibility features to the same level as elsewhere in Moodle e.g. labels on text fields, fieldsets on groups of radio buttons & checkboxes.
* gradebook integration (to allow simple polls to control conditional activities)

==Instance settings page==
* Access section: 20 types of survey, distinguished by:
:-> ppl who is allowed to R/O,
:-> ppl who is allowed to R/W,
:-> ppl who is allowed to delete a record
The reationale is: once a record has been submitted by a user, who is allowed to see it (R/O access)?, who is allowed to edit it (R/W access)?, who is allowed to delete it?

Combining all the options the come out 20 cases are defined as follows where:
:ALL means, all the people accessing the survey;
:GROUP means people belonging to the group of the user who submitted the record;
:OWNER is the user who submitted the record;
:NONE is none.
{| class="nicetable"
|-
! type
! R/O
! R/W
! delete
|-
| 1
| ALL
| ALL
| ALL
|-
| 2
| ALL
| ALL
| GROUP
|-
| 3
| ALL
| ALL
| OWNER
|-
| 4
| ALL
| ALL
| NONE
|-
| 5
| ALL
| GROUP
| GROUP
|-
| 6
| ALL
| GROUP
| OWNER
|-
| 7
| ALL
| GROUP
| NONE
|-
| 8
| ALL
| OWNER
| OWNER
|-
| 9
| ALL
| OWNER
| NONE
|-
| 10
| ALL
| NONE
| NONE
|-
| 11
| GROUP
| GROUP
| GROUP
|-
| 12
| GROUP
| GROUP
| OWNER
|-
| 13
| GROUP
| GROUP
| NONE
|-
| 14
| GROUP
| OWNER
| OWNER
|-
| 15
| GROUP
| OWNER
| NONE
|-
| 16
| GROUP
| NONE
| NONE
|-
| 17
| OWNER
| OWNER
| OWNER
|-
| 18
| OWNER
| OWNER
| NONE
|-
| 19
| OWNER
| NONE
| NONE
|-
| 20
| NONE
| NONE
| NONE
|}

* option: allow/deny save without submission (save and restart)
* option: anonymous survey or named responses
* option: allow access to records any time/after you've submitted/after close date/never
* opening and closing submission dates
* number of maximun allowed submission
* option whether to show results immediately after submission, or a thank you message with link to results.

==Field level settings==
* type of field (char(n), text, number, alphanumeric, boolean, date, picture, file, email, url...) with type check at submit time (and number of digit check for char(n) fields). This information may not be used at field definition time but is useful for data verification/check.

(Example: Please, enter your card ID: _______ This field should be defined, for instance, as char(7))
* option: mandatory/non mandatory field
* free text description field for further description and advices to the completer
*define a range of valid answers for fields allowing this (see next examples)
(Example 1:
Please, enter your seniority. (limited between 0 and 50 years)

Example 2:
Date of birth: (limited between 18 and 100 years ago))
*define fields default to be loaded at "new record" display time
*optional "other" text field for drop down menu/radio button/check box. (see next example)
(Example for drop down:

Where were you born? <code><select name="dropdown_14" size="1"><option value="1" selected="selected">Spain</option><option value="2" >France</option><option value="3" >other, please specify</option></select> <input type="text" name="dropdown_14_other" size="10" maxlength="10" value="" /></code>

If you choose "other" in the drop down menu the field will be enabled and become mandatory, otherwise it will be disabled.
)
* custom question numbers
* question name to name columns header in the downloaded document

==Question types==

Question types should be plug-ins so that they can be extended locally if required. The following list covers types which exist in at least one of the current survey modules.

* radio buttons (horizontal & vertical display)
* short text entry
* long text entry
* checkbox
* drop down menu
* customisable likert scale for rating
* date (Example: When were you born?)

===New question types===
* short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
* time
(Example:
When do you usually take breakfast?
)
* "static text"/"read only" fields (auto filled by the software) like, current_date, user_name, record_ID, counter...
* allocation (Drag and drop)
* ranking

==Result display==

* report per survey, per user and per question
* report about non-respondent users
* choose for a question whether to display results as
** a table
** a bar chart
** a pie chart

==Question management==

* questions can be copied within an activity
* question sets can be created as templates for re-use [maybe later]
* question sets can be used across multiple courses [maybe later]
* questions can be re-ordered within an activity
* question sets can be combined to create a template
* questions can be deleted from an activity, but there should be an "are you sure" check first.

==Answer Piping & Conditional Questions==

*Allow follow on questions related to the previous.
*Do You Smoke? Yes/No If Yes is selected a conditional question appears, How Many per Day, if No is selected move on to question 6 appears

*Answer Piping such as:
*Q1 Which dog breed do you prefer?
*Labrador
*Spaniel
*Collie
*Other

*Q2 In question 1 you stated you prefer the (Q1 Answer) as a breed, what do you like about it. [Where (Q1 Answer) is replaced with the chosen answer such as 'Labrador'
*Temperament
*Looks
*Colour
*Other

MNet

2009-08-10T06:29:05Z

Trobb: /* Setup */

{{Moodle 1.8}}==Overview==
Moodle Network is a new feature found in the 1.8 release of Moodle. The network feature allows a Moodle administrator to establish a link with another Moodle, and to share some resources with the users of that Moodle.

The initial release of Moodle Network is bundled with a new Authentication Plugin, which makes single-sign-on between Moodles possible. A user with the username jody logs in to her Moodle server as normal, and clicks on a link that takes her to a page on another Moodle server. Normally, she would have only the privileges of a guest on the remote Moodle, but behind the scenes, single-sign-on has established a fully authenticated session for Jody on the remote site.

'''WARNING:''' Moodle Networking requires the use of xmlrpc. Please go to your phpinfo page if you are interested in using this and search for --with-xmlrpc. If your php has not been compiled with xmlrpc then you need to address that first! At present it appears that PEAR xmlrpc will not work.
[[Image:Administration Block Users Authentication MoodleNetwork.jpg|thumb|Moodle Network setting in Admin>User>Authentication>Moodle Network]]

==Security==
The Moodle network feature requires that your server has the Curl and OpenSSL extensions installed. When you install or upgrade to Moodle 1.8, your system will generate a new OpenSSL certificate for encrypted communication with other Moodles, and will thereafter rotate encryption keys on a monthly basis (approx).

Communication takes place over an XML-RPC transport, and the XML-RPC documents are wrapped first in an XMLDSIG (XML digital signature) envelope, and then in an XMLENC (XML encryption) envelope. The encryption all happens within PHP, and does not require an https (Apache SSL) server.

References:
*[http://www.w3.org/TR/xmldsig-core/ XML Digital Signatures]
*[http://www.w3.org/TR/xmlenc-core/ XML Encryption]

A special mode can be enabled which would allow a machine with a specified IP address to make calls to the XML-RPC layer without using either encryption or signature envelopes. This mode is provided to enable Moodle to communicate with other software systems in which the integration of signatures and encryption might be prohibitively difficult. It is not envisioned that unencrypted inter-Moodle networking will ever be enabled.

==Peer to Peer Network==

This is the basic layout of the system. It can be very useful to run one Moodle per faculty or departments, each with its own user management, and yet permit users to roam across the Moodle installs... subject to permissions of course.

===Setup===

The instructions will cover 2 Moodle installations: MoodleA and MoodleB. Both are installed correctly and have never had a Moodle Network configuration.

Note: If you experience problems, ensure debugging is turned on in ''Site Administration > Server > Debugging''. Extra diagnostic messages may be displayed (particularly from Moodle 1.9.2)

# Get them to talk to each other
## Ensure ''Admin > Server > Environment'' indicates you have curl installed
## If MoodleA and MoodleB are hosted in the same domain, ensure they have a different cookie prefix. Note that changing the cookie prefix will log you out! You can change the cookie prefix via ''Admin > Server > Session Handling''.
## On both, go to ''Admin > Network > Settings'' and turn Networking ON.
## On MoodleA go to ''Admin > Network > Peers'' - put the URL of MoodleB under "Add New Host" and click Add. The URL should include the directory where your Moodle code is located, for example ''www.mymoodle.org/moodle''.
## Do the equivalent on MoodleB.
# Get user roaming going
## On both, go to ''Admin > Users > Authentication'' and enable Moodle Network authentication plugin. Click on 'Settings' and enable auto_add_remote_users.
## On MoodleA go to ''Admin > Network > Peers'', click on 'MoodleB', and click on 'Services'. Enable SSO-IDP publish and subscribe, and SSO-SP publish and subscribe.
## Do the equivalent on MoodleB.
## On both, go to ''Admin > Users > Permissions > Define Roles'', only roles that have "Roam to a remote Moodle moodle/site:mnetlogintoremote" will be allowed to roam. Grant the privilege as appropriate.
## On both, go to the homepage, and add the 'Network Servers' block.
## To test, it is recommended to use a different browser (even on a different machine) that is logged in to neither. Login to MoodleA with a non-administrator account that has the permissions to roam. You should see the Network Servers block, and clicking on it you should go to MoodleB with a newly autocreated account.
# Get remote enrolments going -- this is optional. It allows administrator of MoodleB can enrol users that are "native" to MoodleB in courses in MoodleA, and viceversa.
## On both, go to ''Admin > Courses > Enrolment'' and enable Moodle Network enrolment plugin (click Save). Click on 'Edit' and enable 'allow_allcourses' or select some courses or categories to be remotely enrolled.
## On MoodleA go to ''Admin > Network > Peers'', click on 'MoodleB', and click on 'Services'. Enable Enrolment publish and subscribe.
## Do the equivalent on MoodleB.
## To use, in MoodleA go to ''Admin > Networking > Enrolments''. You will see MoodleB listed. Click on MoodleB and you will see a list of courses that MoodleB offers for remote enrolment. Select the course you want, and then enroll the users you want to that course.

===Using it===

==Connecting to a Community hub==
A [[Community hub]] is a Moodle server that is configured to accept connections from other Moodle servers, and to provide a set of services to users of these other servers. This guideline will direct you to connect to a Community hub, assess the services it has to offer, and enable those services for your users.

===Setup===
# Get talking to the Hub
## Ensure that the ''Admin > Server > Environment'' page indicates you have curl and openssl installed
## Go to ''Admin > Network > Settings'' and turn Networking on
## Go to ''Admin > Network > Peers'' and enter the URL of Community Hub under "Add New Host". Click Add
## The host details for the Community Hub should appear with the Site Name field already populated. Click Save changes
## The details will be written to your database and two new tabs will appear in this window: 'Services' and 'Logs'. Click Services
##A list of services will appear, each with a checkbox for 'publish' and 'subscribe'. Check the checkboxes for any services you want to publish or subscribe to

===Using it===
If the Community Hub has already enabled a service for you, there will be a tick alongside the appropriate checkbox, for example: if the Hub is publishing Moodle Networked Enrolment, then a tick will appear alongside the subscribe checkbox for this service. Note that in order to enable some functionality, prominently single-sign-on, you may have to publish a service, e.g. the Identity Provider service. The Community Hub will access this service on your Moodle, asking it to authenticate your users.
# Enable Roaming
## Subscribe to SSO (Service Provider) by checking the box
## Publish SSO (Identity Provider) by checking the box
## Click Save changes
## Go to ''Admin > Users > Permissions > Define Roles'', and grant the capability Roam to a remote Moodle moodle/site:mnetlogintoremote to an appropriate role
## Go to ''Admin > Users > Authentication'' and enable the Moodle Network authentication plugin
## Go to your homepage, turn on editing, and add the 'Network Servers' block
## Using a different web-browser, log on as a non-admin user who inhabits the role you granted the roaming capability to
## Note that the Community Hub is listed in the Network Servers block on the homepage. Click on the link to that server
## Some of your user details will be transferred to the Community Hub server, and a browsing session will be started for you as if you had logged on there directly
# Enable Networked Enrolment
## Return to the web browser you've been using as the site administrator
## Go to ''Admin > Network > Peers'' and click on the entry for the Community Hub.
## Click on the Services tab
## Subscribe to Moodle Networked Enrolment
## Go to ''Admin > Courses > Enrolment'' and enable the Moodle Network enrolment plugin. Click Save changes
## Click on edit to view the details for networked enrolments.
## Go to ''Admin > Networking > Enrolments'' to see a list of Moodle servers that offer this service to you
## Click on a server name to view a list of courses that the server offers to your users
## Click on a course name, to view a list users that you can enrol in this course
## Enrol users
## Profit!

==Running a Community hub==
A Community hub is a regular Moodle site that runs in a special mode. As a Moodle Administrator, when you add another Moodle site to your list of network peers, your Moodle will contact that site to find out what it is called, and to request its public key for encrypted communication. Normally, the remote server will simply provide this information without making any record of the transaction.

A Community hub is different. As soon as you add an entry for a Community hub to your system, the Community hub will create an entry for your server in its list of hosts, and may immediately begin to offer services to the users of your site.

This section will guide you to set up a Community hub, and select services to offer to all comers.

===Setup===
# Enable Networking
## Ensure that the ''Admin > Server > Environment'' page indicates you have curl and openssl installed
## Go to ''Admin > Network > Settings'' and turn Networking on
## Go to ''Admin > Network > Peers'' and tick the checkbox for Register all hosts. Click on Save Changes
## On the same page, the first entry in your list of hosts should be All hosts. Click this link
## Click on Services and enable any services you want to offer to all comers

==See also==

* [[Moodle Network FAQ]]
* [[Development:Moodle Network|Moodle Network development notes]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=6976 Moodle Network forum]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=92749 Examples of how people are using Moodle networks] forum discussion

[[Category:Authentication]]
[[Category:Enrolment]]
[[Category:MNET]]

[[fr:Réseau Moodle]]
[[ja:Moodleネットワーク]]
[[es:Red Moodle]]
[[cs:Síťové služby]]

MNet

2009-08-10T06:27:32Z

Trobb: /* Setup */

{{Moodle 1.8}}==Overview==
Moodle Network is a new feature found in the 1.8 release of Moodle. The network feature allows a Moodle administrator to establish a link with another Moodle, and to share some resources with the users of that Moodle.

The initial release of Moodle Network is bundled with a new Authentication Plugin, which makes single-sign-on between Moodles possible. A user with the username jody logs in to her Moodle server as normal, and clicks on a link that takes her to a page on another Moodle server. Normally, she would have only the privileges of a guest on the remote Moodle, but behind the scenes, single-sign-on has established a fully authenticated session for Jody on the remote site.

'''WARNING:''' Moodle Networking requires the use of xmlrpc. Please go to your phpinfo page if you are interested in using this and search for --with-xmlrpc. If your php has not been compiled with xmlrpc then you need to address that first! At present it appears that PEAR xmlrpc will not work.
[[Image:Administration Block Users Authentication MoodleNetwork.jpg|thumb|Moodle Network setting in Admin>User>Authentication>Moodle Network]]

==Security==
The Moodle network feature requires that your server has the Curl and OpenSSL extensions installed. When you install or upgrade to Moodle 1.8, your system will generate a new OpenSSL certificate for encrypted communication with other Moodles, and will thereafter rotate encryption keys on a monthly basis (approx).

Communication takes place over an XML-RPC transport, and the XML-RPC documents are wrapped first in an XMLDSIG (XML digital signature) envelope, and then in an XMLENC (XML encryption) envelope. The encryption all happens within PHP, and does not require an https (Apache SSL) server.

References:
*[http://www.w3.org/TR/xmldsig-core/ XML Digital Signatures]
*[http://www.w3.org/TR/xmlenc-core/ XML Encryption]

A special mode can be enabled which would allow a machine with a specified IP address to make calls to the XML-RPC layer without using either encryption or signature envelopes. This mode is provided to enable Moodle to communicate with other software systems in which the integration of signatures and encryption might be prohibitively difficult. It is not envisioned that unencrypted inter-Moodle networking will ever be enabled.

==Peer to Peer Network==

This is the basic layout of the system. It can be very useful to run one Moodle per faculty or departments, each with its own user management, and yet permit users to roam across the Moodle installs... subject to permissions of course.

===Setup===

The instructions will cover 2 Moodle installations: MoodleA and MoodleB. Both are installed correctly and have never had a Moodle Network configuration.

Note: If you experience problems, ensure debugging is turned on in ''Site Administration > Server > Debugging''. Extra diagnostic messages may be displayed (particularly from Moodle 1.9.2)

# Get them to talk to each other
## Ensure that the ''Moodle Networking'' enrolment plugin has been activated in ''Admin > Courses > Enrolments''.
## Ensure ''Admin > Server > Environment'' indicates you have curl installed
## If MoodleA and MoodleB are hosted in the same domain, ensure they have a different cookie prefix. Note that changing the cookie prefix will log you out! You can change the cookie prefix via ''Admin > Server > Session Handling''.
## On both, go to ''Admin > Network > Settings'' and turn Networking ON.
## On MoodleA go to ''Admin > Network > Peers'' - put the URL of MoodleB under "Add New Host" and click Add. The URL should include the directory where your Moodle code is located, for example ''www.mymoodle.org/moodle''.
## Do the equivalent on MoodleB.
# Get user roaming going
## On both, go to ''Admin > Users > Authentication'' and enable Moodle Network authentication plugin. Click on 'Settings' and enable auto_add_remote_users.
## On MoodleA go to ''Admin > Network > Peers'', click on 'MoodleB', and click on 'Services'. Enable SSO-IDP publish and subscribe, and SSO-SP publish and subscribe.
## Do the equivalent on MoodleB.
## On both, go to ''Admin > Users > Permissions > Define Roles'', only roles that have "Roam to a remote Moodle moodle/site:mnetlogintoremote" will be allowed to roam. Grant the privilege as appropriate.
## On both, go to the homepage, and add the 'Network Servers' block.
## To test, it is recommended to use a different browser (even on a different machine) that is logged in to neither. Login to MoodleA with a non-administrator account that has the permissions to roam. You should see the Network Servers block, and clicking on it you should go to MoodleB with a newly autocreated account.
# Get remote enrolments going -- this is optional. It allows administrator of MoodleB can enrol users that are "native" to MoodleB in courses in MoodleA, and viceversa.
## On both, go to ''Admin > Courses > Enrolment'' and enable Moodle Network enrolment plugin (click Save). Click on 'Edit' and enable 'allow_allcourses' or select some courses or categories to be remotely enrolled.
## On MoodleA go to ''Admin > Network > Peers'', click on 'MoodleB', and click on 'Services'. Enable Enrolment publish and subscribe.
## Do the equivalent on MoodleB.
## To use, in MoodleA go to ''Admin > Networking > Enrolments''. You will see MoodleB listed. Click on MoodleB and you will see a list of courses that MoodleB offers for remote enrolment. Select the course you want, and then enroll the users you want to that course.

===Using it===

==Connecting to a Community hub==
A [[Community hub]] is a Moodle server that is configured to accept connections from other Moodle servers, and to provide a set of services to users of these other servers. This guideline will direct you to connect to a Community hub, assess the services it has to offer, and enable those services for your users.

===Setup===
# Get talking to the Hub
## Ensure that the ''Admin > Server > Environment'' page indicates you have curl and openssl installed
## Go to ''Admin > Network > Settings'' and turn Networking on
## Go to ''Admin > Network > Peers'' and enter the URL of Community Hub under "Add New Host". Click Add
## The host details for the Community Hub should appear with the Site Name field already populated. Click Save changes
## The details will be written to your database and two new tabs will appear in this window: 'Services' and 'Logs'. Click Services
##A list of services will appear, each with a checkbox for 'publish' and 'subscribe'. Check the checkboxes for any services you want to publish or subscribe to

===Using it===
If the Community Hub has already enabled a service for you, there will be a tick alongside the appropriate checkbox, for example: if the Hub is publishing Moodle Networked Enrolment, then a tick will appear alongside the subscribe checkbox for this service. Note that in order to enable some functionality, prominently single-sign-on, you may have to publish a service, e.g. the Identity Provider service. The Community Hub will access this service on your Moodle, asking it to authenticate your users.
# Enable Roaming
## Subscribe to SSO (Service Provider) by checking the box
## Publish SSO (Identity Provider) by checking the box
## Click Save changes
## Go to ''Admin > Users > Permissions > Define Roles'', and grant the capability Roam to a remote Moodle moodle/site:mnetlogintoremote to an appropriate role
## Go to ''Admin > Users > Authentication'' and enable the Moodle Network authentication plugin
## Go to your homepage, turn on editing, and add the 'Network Servers' block
## Using a different web-browser, log on as a non-admin user who inhabits the role you granted the roaming capability to
## Note that the Community Hub is listed in the Network Servers block on the homepage. Click on the link to that server
## Some of your user details will be transferred to the Community Hub server, and a browsing session will be started for you as if you had logged on there directly
# Enable Networked Enrolment
## Return to the web browser you've been using as the site administrator
## Go to ''Admin > Network > Peers'' and click on the entry for the Community Hub.
## Click on the Services tab
## Subscribe to Moodle Networked Enrolment
## Go to ''Admin > Courses > Enrolment'' and enable the Moodle Network enrolment plugin. Click Save changes
## Click on edit to view the details for networked enrolments.
## Go to ''Admin > Networking > Enrolments'' to see a list of Moodle servers that offer this service to you
## Click on a server name to view a list of courses that the server offers to your users
## Click on a course name, to view a list users that you can enrol in this course
## Enrol users
## Profit!

==Running a Community hub==
A Community hub is a regular Moodle site that runs in a special mode. As a Moodle Administrator, when you add another Moodle site to your list of network peers, your Moodle will contact that site to find out what it is called, and to request its public key for encrypted communication. Normally, the remote server will simply provide this information without making any record of the transaction.

A Community hub is different. As soon as you add an entry for a Community hub to your system, the Community hub will create an entry for your server in its list of hosts, and may immediately begin to offer services to the users of your site.

This section will guide you to set up a Community hub, and select services to offer to all comers.

===Setup===
# Enable Networking
## Ensure that the ''Admin > Server > Environment'' page indicates you have curl and openssl installed
## Go to ''Admin > Network > Settings'' and turn Networking on
## Go to ''Admin > Network > Peers'' and tick the checkbox for Register all hosts. Click on Save Changes
## On the same page, the first entry in your list of hosts should be All hosts. Click this link
## Click on Services and enable any services you want to offer to all comers

==See also==

* [[Moodle Network FAQ]]
* [[Development:Moodle Network|Moodle Network development notes]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=6976 Moodle Network forum]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=92749 Examples of how people are using Moodle networks] forum discussion

[[Category:Authentication]]
[[Category:Enrolment]]
[[Category:MNET]]

[[fr:Réseau Moodle]]
[[ja:Moodleネットワーク]]
[[es:Red Moodle]]
[[cs:Síťové služby]]

Managing roles

2007-01-29T01:19:52Z

Trobb: /* Roles FAQ */

{{Roles}}
{{Moodle 1.7}}
Moodle 1.7 allows the administrator to add or edit existing roles available on the Moodle site. This is done through the Administration block>>User>>Permission>>Define roles menu area. Remember that Moodle comes with 7 default roles and adding and editing roles is completely optional.

==Define roles==
There are 3 tabs on the define role page.
[[Image:Roles_Define_tab.JPG|center]]

*Manage roles - The place to add and define permissions for a new role, or edit name and/or permissions associated with existing Moodle roles.
*[[Allow role assignments]] - A matrix which determines which role can assign users to other roles.
*[[Allow role overrides]] - A matrix which determines which role can override a previously assigned role. The default is that only an administrator can override any role assigned by another role.

==Permissions==
The permissions matrix allows a very granular approach to assigning rights to a role (a class of users). Assigning or editing permissions should be done with great care. A change can produce a profound unwanted effect, or an annoying effect that will be hard to understand the cause.

There are over 150 lines of capabilities where any of 4 different permissions can be assigned. The capabilities are grouped in 21 catagories. We strongly recommend not to change the LEGACY roles. Here is the top of the list.

[[Image:Roles_Define_Permissions_crop.JPG|center]]

===Permission terms===
From lowest to highest, from general to specific.

*Inherit - pass along from before [lowest level, always loses]
*Allow - let happen or permit [same level as prevent]
*Prevent - stop [same level as allow]
*Prohibit - forbid {highest level, always wins]

===Permission examples===
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current context.

'''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.

'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permanent stop.

Since the capabilities in each role could be different and participants can be assigned different roles, there could be a conflict in capabilities. The hierarchy of permissions resolves this by saying that the capability defined for a more specific context will win, unless an prohibit is encountered in a less specific context.

Example 1. Mark has a student role in Course One, which allows all students to write into the wikis "Everyone" and "Homework". But Mark also got assigned a Visitor role at a module context level (for the wiki "Honors") and Visitors are prevented writing in the Honors wiki. Thus Mark can write into the "Everyone" and "Homework" wikis but not in "Honors".

Example 2.Jeff has been assigned to a "naughty student" role that prohibits him from postings in any forums for the whole site. However his teacher assigned him a "facilitator" role in "Science forum" in the course Science and Math 101. Since a higher context prohibit permission always wins, Jeff is unable to post in "Science forum".

==Examples of roles==
Why would a site want different roles? Consider
{| border="0" cellpadding="2"
!width="200"|
!width="200"|
!width="200"|
|-
||*Site Designers||*Educational Authority Adviser||*Educational Inspector||
|-
||*Second Marker / Moderator||*Peer observer of teaching||*External Examiner
|-
||*Parent||*Manager||*Weekly Seminar Leader
|-
||*Mentor/Mentee||*Community-Designed Rating Criteria||*Visitor
|-
||*Guest Speaker||*Former Student||*Alumnus
|-
||*Librarian||*Teacher||*Community Education Tutors/Trainers
|-
||*Secretary/Student Worker||*Teaching Assistant||*Student - FERPA rights
|-
||*Help Desk|| ||
|}

==Enrolling existing students in a course ==
In 1.7, enrolling students in a course is done by the roles section. Go to the course, in the [[Administration block]], click Assign Roles, when the new page opens, click on Students and you will be presented with a screen that lists most Moodle users. This is similar to previous versions of Moodle. Select the student on the right and add them to the course list on the left.

If the student is not on the Moodle list, they will need to be created or added to the Moodle user list, also found under the roles section.

==Basic concept 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, being able to reply to a forum post is a capability.
*A '''permission''' is some value that is assigned for a capability for a particular role. For example, using the prevent permission to limit all students from posting to any forum.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks, forums etc.
*A '''hierarchy of permissions''' determines which permission wins or is going to be in effect if there is an apparent conflict. For example, the site allow all students the permission to to post in forums, but a teacher might prevent that right in a particular course. The hierarchy of permissions would allow a student to post in one course but not in another course.

==Testing roles==

It is necessary to log out then log in again to test roles. Do not use "Login As" to check the new settings; use some dummy accounts instead.

==Roles FAQ==

*I want all teachers to be able to create courses. How can I do this?

1) Create a new role called C-only (or whatever) and only assign "allow" to "Create courses" leaving everything else as "inherit".

2) Assign this additional role to those who need the ability to create courses at whatever level you want to (entire site or category). It makes no sense to assign it at the course level since you can't create a course within a course.

[[Category:Administrator]]
[[Category:Roles]]

[[fr:Définir les rôles]]

Managing roles

2007-01-29T01:16:24Z

Trobb: /* Roles FAQ */

{{Roles}}
{{Moodle 1.7}}
Moodle 1.7 allows the administrator to add or edit existing roles available on the Moodle site. This is done through the Administration block>>User>>Permission>>Define roles menu area. Remember that Moodle comes with 7 default roles and adding and editing roles is completely optional.

==Define roles==
There are 3 tabs on the define role page.
[[Image:Roles_Define_tab.JPG|center]]

*Manage roles - The place to add and define permissions for a new role, or edit name and/or permissions associated with existing Moodle roles.
*[[Allow role assignments]] - A matrix which determines which role can assign users to other roles.
*[[Allow role overrides]] - A matrix which determines which role can override a previously assigned role. The default is that only an administrator can override any role assigned by another role.

==Permissions==
The permissions matrix allows a very granular approach to assigning rights to a role (a class of users). Assigning or editing permissions should be done with great care. A change can produce a profound unwanted effect, or an annoying effect that will be hard to understand the cause.

There are over 150 lines of capabilities where any of 4 different permissions can be assigned. The capabilities are grouped in 21 catagories. We strongly recommend not to change the LEGACY roles. Here is the top of the list.

[[Image:Roles_Define_Permissions_crop.JPG|center]]

===Permission terms===
From lowest to highest, from general to specific.

*Inherit - pass along from before [lowest level, always loses]
*Allow - let happen or permit [same level as prevent]
*Prevent - stop [same level as allow]
*Prohibit - forbid {highest level, always wins]

===Permission examples===
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current context.

'''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.

'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permanent stop.

Since the capabilities in each role could be different and participants can be assigned different roles, there could be a conflict in capabilities. The hierarchy of permissions resolves this by saying that the capability defined for a more specific context will win, unless an prohibit is encountered in a less specific context.

Example 1. Mark has a student role in Course One, which allows all students to write into the wikis "Everyone" and "Homework". But Mark also got assigned a Visitor role at a module context level (for the wiki "Honors") and Visitors are prevented writing in the Honors wiki. Thus Mark can write into the "Everyone" and "Homework" wikis but not in "Honors".

Example 2.Jeff has been assigned to a "naughty student" role that prohibits him from postings in any forums for the whole site. However his teacher assigned him a "facilitator" role in "Science forum" in the course Science and Math 101. Since a higher context prohibit permission always wins, Jeff is unable to post in "Science forum".

==Examples of roles==
Why would a site want different roles? Consider
{| border="0" cellpadding="2"
!width="200"|
!width="200"|
!width="200"|
|-
||*Site Designers||*Educational Authority Adviser||*Educational Inspector||
|-
||*Second Marker / Moderator||*Peer observer of teaching||*External Examiner
|-
||*Parent||*Manager||*Weekly Seminar Leader
|-
||*Mentor/Mentee||*Community-Designed Rating Criteria||*Visitor
|-
||*Guest Speaker||*Former Student||*Alumnus
|-
||*Librarian||*Teacher||*Community Education Tutors/Trainers
|-
||*Secretary/Student Worker||*Teaching Assistant||*Student - FERPA rights
|-
||*Help Desk|| ||
|}

==Enrolling existing students in a course ==
In 1.7, enrolling students in a course is done by the roles section. Go to the course, in the [[Administration block]], click Assign Roles, when the new page opens, click on Students and you will be presented with a screen that lists most Moodle users. This is similar to previous versions of Moodle. Select the student on the right and add them to the course list on the left.

If the student is not on the Moodle list, they will need to be created or added to the Moodle user list, also found under the roles section.

==Basic concept 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, being able to reply to a forum post is a capability.
*A '''permission''' is some value that is assigned for a capability for a particular role. For example, using the prevent permission to limit all students from posting to any forum.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks, forums etc.
*A '''hierarchy of permissions''' determines which permission wins or is going to be in effect if there is an apparent conflict. For example, the site allow all students the permission to to post in forums, but a teacher might prevent that right in a particular course. The hierarchy of permissions would allow a student to post in one course but not in another course.

==Testing roles==

It is necessary to log out then log in again to test roles. Do not use "Login As" to check the new settings; use some dummy accounts instead.

==Roles FAQ==

*I want all teachers to be able to create courses. How can I do this?

[[Category:Administrator]]
[[Category:Roles]]

[[fr:Définir les rôles]]

Managing roles

2007-01-29T01:15:33Z

Trobb:

{{Roles}}
{{Moodle 1.7}}
Moodle 1.7 allows the administrator to add or edit existing roles available on the Moodle site. This is done through the Administration block>>User>>Permission>>Define roles menu area. Remember that Moodle comes with 7 default roles and adding and editing roles is completely optional.

==Define roles==
There are 3 tabs on the define role page.
[[Image:Roles_Define_tab.JPG|center]]

*Manage roles - The place to add and define permissions for a new role, or edit name and/or permissions associated with existing Moodle roles.
*[[Allow role assignments]] - A matrix which determines which role can assign users to other roles.
*[[Allow role overrides]] - A matrix which determines which role can override a previously assigned role. The default is that only an administrator can override any role assigned by another role.

==Permissions==
The permissions matrix allows a very granular approach to assigning rights to a role (a class of users). Assigning or editing permissions should be done with great care. A change can produce a profound unwanted effect, or an annoying effect that will be hard to understand the cause.

There are over 150 lines of capabilities where any of 4 different permissions can be assigned. The capabilities are grouped in 21 catagories. We strongly recommend not to change the LEGACY roles. Here is the top of the list.

[[Image:Roles_Define_Permissions_crop.JPG|center]]

===Permission terms===
From lowest to highest, from general to specific.

*Inherit - pass along from before [lowest level, always loses]
*Allow - let happen or permit [same level as prevent]
*Prevent - stop [same level as allow]
*Prohibit - forbid {highest level, always wins]

===Permission examples===
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current context.

'''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.

'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permanent stop.

Since the capabilities in each role could be different and participants can be assigned different roles, there could be a conflict in capabilities. The hierarchy of permissions resolves this by saying that the capability defined for a more specific context will win, unless an prohibit is encountered in a less specific context.

Example 1. Mark has a student role in Course One, which allows all students to write into the wikis "Everyone" and "Homework". But Mark also got assigned a Visitor role at a module context level (for the wiki "Honors") and Visitors are prevented writing in the Honors wiki. Thus Mark can write into the "Everyone" and "Homework" wikis but not in "Honors".

Example 2.Jeff has been assigned to a "naughty student" role that prohibits him from postings in any forums for the whole site. However his teacher assigned him a "facilitator" role in "Science forum" in the course Science and Math 101. Since a higher context prohibit permission always wins, Jeff is unable to post in "Science forum".

==Examples of roles==
Why would a site want different roles? Consider
{| border="0" cellpadding="2"
!width="200"|
!width="200"|
!width="200"|
|-
||*Site Designers||*Educational Authority Adviser||*Educational Inspector||
|-
||*Second Marker / Moderator||*Peer observer of teaching||*External Examiner
|-
||*Parent||*Manager||*Weekly Seminar Leader
|-
||*Mentor/Mentee||*Community-Designed Rating Criteria||*Visitor
|-
||*Guest Speaker||*Former Student||*Alumnus
|-
||*Librarian||*Teacher||*Community Education Tutors/Trainers
|-
||*Secretary/Student Worker||*Teaching Assistant||*Student - FERPA rights
|-
||*Help Desk|| ||
|}

==Enrolling existing students in a course ==
In 1.7, enrolling students in a course is done by the roles section. Go to the course, in the [[Administration block]], click Assign Roles, when the new page opens, click on Students and you will be presented with a screen that lists most Moodle users. This is similar to previous versions of Moodle. Select the student on the right and add them to the course list on the left.

If the student is not on the Moodle list, they will need to be created or added to the Moodle user list, also found under the roles section.

==Basic concept 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, being able to reply to a forum post is a capability.
*A '''permission''' is some value that is assigned for a capability for a particular role. For example, using the prevent permission to limit all students from posting to any forum.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks, forums etc.
*A '''hierarchy of permissions''' determines which permission wins or is going to be in effect if there is an apparent conflict. For example, the site allow all students the permission to to post in forums, but a teacher might prevent that right in a particular course. The hierarchy of permissions would allow a student to post in one course but not in another course.

==Testing roles==

It is necessary to log out then log in again to test roles. Do not use "Login As" to check the new settings; use some dummy accounts instead.

==Roles FAQ==

[[Category:Administrator]]
[[Category:Roles]]

[[fr:Définir les rôles]]

Managing roles

2007-01-29T01:07:58Z

Trobb: /* Basic concept definitions */

{{Roles}}
{{Moodle 1.7}}
Moodle 1.7 allows the administrator to add or edit existing roles available on the Moodle site. This is done through the Administration block>>User>>Permission>>Define roles menu area. Remember that Moodle comes with 7 default roles and adding and editing roles is completely optional.

==Define roles==
There are 3 tabs on the define role page.
[[Image:Roles_Define_tab.JPG|center]]

*Manage roles - The place to add and define permissions for a new role, or edit name and/or permissions associated with existing Moodle roles.
*[[Allow role assignments]] - A matrix which determines which role can assign users to other roles.
*[[Allow role overrides]] - A matrix which determines which role can override a previously assigned role. The default is that only an administrator can override any role assigned by another role.

==Permissions==
The permissions matrix allows a very granular approach to assigning rights to a role (a class of users). Assigning or editing permissions should be done with great care. A change can produce a profound unwanted effect, or an annoying effect that will be hard to understand the cause.

There are over 150 lines of capabilities where any of 4 different permissions can be assigned. The capabilities are grouped in 21 catagories. We strongly recommend not to change the LEGACY roles. Here is the top of the list.

[[Image:Roles_Define_Permissions_crop.JPG|center]]

===Permission terms===
From lowest to highest, from general to specific.

*Inherit - pass along from before [lowest level, always loses]
*Allow - let happen or permit [same level as prevent]
*Prevent - stop [same level as allow]
*Prohibit - forbid {highest level, always wins]

===Permission examples===
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current context.

'''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.

'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permanent stop.

Since the capabilities in each role could be different and participants can be assigned different roles, there could be a conflict in capabilities. The hierarchy of permissions resolves this by saying that the capability defined for a more specific context will win, unless an prohibit is encountered in a less specific context.

Example 1. Mark has a student role in Course One, which allows all students to write into the wikis "Everyone" and "Homework". But Mark also got assigned a Visitor role at a module context level (for the wiki "Honors") and Visitors are prevented writing in the Honors wiki. Thus Mark can write into the "Everyone" and "Homework" wikis but not in "Honors".

Example 2.Jeff has been assigned to a "naughty student" role that prohibits him from postings in any forums for the whole site. However his teacher assigned him a "facilitator" role in "Science forum" in the course Science and Math 101. Since a higher context prohibit permission always wins, Jeff is unable to post in "Science forum".

==Examples of roles==
Why would a site want different roles? Consider
{| border="0" cellpadding="2"
!width="200"|
!width="200"|
!width="200"|
|-
||*Site Designers||*Educational Authority Adviser||*Educational Inspector||
|-
||*Second Marker / Moderator||*Peer observer of teaching||*External Examiner
|-
||*Parent||*Manager||*Weekly Seminar Leader
|-
||*Mentor/Mentee||*Community-Designed Rating Criteria||*Visitor
|-
||*Guest Speaker||*Former Student||*Alumnus
|-
||*Librarian||*Teacher||*Community Education Tutors/Trainers
|-
||*Secretary/Student Worker||*Teaching Assistant||*Student - FERPA rights
|-
||*Help Desk|| ||
|}

==Enrolling existing students in a course ==
In 1.7, enrolling students in a course is done by the roles section. Go to the course, in the [[Administration block]], click Assign Roles, when the new page opens, click on Students and you will be presented with a screen that lists most Moodle users. This is similar to previous versions of Moodle. Select the student on the right and add them to the course list on the left.

If the student is not on the Moodle list, they will need to be created or added to the Moodle user list, also found under the roles section.

==Basic concept 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, being able to reply to a forum post is a capability.
*A '''permission''' is some value that is assigned for a capability for a particular role. For example, using the prevent permission to limit all students from posting to any forum.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks, forums etc.
*A '''hierarchy of permissions''' determines which permission wins or is going to be in effect if there is an apparent conflict. For example, the site allow all students the permission to to post in forums, but a teacher might prevent that right in a particular course. The hierarchy of permissions would allow a student to post in one course but not in another course.

==Testing roles==

It is necessary to log out then log in again to test roles. Do not use "Login As" to check the new settings; use some dummy accounts instead.

[[Category:Administrator]]
[[Category:Roles]]

[[fr:Définir les rôles]]