MoodleDocs - User contributions [en]

Course rate block

2013-07-08T13:23:55Z

Jenny-gray:

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English, Hebrew, Mexican spanish and German.

If using the german language pack, you will need to copy the star0.png file from rate_course/lang/de_utf8 into rate_course/graphic to replace the one there with english text included. Hopefully we'll improve this to dynamically include the language some time!

===Integrating the Questionnaire module===

In the Moodle 2.x compatible version of this block, you can edit the block settings to add a link to a Questionnaire. If you do not have the questionnaire module installed, or do not wish to use this feature, simply leave the block setting empty.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block is maintained by Jenny Gray at the UK Open University.

[[Category:Contributed code]]

[[es:Bloque de valoración de curso]]

Course rate block

2012-02-14T16:33:19Z

Jenny-gray: /* Contributor/Maintainer */

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English, Hebrew and German.

If using the german language pack, you will need to copy the star0.png file from rate_course/lang/de_utf8 into rate_course/graphic to replace the one there with english text included. Hopefully we'll improve this to dynamically include the language some time!

===Integrating the Questionnaire module===

In the Moodle 2.x compatible version of this block, you can edit the block settings to add a link to a Questionnaire. If you do not have the questionnaire module installed, or do not wish to use this feature, simply leave the block setting empty.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray at the UK Open University, however we are no longer using this block on Moodle 2.x and would be grateful for any volunteers to collaborate or take over maintenance of this block.

[[Category:Contributed code]]

Course rate block

2011-07-28T12:29:04Z

Jenny-gray:

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English, Hebrew and German.

If using the german language pack, you will need to copy the star0.png file from rate_course/lang/de_utf8 into rate_course/graphic to replace the one there with english text included. Hopefully we'll improve this to dynamically include the language some time!

===Integrating the Questionnaire module===

In the Moodle 2.x compatible version of this block, you can edit the block settings to add a link to a Questionnaire. If you do not have the questionnaire module installed, or do not wish to use this feature, simply leave the block setting empty.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray.

[[Category:Contributed code]]

Development:Survey 2 brainstorm

2011-04-21T15:58:08Z

Jenny-gray: /* Question management */

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
* 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-04-08T13:39:56Z

Jenny-gray: /* 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
* 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

==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-04-06T12:38:26Z

Jenny-gray: /* 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
* 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.

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

==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-03-24T14:04:57Z

Jenny-gray: /* Result display */

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

==Module settings page==
*option: allow/deny save without submission
*option: anonymous survey or named responses
*option: allow/deny record modification after submission
*option: allow/deny the read only access to submitted records (see next example)
(Example: This option should appear like:
<code>
<div>Submitted answers are available/visible <select name="dropdown_7" size="1">
<option value="0">to all users</option>
<option value="1" >to submitter only</option>
<option value="2" >to submitter group only</option>
</select></div>
</code>
)
*option: allow/deny submitted record deletion
*custom form and css
*download of submitted records in some standard format
* option: allow access to results any time/after you've submitted/after close date/never
** fine-grain control for result display at question level also
*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. (see next example)

(Example:
Please, enter your card ID: _______
This field should be defined, for instance, as char(7))
*opening and closing submission dates (displayed on calendar)
*relations between tables
(Example:
one record for the profile of my company
one related record for each intervention request submitted by my company)

=== Standard module settings ===

* support for groups and groupings
* permission control for which roles can create surveys

==Field level settings==
*mandatory/non mandatory field option
*free text description field for further description and advice 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.
)
*define read-only fields (auto filled by the software) like, current_date, user_name, record_ID...
* option: allow access to results any time/after you've submitted/after close date/never

==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
* short text entry
* long text entry
* allocation
* checkbox
* customisable likert scale for rating
* ranking

===New question types===
*short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
*order list. A list of available items and the answer is supposed to order them.
*time (see next example)

(Example:
When do you usually take breakfast?
)

==Result display==

* choose for a question whether to display results as
** a table
** a bar chart
** a pie chart
* option whether to show results immediately after submission, or a thank you message with link to results.

==Question management==

* questions can be copied within an activity
* question sets can be created as templates for re-use
* question sets can be used across multiple courses
* questions can be re-ordered within an activity
* question sets can be combined to create a questionnaire

==Uncategorised requested features==
*handle more than one view_single/view_list/find/input layout (and allow this or that layout to users on the basis of capabilities).

The idea is: On the basis of capability you will access your specific layout with only a field subset.
If you have this capability, you will find all the fields of the survey, otherwise you will find only a subset of them.

The same feature may be provided in the following way:
At fields level definition the course creator should be allowed to mark the field "field1" as
#visible and enabled to all
#visible to all but enabled to users with view_field1 capability only
#visible and enabled to users with view_field1 capability only

*allow update of submitted questionnaire as an option (not just a clean slate on the next go-round)
*allow course creator to add custom number to question inside layouts (i.e.: 1, 2, 2a, 2b, 3...) to respect questions hierarchy
*allow course creator to indent questions inside layouts to respect questions hierarchy (as it is already possible the indent of resources inside courses)
*conditional branching (see next example)
(Example:

1. Gender: <code><input type="radio" name="gender" value="0" checked="checked"/></code>F <code><input type="radio" name="gender" value="1" /></code>M
1a. How many pregnancies have you had? <code><select><option value="0" selected="selected">0</option><option value="1">1</option><option value="2">2</option><option value="more">more</option></select></code> (should be disabled when answer 1 == F)
1b. Question relevant only for males? <code><select disabled="disabled"><option value="aa" selected="selected">aa</option><option value="bb">bb</option><option value="cc">cc</option><option value="more">other</option></select></code> (should be disabled when answer 1 == M)
)

==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-03-14T13:59:08Z

Jenny-gray:

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

==Module settings page==
*option: allow/deny save without submission
*option: anonymous survey or named responses
*option: allow/deny record modification after submission
*option: allow/deny the read only access to submitted records (see next example)
(Example: This option should appear like:
<code>
<div>Submitted answers are available/visible <select name="dropdown_7" size="1">
<option value="0">to all users</option>
<option value="1" >to submitter only</option>
<option value="2" >to submitter group only</option>
</select></div>
</code>
)
*option: allow/deny submitted record deletion
*custom form and css
*download of submitted records in some standard format
* option: allow access to results any time/after you've submitted/after close date/never
** fine-grain control for result display at question level also
*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. (see next example)

(Example:
Please, enter your card ID: _______
This field should be defined, for instance, as char(7))
*opening and closing submission dates (displayed on calendar)
*relations between tables
(Example:
one record for the profile of my company
one related record for each intervention request submitted by my company)

=== Standard module settings ===

* support for groups and groupings
* permission control for which roles can create surveys

==Field level settings==
*mandatory/non mandatory field option
*free text description field for further description and advice 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.
)
*define read-only fields (auto filled by the software) like, current_date, user_name, record_ID...
* option: allow access to results any time/after you've submitted/after close date/never

==Fields types==

Field 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
* short text entry
* long text entry
* allocation
* checkbox
* customisable likert scale for rating
* ranking

===New field types===
*short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
*order list. A list of available items and the answer is supposed to order them.
*time (see next example)

(Example:
When do you usually take breakfast?
)

==Result display==

* 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
* question sets can be used across multiple courses
* questions can be re-ordered within an activity

==Uncategorised requested features==
*handle more than one view_single/view_list/find/input layout (and allow this or that layout to users on the basis of capabilities).

The idea is: On the basis of capability you will access your specific layout with only a field subset.
If you have this capability, you will find all the fields of the survey, otherwise you will find only a subset of them.

The same feature may be provided in the following way:
At fields level definition the course creator should be allowed to mark the field "field1" as
#visible and enabled to all
#visible to all but enabled to users with view_field1 capability only
#visible and enabled to users with view_field1 capability only

*allow course creator to add custom number to question inside layouts (i.e.: 1, 2, 2a, 2b, 3...) to respect questions hierarchy
*allow course creator to indent questions inside layouts to respect questions hierarchy (as it is already possible the indent of resources inside courses)
*conditional branching (see next example)
(Example:

1. Gender: <code><input type="radio" name="gender" value="0" checked="checked"/></code>F <code><input type="radio" name="gender" value="1" /></code>M
1a. How many pregnancies have you had? <code><select><option value="0" selected="selected">0</option><option value="1">1</option><option value="2">2</option><option value="more">more</option></select></code> (should be disabled when answer 1 == F)
1b. Question relevant only for males? <code><select disabled="disabled"><option value="aa" selected="selected">aa</option><option value="bb">bb</option><option value="cc">cc</option><option value="more">other</option></select></code> (should be disabled when answer 1 == M)
)

Development:User preferences for plug-ins

2011-03-14T13:29:34Z

Jenny-gray: /* Defining the form */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block, wherever it appears. This would gather together user preferences in a single location, making them easy to find.

When the user views the settings screen, their current settings will be displayed. An Edit button will allow them to make changes.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

=== User interface mock-ups ===

1. a custom plug-in's main screen - showing its link to its settings screen

[[Image:userprefs_pluginscreen.jpg|600px]]

2. a custom plug-in's setting screen in read mode - also showing the settings block with links to other settings

[[Image:Userprefs_readscreen.png]]

3. a custom plug-in's setting screen in edit mode

[[Image:Userprefs_edit.png]]

4. forum settings

[[Image:Userpref_forum.png]]

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

Initially I thought that the user/edit.php pages should display the Settings block. Given that the settings block and the "my profile" section is available all over the place, I'm not sure this is strictly necessary. When you're editing your profile, so you really need to jump to other places? You don't have the block there already with your "change password" link.

If we do want the settings block on the edit profile screen, it's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189. Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text.

A new class of user_settingpage will be set up, so that the userpreferences.php file will start with:

$settings = new user_settingpage('format_studyplan', get_string('pluginname','format_studyplan'));

Then each setting will be added like this:

$settings->add(new user_setting_checkbox('format_studyplan_enablenotes', get_string('enablenotes_label', 'format_studyplan'), get_string('enablenotes_prompt', 'format_studyplan'), get_string('enablenotes_help', 'format_studyplan'), true, PARAM_INT));

To be completed - I'm not sure yet what the user_setting classes would need to do (how much can they inherit from admin_setting), and what we'd need to write so that when a user clicks on plugin/userpreferences.php link in the website they get the form rendered correctly.

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If the user visits their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor (possibly some new ones coming related to this too)
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-03-14T13:20:37Z

Jenny-gray: /* User interface mock-ups */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block, wherever it appears. This would gather together user preferences in a single location, making them easy to find.

When the user views the settings screen, their current settings will be displayed. An Edit button will allow them to make changes.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

=== User interface mock-ups ===

1. a custom plug-in's main screen - showing its link to its settings screen

[[Image:userprefs_pluginscreen.jpg|600px]]

2. a custom plug-in's setting screen in read mode - also showing the settings block with links to other settings

[[Image:Userprefs_readscreen.png]]

3. a custom plug-in's setting screen in edit mode

[[Image:Userprefs_edit.png]]

4. forum settings

[[Image:Userpref_forum.png]]

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

Initially I thought that the user/edit.php pages should display the Settings block. Given that the settings block and the "my profile" section is available all over the place, I'm not sure this is strictly necessary. When you're editing your profile, so you really need to jump to other places? You don't have the block there already with your "change password" link.

If we do want the settings block on the edit profile screen, it's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189. Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If the user visits their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor (possibly some new ones coming related to this too)
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

{{CategoryDeveloper}}

File:Userpref forum.png

2011-03-14T13:19:16Z

Jenny-gray:

Development:User preferences for plug-ins

2011-03-14T12:38:11Z

Jenny-gray: /* User interface mock-ups */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block, wherever it appears. This would gather together user preferences in a single location, making them easy to find.

When the user views the settings screen, their current settings will be displayed. An Edit button will allow them to make changes.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

=== User interface mock-ups ===

1. a custom plug-in's main screen - showing its link to its settings screen

[[Image:userprefs_pluginscreen.jpg|600px]]

2. a custom plug-in's setting screen in read mode

[[Image:Userprefs_readscreen.png]]

3. a custom plug-in's setting screen in edit mode

[[Image:Userprefs_edit.png]]

4. forum settings

5. the user profile page

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

Initially I thought that the user/edit.php pages should display the Settings block. Given that the settings block and the "my profile" section is available all over the place, I'm not sure this is strictly necessary. When you're editing your profile, so you really need to jump to other places? You don't have the block there already with your "change password" link.

If we do want the settings block on the edit profile screen, it's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189. Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If the user visits their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor (possibly some new ones coming related to this too)
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

{{CategoryDeveloper}}

File:Userprefs edit.png

2011-03-14T12:32:37Z

Jenny-gray:

File:Userprefs readscreen.png

2011-03-14T12:31:49Z

Jenny-gray:

Development:User preferences for plug-ins

2011-03-14T12:14:45Z

Jenny-gray: /* User interface mock-ups */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block, wherever it appears. This would gather together user preferences in a single location, making them easy to find.

When the user views the settings screen, their current settings will be displayed. An Edit button will allow them to make changes.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

=== User interface mock-ups ===

1. a custom plug-in's main screen - showing its link to its settings screen

[[Image:userprefs_pluginscreen.jpg]]

2. a custom plug-in's setting screen in read mode

3. a custom plug-in's setting screen in edit mode

4. forum settings

5. the user profile page

6. the course home page

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

Initially I thought that the user/edit.php pages should display the Settings block. Given that the settings block and the "my profile" section is available all over the place, I'm not sure this is strictly necessary. When you're editing your profile, so you really need to jump to other places? You don't have the block there already with your "change password" link.

If we do want the settings block on the edit profile screen, it's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189. Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If the user visits their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor (possibly some new ones coming related to this too)
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

{{CategoryDeveloper}}

File:userprefs pluginscreen.jpg

2011-03-14T12:13:57Z

Jenny-gray:

Development:User preferences for plug-ins

2011-03-14T10:44:51Z

Jenny-gray:

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block, wherever it appears. This would gather together user preferences in a single location, making them easy to find.

When the user views the settings screen, their current settings will be displayed. An Edit button will allow them to make changes.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

=== User interface mock-ups ===

1. a custom plug-in's main screen - showing its link to its settings screen

2. a custom plug-in's setting screen in read mode

3. a custom plug-in's setting screen in edit mode

4. forum settings

5. the user profile page

6. the course home page

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

Initially I thought that the user/edit.php pages should display the Settings block. Given that the settings block and the "my profile" section is available all over the place, I'm not sure this is strictly necessary. When you're editing your profile, so you really need to jump to other places? You don't have the block there already with your "change password" link.

If we do want the settings block on the edit profile screen, it's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189. Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If the user visits their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor (possibly some new ones coming related to this too)
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-03-14T10:03:03Z

Jenny-gray: /* Overview */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in. Each plug-in would offer its own settings screen, and would place links to that screen at suitable place(s) in their own user interface. Additionally, a link to the settings screen would be automatically added to the profile section of the settings block. This would gather together user preferences in a single location, making them easy to find.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-03-11T09:44:26Z

Jenny-gray: /* Generated settings form */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Example plug-in form:

[[Image:userpref_Studyplansettings.gif]]

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

File:userpref Studyplansettings.gif

2011-03-11T09:43:42Z

Jenny-gray:

Development:User preferences for plug-ins

2011-03-11T09:42:18Z

Jenny-gray: /* Settings block */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

[[Image:Userpref_settingblock.gif]]

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

File:Userpref settingblock.gif

2011-03-11T09:41:43Z

Jenny-gray:

Development:User preferences for plug-ins

2011-02-23T09:38:20Z

Jenny-gray: /* set_user_preferences */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

''Update'' Tim points out that you'd be unlikely to want to set multiple plug-ins at the same time, which is very true. Its probably not something we should encourage either. So maybe it would be better to simply add another parameter (optional, default null as with set_user_preference()) with the plugin name.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-02-23T09:36:25Z

Jenny-gray: /* Structure */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-02-22T10:49:01Z

Jenny-gray:

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

Development:User preferences for plug-ins

2011-02-22T10:19:28Z

Jenny-gray:

Development:User preferences for plug-ins

2011-02-22T10:10:18Z

Jenny-gray: New page: This page is associated with discussion about allowing plug-ins to declare their own user settings screens. * Forum thread http://moodle.org/mod/forum/discuss.php?d=168322 * Tracker issue...

Development:Migrating to 2.0 checklist

2011-01-27T15:04:26Z

Jenny-gray: /* General */

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[Development:Migrating_contrib_code_to_2.0]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

==Database==

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

==Page display==

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

==Roles and Permissions:==

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

==Language strings==

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

==Forms==

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

==General==

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Development:Migrating to 2.0 checklist

2011-01-27T15:02:48Z

Jenny-gray:

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[Development:Migrating_contrib_code_to_2.0]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

==Database==

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

==Page display==

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

==Roles and Permissions:==

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

==Language strings==

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

==Forms==

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

==General==

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Update the code template at the top of each file (see [[Code template guidelines]] for details
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Development:Migrating to 2.0 checklist

2011-01-27T15:01:44Z

Jenny-gray: New page: h1. Plugin migration checklist These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this che...

h1. Plugin migration checklist

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

h2. Database

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

h2. Page display

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

h2. Roles and Permissions:

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

h2. Language strings

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

h2. Forms

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

h2. General

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Update the code template at the top of each file (see [[Code template guidelines]] for details
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Development:Migrating contrib code to 2.0

2011-01-27T15:00:01Z

Jenny-gray: /* See also */

{{stub}}

{{Moodle 2.0}}

The goal of this page is to provide a checklist of tasks to be considered to upgrade CONTRIB code to Moodle 2.0. Several significant changes have taken place including the File API, DB Layer, Navigation, Output renderer, etc. It would be good if we had a list that contributors could follow to help move them toward being able to migrate the code. Any help in building up this list is greatly appreciated.

''Please add useful links...''

== Installation ==

The 'requires' version in the plugin's version.php is checked to make sure it looks like Moodle 2.0. You should change this value to '2010112400' or later otherwise plugin installation will abort.

== Database ==
* [[Development:DB_layer_2.0_migration_docs]]

== File system ==

== Forms API ==
* [[Development:Using the File API in Moodle forms]]
* [[Development:Using_the_file_API]]

== Themes ==
* [[Development:Output_renderers]]
* [[Development:Text formats 2.0|Text formats 2.0]] how user-entered content is handled.
* [[Development:Migrating_your_code_to_the_2.0_rendering_API]] (n.b., some info outdated and may need updating)
* [[Development:Themes_2.0]]

Some details of how to re-design image CSS for plugin code are in the main themes documentation: [[Development:Themes_2.0_creating_your_first_theme#Using_images_within_CSS]]

Be aware that themes are now cached on the server and so emptying your browser cache will not refresh the CSS. This can only be done by going to the site administration->appearance->themes->theme selector page and clicking the 'invalidate theme caches' button.

== JavaScript ==
JavaScript is included in different ways now and will need to be migrated, see the PHPDoc comments in /lib/outputrequirements.lib and some (slightly outdated) advice here: [[Development:JavaScript_guidelines]]

== Backup and Restore ==

* [[Backup_2.0_for_developers]]

== Miscellaneous ==
There are other coding changes such as:
* MDL-24063 which eliminates PARAM_CLEAN
* MDL-24058 about no longer using stripslashes or addslashes
* [[Deprecated_functions_in_2.0]]

Please feel free to add others that come to mind. CONTRIB maintainers should check their 2.0 versions for these and make sure that they are appropriately handled.

== See also ==

* [[Moodle_2.0_release_notes]]
* CONTRIB-1988
* http://cvs.moodle.org/moodle/blocks/upgrade.txt?view=markup
* http://cvs.moodle.org/moodle/mod/upgrade.txt?view=markup
* [[User:Frank_Ralf/Experience_of_converting_a_module_to_Moodle_2|Experience of converting a module to Moodle 2]] by Sam Marshall (perhaps that documentation should better live here? --[[User:Frank Ralf|Frank Ralf]] 16:36, 15 November 2010 (UTC))
* [[Development:Local_customisation]]
* [[Development:Migrating to 2.0 checklist]] list of things to look out for when upgrading a plug-in

[[Category:Developer]]

Development:Migrating contrib code to 2.0

2011-01-21T11:53:58Z

Jenny-gray:

Course rate block

2010-06-18T14:57:47Z

Jenny-gray: /* Languages */

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

Most users will want to download the "for Moodle 1.9" version, since the latest version (in CVS HEAD) is compatible with Moodle 2.0 which has not yet been released.

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English and German. If using the german language pack, you will need to copy the star0.png file from rate_course/lang/de_utf8 into rate_course/graphic to replace the one there with english text included. Hopefully we'll improve this to dynamically include the language some time!

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray.

[[Category:Contributed code]]

Course rate block

2010-06-11T12:54:08Z

Jenny-gray: /* Languages */

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

Most users will want to download the "for Moodle 1.9" version, since the latest version (in CVS HEAD) is compatible with Moodle 2.0 which has not yet been released.

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English and German only.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray.

[[Category:Contributed code]]

Course rate block

2009-10-15T12:51:47Z

Jenny-gray: how to display on mymoodle page

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

Most users will want to download the "for Moodle 1.9" version, since the latest version (in CVS HEAD) is compatible with Moodle 2.0 which has not yet been released.

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English only.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear. You can also add it to the myMoodle course information by editing the print_overview() function in course/lib.php;

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray.

[[Category:Contributed code]]

Development:Community hub

2009-07-06T15:47:26Z

Jenny-gray: /* Harvest courses */

{{Work in progress}}{{Moodle 2.0}}

* '''PROJECT STATE: Proposal'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc (automatic and/or manual).
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
* (E) The repository API downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more CDS (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a CDS (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there (with or without Mnet).

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
# Teacher browses a list of downloadable courses in the File picker (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Find community".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Find community". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://moodle.org/hubs http://moodle.org/hubs] as well as a simple XML format from [http://moodle.org/hubs/list.xml http://moodle.org/hubs/list.xml] suitable for consumption by Moodle sites.

{| class="nicetable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubname
|varchar
|Name of the Hub
|-
|hubdescription
|text
|Description of the hub, from the admin there
|-
|huburl
|varchar
|The full URL to the hub front page
|-
|hubsecret
|varchar
|The secret code from the hub (extra authentication)
|-
|trusted
|int
|Is the hub trusted? Does it have good quality control?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|sites
|int
|Number of sites registered on this hub
|-
|courses
|int
|Number of courses registered on this hub
|-
|timefirst
|int
|Time that the hub was first registered
|-
|timelast
|int
|Time that the hub was last registered/updated
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|image
|varchar
|hub logo url
|}

[[Image:Registerhub.png]]

following a hub list table on Moodle.org:
[[Image:Hublist.png]]

==Moodle Hub Server==

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A default installation of Moodle can also be a Hub, or if the admin chooses, a site can be a dedicated Hub if they choose that option during install (in this case the front page of the site will be a dedicated site search for the public).

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name
* description
* language
* contact name
* contact email
* enable
* hub secret (generated the first time the hub is registered on Moodle.org, it will never change)
* logo url
* protected web search interface '''(TODO: the protection method needs to be defined)'''

=== Data structure ===

==== Sites ====

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites].

* Id
* Site name
* Site description
* URL
* Address
*# Country code (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
*# Region/state (based on list) [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)]
*# Street address
*# Geolocation (for mapping)
* Site manager
*# Name
*# Email
*# Phone
* Contact form yes/no?
* Default site language
* Moodle version (eg 2009050502)
* Moodle release (eg 1.9.5+)
* Site ip address (updated at every update)
* Unique SiteID code generated by Moodle site
* Confirmed by admin
* Site is "trusted" - this means we don't manually check data in future from this site.
* Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
* Harvesting url
* Time updated
* Time created
* Currently unreachable
* Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

* Tool usage stats
** number of courses
** number of users
** number of enrolments
** number of posts
** number of resources
** number of questions
** median course size
* Subscribed to securityalerts@lists.moodle.org

==== Courses ====

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

* Course ID
* Site ID (foreign key to sites table)
* Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([https://docs.moodle.org/en/Course_Standard_Tags Course Standard Tags ])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)
* Audience: Educators | Students | Admins
* Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
* Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )

* Availability (public/private)
* Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
* Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
* Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
* Is the course enrollable anyone with an account?
* Is guest access allowed?
* Are screenshots supplied? (stored on disk under id of this record)
* Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
* Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

=== Web user interface ===

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Here is a very rough mockup of how it could look:

[[Image:Webinterface.png]]

[[Image:Search_hub_moodle.png]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - <span style=color:blue>use comment 2.0 API</span>

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable <span style=color:blue>(first tag retrieved by the request is considered)</span>''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Date last checked (by a cron job)
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service user interface ===

A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface (at http://hubsite.org/hub) where the hub is managed. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Site registration ==

The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis.
# choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image)

Each Moodle.org Hub will perform a check every week to verify that each site is accessible and optionally to harvest the courses from that site. Sites that fail two or three checks in a row will be disable in the Hub listing.

[[Image:SiteRegistration.png|900px]]

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|900px]]

== Import/Export courses ==

The Import/Export block will be available on course pages and contains buttons to:

* '''Publish course''': to publish or update the description of the current course in one or more Hubs (admins only)
* '''Export course''': publish/upload entire course (as Moodle Backup minus userdata) somewhere (eg a Hub) (via Portfolio API plugins)
* '''Import course''': find/download/install a course template from a Hub or from another course on same site (Repository API plugins)

=== Publish course ===

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|900px]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable, so that others can come here and use the course where it is, and/or
* downloadable, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub. The Hub will bounce back a confirmation which gets saved locally as the "Last publish date" for that course.

If the checkbox to allow download was selected, then the URL to a course download script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

=== Export course ===

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. Portfolio (export) plugins could include:

* downloading it to the local computer
* uploading it as a zip to any general purpose repository
* copy the course to another Moodle site set up with Mnet peering.

Pushing it to another Moodle site would trigger extra behaviours:

* Permissions would be checked on the destination Moodle
* The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
* Someone on the external Moodle can be alerted to approve/unhide the new course

=== Import course ===

The '''Import course''' button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

* find Hubs by downloading the Hub List
* search particular Hubs for downloadable courses (only)
* search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses and passed any challenge there might be (eg the Hub could potentially require a password or payment or a license agreement form), then the zip file is downloaded to the local Moodle, and then the user is passed to the standard restore process.

[[Image:FilePicker_all_JS.png|900px]]
[[Image:FilePicker_JS_course_selector.png|900px]]

== Harvest courses ==

Each hub will use cron to call every site that has registered a harvesting url on a periodic basis. This will be done at the same time as the link is checked to ensure the site is reachable, so the "time link was last checked" field in the site table also indicates when the site was last harvested.

The harvesting url will be an RSS feed which will list all the courses to be included in the hub and their metadata. This might be the feed of all visible courses on the site, or courses in a given category. TODO: should we allow them to enter multiple category feeds so they can say "arts", "business" and "languages" but not "science"?

Course list RSS feeds are an existing tracker item for Moodle 2.0 See http://tracker.moodle.org/browse/MDL-13248 This patch allows admins to pick which categories have individual feeds created and are included in the "all courses" feed. Each course becomes an <item> in the RSS feed as follows:

* <category> the Moodle course category in which the course belongs
* <title> the course fullname
* <link> the course url
* <pubdate> the date the course (or any of its resources and activities) last updated
* <description> the course summary

The current tracker item will need to be extended to include appropriate course metadata in the RSS feed. There is a [http://purl.org/dc/elements/1.1/ Dublin Core extension to RSS 2.0] which can be implemented.

TODO: If we choose an alternative metadata format we will need to locate or create an alternative RSS extension. There is a [http://www.downes.ca/xml/RSS_LOM.htm LOM extension] but not from an official IEEE namespace.

We will need to declare our own namespace RSS extension to identify whether a course should be listed in the hub as downloadable and/or enrollable. This extension will add tags to the RSS feed as follows:

* <moodlehub:downloadable>
* <moodlehub:enrollable>

Both tags will take either "yes" or "no" values and will be set by course creators at the same time as they enter course metadata.

The hub will check the published date for each item in the RSS feed to identify whether it needs to update its records. TODO: if we use OAI-PMH for harvesting we can request courses updated since x see http://moodle.org/mod/forum/discuss.php?d=127488

If the course has been updated and is <moodlehub:downloadable> is yes, then the hub will request the site to create a new backup of the entire course (less user data).

= Schedule =

Full schedule and progress is in the tracker: MDL-19309

# Moodle.org Hub List
# Hub registration form
# Hub Web interface
# Hub web service interface
# Improve Site registration form
# Community block
# Publish courses
# Import courses
# Export courses
# Harvest courses

= See also =

* [[Community hub technotes]] - relating to MNet developments in Moodle 1.8
* MDL-18580 - Community Hub tracker issue

[[Category:MNET]]

[[ja:開発:コミュニティハブ]]

Development:Community hub

2009-07-06T15:46:50Z

Jenny-gray: /* Import course */

{{Work in progress}}{{Moodle 2.0}}

* '''PROJECT STATE: Proposal'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc (automatic and/or manual).
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
* (E) The repository API downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more CDS (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a CDS (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there (with or without Mnet).

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
# Teacher browses a list of downloadable courses in the File picker (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Find community".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Find community". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://moodle.org/hubs http://moodle.org/hubs] as well as a simple XML format from [http://moodle.org/hubs/list.xml http://moodle.org/hubs/list.xml] suitable for consumption by Moodle sites.

{| class="nicetable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubname
|varchar
|Name of the Hub
|-
|hubdescription
|text
|Description of the hub, from the admin there
|-
|huburl
|varchar
|The full URL to the hub front page
|-
|hubsecret
|varchar
|The secret code from the hub (extra authentication)
|-
|trusted
|int
|Is the hub trusted? Does it have good quality control?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|sites
|int
|Number of sites registered on this hub
|-
|courses
|int
|Number of courses registered on this hub
|-
|timefirst
|int
|Time that the hub was first registered
|-
|timelast
|int
|Time that the hub was last registered/updated
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|image
|varchar
|hub logo url
|}

[[Image:Registerhub.png]]

following a hub list table on Moodle.org:
[[Image:Hublist.png]]

==Moodle Hub Server==

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A default installation of Moodle can also be a Hub, or if the admin chooses, a site can be a dedicated Hub if they choose that option during install (in this case the front page of the site will be a dedicated site search for the public).

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name
* description
* language
* contact name
* contact email
* enable
* hub secret (generated the first time the hub is registered on Moodle.org, it will never change)
* logo url
* protected web search interface '''(TODO: the protection method needs to be defined)'''

=== Data structure ===

==== Sites ====

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites].

* Id
* Site name
* Site description
* URL
* Address
*# Country code (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
*# Region/state (based on list) [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)]
*# Street address
*# Geolocation (for mapping)
* Site manager
*# Name
*# Email
*# Phone
* Contact form yes/no?
* Default site language
* Moodle version (eg 2009050502)
* Moodle release (eg 1.9.5+)
* Site ip address (updated at every update)
* Unique SiteID code generated by Moodle site
* Confirmed by admin
* Site is "trusted" - this means we don't manually check data in future from this site.
* Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
* Harvesting url
* Time updated
* Time created
* Currently unreachable
* Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

* Tool usage stats
** number of courses
** number of users
** number of enrolments
** number of posts
** number of resources
** number of questions
** median course size
* Subscribed to securityalerts@lists.moodle.org

==== Courses ====

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

* Course ID
* Site ID (foreign key to sites table)
* Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([https://docs.moodle.org/en/Course_Standard_Tags Course Standard Tags ])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)
* Audience: Educators | Students | Admins
* Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
* Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )

* Availability (public/private)
* Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
* Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
* Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
* Is the course enrollable anyone with an account?
* Is guest access allowed?
* Are screenshots supplied? (stored on disk under id of this record)
* Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
* Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

=== Web user interface ===

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Here is a very rough mockup of how it could look:

[[Image:Webinterface.png]]

[[Image:Search_hub_moodle.png]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - <span style=color:blue>use comment 2.0 API</span>

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable <span style=color:blue>(first tag retrieved by the request is considered)</span>''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Date last checked (by a cron job)
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service user interface ===

A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface (at http://hubsite.org/hub) where the hub is managed. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Site registration ==

The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis.
# choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image)

Each Moodle.org Hub will perform a check every week to verify that each site is accessible and optionally to harvest the courses from that site. Sites that fail two or three checks in a row will be disable in the Hub listing.

[[Image:SiteRegistration.png|900px]]

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|900px]]

== Import/Export courses ==

The Import/Export block will be available on course pages and contains buttons to:

* '''Publish course''': to publish or update the description of the current course in one or more Hubs (admins only)
* '''Export course''': publish/upload entire course (as Moodle Backup minus userdata) somewhere (eg a Hub) (via Portfolio API plugins)
* '''Import course''': find/download/install a course template from a Hub or from another course on same site (Repository API plugins)

=== Publish course ===

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|900px]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable, so that others can come here and use the course where it is, and/or
* downloadable, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub. The Hub will bounce back a confirmation which gets saved locally as the "Last publish date" for that course.

If the checkbox to allow download was selected, then the URL to a course download script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

=== Export course ===

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. Portfolio (export) plugins could include:

* downloading it to the local computer
* uploading it as a zip to any general purpose repository
* copy the course to another Moodle site set up with Mnet peering.

Pushing it to another Moodle site would trigger extra behaviours:

* Permissions would be checked on the destination Moodle
* The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
* Someone on the external Moodle can be alerted to approve/unhide the new course

=== Import course ===

The '''Import course''' button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

* find Hubs by downloading the Hub List
* search particular Hubs for downloadable courses (only)
* search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses and passed any challenge there might be (eg the Hub could potentially require a password or payment or a license agreement form), then the zip file is downloaded to the local Moodle, and then the user is passed to the standard restore process.

[[Image:FilePicker_all_JS.png|900px]]
[[Image:FilePicker_JS_course_selector.png|900px]]

=== Harvest courses ===

Each hub will use cron to call every site that has registered a harvesting url on a periodic basis. This will be done at the same time as the link is checked to ensure the site is reachable, so the "time link was last checked" field in the site table also indicates when the site was last harvested.

The harvesting url will be an RSS feed which will list all the courses to be included in the hub and their metadata. This might be the feed of all visible courses on the site, or courses in a given category. TODO: should we allow them to enter multiple category feeds so they can say "arts", "business" and "languages" but not "science"?

Course list RSS feeds are an existing tracker item for Moodle 2.0 See http://tracker.moodle.org/browse/MDL-13248 This patch allows admins to pick which categories have individual feeds created and are included in the "all courses" feed. Each course becomes an <item> in the RSS feed as follows:

* <category> the Moodle course category in which the course belongs
* <title> the course fullname
* <link> the course url
* <pubdate> the date the course (or any of its resources and activities) last updated
* <description> the course summary

The current tracker item will need to be extended to include appropriate course metadata in the RSS feed. There is a [http://purl.org/dc/elements/1.1/ Dublin Core extension to RSS 2.0] which can be implemented.

TODO: If we choose an alternative metadata format we will need to locate or create an alternative RSS extension. There is a [http://www.downes.ca/xml/RSS_LOM.htm LOM extension] but not from an official IEEE namespace.

We will need to declare our own namespace RSS extension to identify whether a course should be listed in the hub as downloadable and/or enrollable. This extension will add tags to the RSS feed as follows:

* <moodlehub:downloadable>
* <moodlehub:enrollable>

Both tags will take either "yes" or "no" values and will be set by course creators at the same time as they enter course metadata.

The hub will check the published date for each item in the RSS feed to identify whether it needs to update its records. TODO: if we use OAI-PMH for harvesting we can request courses updated since x see http://moodle.org/mod/forum/discuss.php?d=127488

If the course has been updated and is <moodlehub:downloadable> is yes, then the hub will request the site to create a new backup of the entire course (less user data).

= Schedule =

Full schedule and progress is in the tracker: MDL-19309

# Moodle.org Hub List
# Hub registration form
# Hub Web interface
# Hub web service interface
# Improve Site registration form
# Community block
# Publish courses
# Import courses
# Export courses
# Harvest courses

= See also =

* [[Community hub technotes]] - relating to MNet developments in Moodle 1.8
* MDL-18580 - Community Hub tracker issue

[[Category:MNET]]

[[ja:開発:コミュニティハブ]]

Development:Community hub

2009-07-06T14:48:34Z

Jenny-gray: /* Schedule */

{{Work in progress}}{{Moodle 2.0}}

* '''PROJECT STATE: Proposal'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc (automatic and/or manual).
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
* (E) The repository API downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more CDS (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a CDS (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there (with or without Mnet).

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
# Teacher browses a list of downloadable courses in the File picker (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Find community".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Find community". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://moodle.org/hubs http://moodle.org/hubs] as well as a simple XML format from [http://moodle.org/hubs/list.xml http://moodle.org/hubs/list.xml] suitable for consumption by Moodle sites.

{| class="nicetable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubname
|varchar
|Name of the Hub
|-
|hubdescription
|text
|Description of the hub, from the admin there
|-
|huburl
|varchar
|The full URL to the hub front page
|-
|hubsecret
|varchar
|The secret code from the hub (extra authentication)
|-
|trusted
|int
|Is the hub trusted? Does it have good quality control?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|sites
|int
|Number of sites registered on this hub
|-
|courses
|int
|Number of courses registered on this hub
|-
|timefirst
|int
|Time that the hub was first registered
|-
|timelast
|int
|Time that the hub was last registered/updated
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|image
|varchar
|hub logo url
|}

[[Image:Registerhub.png]]

following a hub list table on Moodle.org:
[[Image:Hublist.png]]

==Moodle Hub Server==

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A default installation of Moodle can also be a Hub, or if the admin chooses, a site can be a dedicated Hub if they choose that option during install (in this case the front page of the site will be a dedicated site search for the public).

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name
* description
* language
* contact name
* contact email
* enable
* hub secret (generated the first time the hub is registered on Moodle.org, it will never change)
* logo url
* protected web search interface '''(TODO: the protection method needs to be defined)'''

=== Data structure ===

==== Sites ====

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites].

* Id
* Site name
* Site description
* URL
* Address
*# Country code (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
*# Region/state (based on list) [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)]
*# Street address
*# Geolocation (for mapping)
* Site manager
*# Name
*# Email
*# Phone
* Contact form yes/no?
* Default site language
* Moodle version (eg 2009050502)
* Moodle release (eg 1.9.5+)
* Site ip address (updated at every update)
* Unique SiteID code generated by Moodle site
* Confirmed by admin
* Site is "trusted" - this means we don't manually check data in future from this site.
* Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
* Harvesting url
* Time updated
* Time created
* Currently unreachable
* Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

* Tool usage stats
** number of courses
** number of users
** number of enrolments
** number of posts
** number of resources
** number of questions
** median course size
* Subscribed to securityalerts@lists.moodle.org

==== Courses ====

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

* Course ID
* Site ID (foreign key to sites table)
* Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([https://docs.moodle.org/en/Course_Standard_Tags Course Standard Tags ])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)
* Audience: Educators | Students | Admins
* Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
* Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )

* Availability (public/private)
* Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
* Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
* Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
* Is the course enrollable anyone with an account?
* Is guest access allowed?
* Are screenshots supplied? (stored on disk under id of this record)
* Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
* Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

=== Web user interface ===

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Here is a very rough mockup of how it could look:

[[Image:Webinterface.png]]

[[Image:Search_hub_moodle.png]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - <span style=color:blue>use comment 2.0 API</span>

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable <span style=color:blue>(first tag retrieved by the request is considered)</span>''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Date last checked (by a cron job)
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service user interface ===

A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface (at http://hubsite.org/hub) where the hub is managed. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Site registration ==

The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis.
# choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image)

Each Moodle.org Hub will perform a check every week to verify that each site is accessible and optionally to harvest the courses from that site. Sites that fail two or three checks in a row will be disable in the Hub listing.

[[Image:SiteRegistration.png|900px]]

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|900px]]

== Import/Export courses ==

The Import/Export block will be available on course pages and contains buttons to:

* '''Publish course''': to publish or update the description of the current course in one or more Hubs (admins only)
* '''Export course''': publish/upload entire course (as Moodle Backup minus userdata) somewhere (eg a Hub) (via Portfolio API plugins)
* '''Import course''': find/download/install a course template from a Hub or from another course on same site (Repository API plugins)

=== Publish course ===

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|900px]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable, so that others can come here and use the course where it is, and/or
* downloadable, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub. The Hub will bounce back a confirmation which gets saved locally as the "Last publish date" for that course.

If the checkbox to allow download was selected, then the URL to a course download script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

=== Export course ===

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. Portfolio (export) plugins could include:

* downloading it to the local computer
* uploading it as a zip to any general purpose repository
* copy the course to another Moodle site set up with Mnet peering.

Pushing it to another Moodle site would trigger extra behaviours:

* Permissions would be checked on the destination Moodle
* The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
* Someone on the external Moodle can be alerted to approve/unhide the new course

=== Import course ===

The '''Import course''' button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

* find Hubs by downloading the Hub List
* search particular Hubs for downloadable courses (only)
* search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses and passed any challenge there might be (eg the Hub could potentially require a password or payment or a license agreement form), then the zip file is downloaded to the local Moodle, and then the user is passed to the standard restore process.

[[Image:FilePicker_all_JS.png|900px]]
[[Image:FilePicker_JS_course_selector.png|900px]]

= Schedule =

Full schedule and progress is in the tracker: MDL-19309

# Moodle.org Hub List
# Hub registration form
# Hub Web interface
# Hub web service interface
# Improve Site registration form
# Community block
# Publish courses
# Import courses
# Export courses
# Harvest courses

= See also =

* [[Community hub technotes]] - relating to MNet developments in Moodle 1.8
* MDL-18580 - Community Hub tracker issue

[[Category:MNET]]

[[ja:開発:コミュニティハブ]]

Development:Community hub

2009-07-06T14:47:55Z

Jenny-gray: /* Site registration */

{{Work in progress}}{{Moodle 2.0}}

* '''PROJECT STATE: Proposal'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc (automatic and/or manual).
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
* (E) The repository API downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more CDS (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a CDS (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there (with or without Mnet).

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
# Teacher browses a list of downloadable courses in the File picker (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Find community".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Find community". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://moodle.org/hubs http://moodle.org/hubs] as well as a simple XML format from [http://moodle.org/hubs/list.xml http://moodle.org/hubs/list.xml] suitable for consumption by Moodle sites.

{| class="nicetable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubname
|varchar
|Name of the Hub
|-
|hubdescription
|text
|Description of the hub, from the admin there
|-
|huburl
|varchar
|The full URL to the hub front page
|-
|hubsecret
|varchar
|The secret code from the hub (extra authentication)
|-
|trusted
|int
|Is the hub trusted? Does it have good quality control?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|sites
|int
|Number of sites registered on this hub
|-
|courses
|int
|Number of courses registered on this hub
|-
|timefirst
|int
|Time that the hub was first registered
|-
|timelast
|int
|Time that the hub was last registered/updated
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|image
|varchar
|hub logo url
|}

[[Image:Registerhub.png]]

following a hub list table on Moodle.org:
[[Image:Hublist.png]]

==Moodle Hub Server==

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A default installation of Moodle can also be a Hub, or if the admin chooses, a site can be a dedicated Hub if they choose that option during install (in this case the front page of the site will be a dedicated site search for the public).

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name
* description
* language
* contact name
* contact email
* enable
* hub secret (generated the first time the hub is registered on Moodle.org, it will never change)
* logo url
* protected web search interface '''(TODO: the protection method needs to be defined)'''

=== Data structure ===

==== Sites ====

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites].

* Id
* Site name
* Site description
* URL
* Address
*# Country code (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
*# Region/state (based on list) [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)]
*# Street address
*# Geolocation (for mapping)
* Site manager
*# Name
*# Email
*# Phone
* Contact form yes/no?
* Default site language
* Moodle version (eg 2009050502)
* Moodle release (eg 1.9.5+)
* Site ip address (updated at every update)
* Unique SiteID code generated by Moodle site
* Confirmed by admin
* Site is "trusted" - this means we don't manually check data in future from this site.
* Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
* Harvesting url
* Time updated
* Time created
* Currently unreachable
* Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

* Tool usage stats
** number of courses
** number of users
** number of enrolments
** number of posts
** number of resources
** number of questions
** median course size
* Subscribed to securityalerts@lists.moodle.org

==== Courses ====

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

* Course ID
* Site ID (foreign key to sites table)
* Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([https://docs.moodle.org/en/Course_Standard_Tags Course Standard Tags ])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)
* Audience: Educators | Students | Admins
* Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
* Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )

* Availability (public/private)
* Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
* Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
* Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
* Is the course enrollable anyone with an account?
* Is guest access allowed?
* Are screenshots supplied? (stored on disk under id of this record)
* Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
* Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

=== Web user interface ===

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Here is a very rough mockup of how it could look:

[[Image:Webinterface.png]]

[[Image:Search_hub_moodle.png]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - <span style=color:blue>use comment 2.0 API</span>

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable <span style=color:blue>(first tag retrieved by the request is considered)</span>''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Date last checked (by a cron job)
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service user interface ===

A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface (at http://hubsite.org/hub) where the hub is managed. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Site registration ==

The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis.
# choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image)

Each Moodle.org Hub will perform a check every week to verify that each site is accessible and optionally to harvest the courses from that site. Sites that fail two or three checks in a row will be disable in the Hub listing.

[[Image:SiteRegistration.png|900px]]

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|900px]]

== Import/Export courses ==

The Import/Export block will be available on course pages and contains buttons to:

* '''Publish course''': to publish or update the description of the current course in one or more Hubs (admins only)
* '''Export course''': publish/upload entire course (as Moodle Backup minus userdata) somewhere (eg a Hub) (via Portfolio API plugins)
* '''Import course''': find/download/install a course template from a Hub or from another course on same site (Repository API plugins)

=== Publish course ===

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|900px]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable, so that others can come here and use the course where it is, and/or
* downloadable, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub. The Hub will bounce back a confirmation which gets saved locally as the "Last publish date" for that course.

If the checkbox to allow download was selected, then the URL to a course download script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

=== Export course ===

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. Portfolio (export) plugins could include:

* downloading it to the local computer
* uploading it as a zip to any general purpose repository
* copy the course to another Moodle site set up with Mnet peering.

Pushing it to another Moodle site would trigger extra behaviours:

* Permissions would be checked on the destination Moodle
* The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
* Someone on the external Moodle can be alerted to approve/unhide the new course

=== Import course ===

The '''Import course''' button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

* find Hubs by downloading the Hub List
* search particular Hubs for downloadable courses (only)
* search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses and passed any challenge there might be (eg the Hub could potentially require a password or payment or a license agreement form), then the zip file is downloaded to the local Moodle, and then the user is passed to the standard restore process.

[[Image:FilePicker_all_JS.png|900px]]
[[Image:FilePicker_JS_course_selector.png|900px]]

= Schedule =

Full schedule and progress is in the tracker: MDL-19309

# Moodle.org Hub List
# Hub registration form
# Hub Web interface
# Hub web service interface
# Improve Site registration form
# Community block
# Publish courses
# Import courses
# Export courses

= See also =

* [[Community hub technotes]] - relating to MNet developments in Moodle 1.8
* MDL-18580 - Community Hub tracker issue

[[Category:MNET]]

[[ja:開発:コミュニティハブ]]

Development:Community hub

2009-07-06T14:46:22Z

Jenny-gray: /* Sites */

{{Work in progress}}{{Moodle 2.0}}

* '''PROJECT STATE: Proposal'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc (automatic and/or manual).
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
* (E) The repository API downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more CDS (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a CDS (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there (with or without Mnet).

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
# Teacher browses a list of downloadable courses in the File picker (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Find community".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Find community". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new open source web application for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://moodle.org/hubs http://moodle.org/hubs] as well as a simple XML format from [http://moodle.org/hubs/list.xml http://moodle.org/hubs/list.xml] suitable for consumption by Moodle sites.

{| class="nicetable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubname
|varchar
|Name of the Hub
|-
|hubdescription
|text
|Description of the hub, from the admin there
|-
|huburl
|varchar
|The full URL to the hub front page
|-
|hubsecret
|varchar
|The secret code from the hub (extra authentication)
|-
|trusted
|int
|Is the hub trusted? Does it have good quality control?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|sites
|int
|Number of sites registered on this hub
|-
|courses
|int
|Number of courses registered on this hub
|-
|timefirst
|int
|Time that the hub was first registered
|-
|timelast
|int
|Time that the hub was last registered/updated
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|image
|varchar
|hub logo url
|}

[[Image:Registerhub.png]]

following a hub list table on Moodle.org:
[[Image:Hublist.png]]

==Moodle Hub Server==

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A default installation of Moodle can also be a Hub, or if the admin chooses, a site can be a dedicated Hub if they choose that option during install (in this case the front page of the site will be a dedicated site search for the public).

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name
* description
* language
* contact name
* contact email
* enable
* hub secret (generated the first time the hub is registered on Moodle.org, it will never change)
* logo url
* protected web search interface '''(TODO: the protection method needs to be defined)'''

=== Data structure ===

==== Sites ====

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites].

* Id
* Site name
* Site description
* URL
* Address
*# Country code (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
*# Region/state (based on list) [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)]
*# Street address
*# Geolocation (for mapping)
* Site manager
*# Name
*# Email
*# Phone
* Contact form yes/no?
* Default site language
* Moodle version (eg 2009050502)
* Moodle release (eg 1.9.5+)
* Site ip address (updated at every update)
* Unique SiteID code generated by Moodle site
* Confirmed by admin
* Site is "trusted" - this means we don't manually check data in future from this site.
* Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
* Harvesting url
* Time updated
* Time created
* Currently unreachable
* Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

* Tool usage stats
** number of courses
** number of users
** number of enrolments
** number of posts
** number of resources
** number of questions
** median course size
* Subscribed to securityalerts@lists.moodle.org

==== Courses ====

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

* Course ID
* Site ID (foreign key to sites table)
* Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([https://docs.moodle.org/en/Course_Standard_Tags Course Standard Tags ])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)
* Audience: Educators | Students | Admins
* Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
* Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )

* Availability (public/private)
* Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
* Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
* Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
* Is the course enrollable anyone with an account?
* Is guest access allowed?
* Are screenshots supplied? (stored on disk under id of this record)
* Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
* Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

=== Web user interface ===

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Here is a very rough mockup of how it could look:

[[Image:Webinterface.png]]

[[Image:Search_hub_moodle.png]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - <span style=color:blue>use comment 2.0 API</span>

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable <span style=color:blue>(first tag retrieved by the request is considered)</span>''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Date last checked (by a cron job)
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service user interface ===

A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface (at http://hubsite.org/hub) where the hub is managed. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Site registration ==

The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis.

Each Moodle.org Hub will perform a check every week to verify that each site is accessible. Sites that fail two or three checks in a row will be disable in the Hub listing.

[[Image:SiteRegistration.png|900px]]

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|900px]]

== Import/Export courses ==

The Import/Export block will be available on course pages and contains buttons to:

* '''Publish course''': to publish or update the description of the current course in one or more Hubs (admins only)
* '''Export course''': publish/upload entire course (as Moodle Backup minus userdata) somewhere (eg a Hub) (via Portfolio API plugins)
* '''Import course''': find/download/install a course template from a Hub or from another course on same site (Repository API plugins)

=== Publish course ===

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|900px]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable, so that others can come here and use the course where it is, and/or
* downloadable, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub. The Hub will bounce back a confirmation which gets saved locally as the "Last publish date" for that course.

If the checkbox to allow download was selected, then the URL to a course download script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

=== Export course ===

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. Portfolio (export) plugins could include:

* downloading it to the local computer
* uploading it as a zip to any general purpose repository
* copy the course to another Moodle site set up with Mnet peering.

Pushing it to another Moodle site would trigger extra behaviours:

* Permissions would be checked on the destination Moodle
* The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
* Someone on the external Moodle can be alerted to approve/unhide the new course

=== Import course ===

The '''Import course''' button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

* find Hubs by downloading the Hub List
* search particular Hubs for downloadable courses (only)
* search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses and passed any challenge there might be (eg the Hub could potentially require a password or payment or a license agreement form), then the zip file is downloaded to the local Moodle, and then the user is passed to the standard restore process.

[[Image:FilePicker_all_JS.png|900px]]
[[Image:FilePicker_JS_course_selector.png|900px]]

= Schedule =

Full schedule and progress is in the tracker: MDL-19309

# Moodle.org Hub List
# Hub registration form
# Hub Web interface
# Hub web service interface
# Improve Site registration form
# Community block
# Publish courses
# Import courses
# Export courses

= See also =

* [[Community hub technotes]] - relating to MNet developments in Moodle 1.8
* MDL-18580 - Community Hub tracker issue

[[Category:MNET]]

[[ja:開発:コミュニティハブ]]

Development talk:Community hub

2009-06-30T14:48:11Z

Jenny-gray: /* Harvesting courses regularly and a few other comments */

Regarding the course import for teachers to start from...
I can envisage a situation whereby the original course author finds new information/ideas and adds stuff to the master course after the teacher has downloaded it, which in the current model would not make it to the teacher as the download is a one off process which they will not repeat. I would prefer a model whereby a course can act as a master template which gets updated regularly so that new questions, resources, activities etc appear dynamically as hidden items within the teacher's downloaded course, ready to be reviewed and revealed if needed. This would be like maintaining your Moodle install using CVS - you get updates all the time as they are created.

It would also be good to be able to track how many people are using a particular course and to have some sort of meta-forum for discussing changes and developemts. Many teachers will end up using the successful/well designed courses, so it would make a lot of sense to have a way of pooling their shared experience and getting that feedback back to the original creator. -- [[User:Matt Gibson|Matt Gibson]] 18:51, 25 June 2009 (UTC)

== Harvesting courses regularly and a few other comments ==

I've put this in the forum, but I'll say it here as well. If a site has a lot of courses to share with a hub, perhaps because they are an OpenCourseWare provider, they might prefer to supply an RSS or OAI list rather than click "publish" on each individual course. OCW Consortium members are already encouraged to offer an RSS feed (with DC metadata) of all their courses that is picked up by a number of OCW search tools. I'm sure Moodle users in that community would love the same approach to mean they could be included in the hubs as well.

To aid course harvesting (but to make publishing easier anyway) I'd like to see the DC metadata editing screen become part of the standard course settings screen, and the data pulled from here as part of the publish to hub functionality (and into any RSS or OAI service).

Using LOM as well as (or instead of) DC would allow more flexible searching at the hub with relatively little extra cost of data inputting.

Finally, there is a great deal of discussion in the OCW community about asset-level re-use. Anecdotal evidence from teachers suggests that the course-level is not fine-grained enough and they'd prefer to pick a single resource/image/activity. See http://opencontent.org/blog/archives/900 and related comments for example. So I'd like to see DC metadata added to resources and modules too, and the searching and import/export/enrol facility in the hub system work at this level also.
-- [[User:Jenny Gray|Jenny Gray]] 14:48, 30 June 2009 (GMT)

Development talk:Community hub

2009-06-30T14:47:25Z

Jenny-gray: /* Harvesting courses regularly and a few other comments */ new section

Course rate block

2009-02-24T15:31:04Z

Jenny-gray: /* Advanced Options */

==Couse Rating Block==

The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have made ratings.

[[Image:Rateimg.jpg]]

Each user can rate a course only once. If they visit the ratings form again, a message is displayed to indicate that they've already rated the course, and the (disabled) form displays the rating they gave.

===Installation===

Most users will want to download the "for Moodle 1.9" version, since the latest version (in CVS HEAD) is compatible with Moodle 2.0 which has not yet been released.

*Copy the files into the \blocks folder.
*Go to the \admin page and allow the block to be installed
*Add the block to your course pages to display course ratings

=== Roles and Permissions ===

The default installation will allow all roles except for Guest and Authenticated User to rate a course. All users, regardless of role, can see ratings.

===Languages===

English only.

===Advanced Options===

You can get the rating graphic displayed anywhere you want by adding this code at the right point:

$block = block_instance('rate_course');
$block->display_rating($course->id);

We've added this to our course listings so you can see the rating for each course as you browse through the categories. To do the same, edit course/lib.php and paste the code in the print_course() function wherever you want it to appear.

=== To Do ===

It would be great if users could enter their rating by clicking directly on the star graphic in the block, using AJAX, rather than have to go to a separate page, submit a form and return to the course home page. This would need to be an option, so that sites (or users) which do not have AJAX enabled could continue to use the form page.

===Contributor/Maintainer===

The Course Ratings Block was contributed and is maintained by Jenny Gray.

[[Category:Contributed code]]

Course rate block

2009-02-18T08:58:28Z

Jenny-gray:

Course rate block

2009-02-17T09:30:17Z

Jenny-gray: New page: ==Couse Rating Block== The block contains a link to a separate form page to give a rating, and displays the current aggregate of all user ratings including the number of people who have m...

File:Rateimg.jpg

2009-02-17T09:26:21Z

Jenny-gray: screenshot for the course ratings block

screenshot for the course ratings block

Development:MoodleMoot 2007 HackFest

2007-10-23T13:03:35Z

Jenny-gray: /* Social Networking tools */

The main part of the [http://moodlemoot.org/ 2007 UK Moodle Moot] is on Wednesday and Thursday 24th and 25th October. The day before, on the Tuesday, there will be a HackFest for developers to meet, talk and write code.

==Practical arrangement==

You need to get [http://maps.google.co.uk/maps?ll=52.025356,-0.710997&spn=0.001005,0.001904&t=k&z=19 right here]. This is the centre of the Open University's Campus:

[http://www3.open.ac.uk/contact/ The Open University]<br />
Walton Hall<br />
Milton Keynes<br />
[http://maps.google.co.uk/?q=mk7+6aa&ie=UTF8&om=1&f=d MK7 6AA]

The area we are meeting in is called the Christodoulou Meeting Rooms. The entry is under an archway, and if you go in and up the stairs you should find us in Meeting Room 15, or the open foyer area just outside it. We will be there from about 10:00am to about 5:30pm, and lunch will be provided. We also have rooms 1, 2 and 7 available if people want to form smaller groups at any time. (Also, in meeting room 11, there will be a separate group of people taking about online equation editors, which may interest some people.)

If you are registered for the MoodleMoot, wireless network sign-in information should be available on arrival.

==Programme for the day==

In keeping with Moodle's open source philosophy, the day will be self-organising. You can turn up and talk to other developers about anything you like. However, within that general free-for-all, we will have a number of pre-announced discussions on particular topics at particular times. We have a number of other rooms available for these break-out sessions, but I don't know the room numbers right now.

Please feel free to add your own suggestions below.

Naturally, not all developers will be able to come, so it might be a good idea to start discussing some of these topics in the [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum] now. And if anything significant comes out of the discussions, we should try to record it on the wiki.

==Particular discussions==

These are significant topics, where it might be worth getting about 5-10 interested developers into a break-out room for a focussed discussion on one topic, or a demonstration of a particular idea.

Irrespective of these sessions, there will be other developers around talking about whatever interests them all day.

===Repository API===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || 10:30 - 11:20
|-
| Room: || CMR07
|-
| Suggested by: || Martin Dougiamas
|}

# Portfolio separate from repo
# We need to think carefully/clearly about when to copy and when not to
# Think users, not roles
# It's very complicated

===Social Networking tools===
{|
|-
| Time: || 11:20 - 12:00
|-
| Room: || CMR07
|-
| Suggested by: || Jenny Gray
|-
|}

The aim is to discuss recent user tagging in Moodle and how it can be used; to think about what else can be tagged (courses, resources, activities etc); and to think about how Moodle can be made more social. Here are some suggestions made to me recently:

* Learning twitter
* Learning shared to do
* Offering self-organising groups of learners their own activity areas (forums etc)
* shared activity reports

Session feedback:

* unit tagging from OU to be integrated into new tags block for Moodle 2.0
* should we push into third party social networking tools or pull from them?
** push into will be unpopular with students who see these networks a their private space
* any moodle site could add extra user profile fields like status, mood with existing core functionality
* ideas for extension
** see other people's tag clouds
** when it says "3 things tagged with this", want to know who made those tags
** need fine grained control over who can tag what
** need to make sure that when things are deleted the tags go too
** want to be able to tag other people
** want to be able to choose to keep my tags private (probably with an admin setting to control whether this feature is enabled or not)
* facebook apps style API for moodle plug-ins
** scarey for sys-admins (facebook do it with the app on a separate server)
** maybe something simple could be done with a better database module
** something for a lot later!

=== Accessibility demonstration ===
My colleague Chetz Colwell and I would like to give a brief demonstration of assistive technologies to developers, particularly core developers, and discuss future accessibility work on Moodle. We'll hopefully have a screen reader JAWS (Thunder?), screen magnifier, do a keyboard-only demo, and possibly speech recognition.
{|
|-
| Time: || 12:00 to 12:40
|-
| Room: || CMR15
|-
| Suggested by: || Nick Freear
|}

===Quiz developments===
{|
|-
| Time: || 1:40 to 2:20
|-
| Room: || CMR07
|-
| Suggested by: || Tim Hunt
|}
We can discuss some things that have happened recently:
* The implication of [[Development:Plan_to_Improve_Flexibility_of_Question_Category_Sharing_and_Permissions|Jamie's recent changes to the question bank]],
* Improvements to the question type API, especially [[Development:Plans_for_enhancing_import/export_in_questiontype_plugins|Howard's recent changes]],
some things that will probably happen soon:
* The OU's quiz navigation changes, that we hope to put into Moodle 2.0,
* The OU's [[Development:Plans_for_adaptive_mode|changes to adaptive mode]] that we hope to put into Moodle 2.0,
* Tony Gardner-Medwin's plans to introduce certainty-based marking,
known problems with the quiz architecture that no-one is working on right now:
* ... suggestions welcome ...
and anything else you want to raise.

Of course, you can talk to me about the quiz at any time time during the day too, if you have a more specific issue.

===ePortfolios===
{|
|-
| Time: || 2:20 to 3:00
|-
| Room: || CMR07
|-
| Suggested by: || Thanh Le
|}
A quick overview of the Open University electronic portfolio tool and describing its technical underpinning to provide more background information.

From the session, I am keen to:
* gauge people's interest in the tool;
* discuss how the tool can integrate with other Moodle tools around the concept of personal data storage;
* gather interest and collaboration;

===Conditional Activities===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || 3:00 - 3:40
|-
| Room: || CMR07
|-
| Suggested by: || Martin Dougiamas
|}

===Offline Moodle (and particularly synchronisation issues)===
Offline Moodle reuses the core components on Backup and mNet(Moodle Network) and adds a synchronisation component to take care of tasks that Moodle doesn't already cater for.

The components are used because they are core components. They already offer functionality that we require and as they evolve the Offline Moodle feature will be able to take advantage of the extra features, functionality and reliability they provide.

Because this is a new feature I'll explain a little about how we use the comments and then jot a few questions down that have come up:
Backup and restore is used to get information in and out of Moodle in a standardised format well understood by Moodle. It is supported by most modules and features and is likely to be fixed quickly as changes to modules effect the backup process.
* Will the backup tool scale effectively
* Will changes for Offline Moodle harm the backup code?

Moodle Network is used to provide web service functionality.
* is Moodle Network the best option for this?
* has the web service been implemented correctly?

Synchronisation (Synch) Component
This component is really the main controller of synchronisation whic is the key feature of Offline Moodle at this time. We've spent a lot of our time developing code to get the content in and out of Moodle and transferred between Moodles in a reliable and well managed fashion. The synch component brings all this together.

So far we've proven that we can reliably get course content and related module content from Moodle Server to Offline Moodle. For forums we can get it back again. We've investigated lots more but haven't code it yet.

We would like the communities input. The plan is to improve it by adding functionality such as:
* merging content: this is a key feature. For example merging a forum discussion with posts from the Offline Moodle and the Moodle Server. Our original proof of concept proved this is possible for forums but the code has not been written for Offline Moodle
* filtering content: passwords, copyrighted material and other sensitive data all need to be removed at certain points through out the process
* security: checks for hacking, viruses and trojans, making sure the data doesn't get changed in transit. These are all key issues that need to be addressed.

{|
|-
| Time: || 3:40 - 4:20
|-
| Room: || CMR07
|-
| Suggested by: || Colin Chambers
|}

==Other things people want to do during the day==

=== PGP Keysiging ===
If any developers would like to exchange PGP Keys and expand their web of trust then this could be done during the Developer day.

I think it would be good to follow the [http://www.debian.org/events/keysigning Debian guidlines] for this.--[[User:Dan Poltawski|Dan Poltawski]] 18:03, 10 October 2007 (CDT)

===Enrollment 'Groups'===
I would like to discuss the concept of enrollment groups and thoughts on the reasons for such a feature to be incorporated into Moodle. It would be a useful opportunity to discuss approaches with developers. This is with the intention of implementing a solution and offering it for inclusion into core when I work on this in the coming months. --[[User:Dan Poltawski|Dan Poltawski]] 16:46, 16 October 2007 (CDT)

===Bug fixing prize?===

Should we offer a prize for the person who fixes most bugs during the day?--[[User:Tim Hunt|Tim Hunt]] 03:46, 14 October 2007 (CDT)

Sorry I won't be there,
Ok if you mean somebody submitting the larger number of proposals approved by at least one of the participants, on how to solve various bug. No real code please, if you don't want to create new ones...[[User:Pierre Pichet|Pierre Pichet]] 18:34, 19 October 2007 (CDT)

==See also==

* [[Developer conferences]]
* [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum]

[[Category:Developer]]

Development:MoodleMoot 2007 HackFest

2007-10-19T08:07:13Z

Jenny-gray: /* Social Networking tools */

The main part of the [http://moodlemoot.org/ 2007 UK Moodle Moot] is on Wednesday and Thursday 24th and 25th October. The day before, on the Tuesday, there will be a HackFest for developers to meet, talk and write code.

==Practical arrangement==

You need to get [http://maps.google.co.uk/maps?ll=52.025356,-0.710997&spn=0.001005,0.001904&t=k&z=19 right here]. This is the centre of the Open University's Campus:

[http://www3.open.ac.uk/contact/ The Open University]<br />
Walton Hall<br />
Milton Keynes<br />
[http://maps.google.co.uk/?q=mk7+6aa&ie=UTF8&om=1&f=d MK7 6AA]

The area we are meeting in is called the Christodoulou Meeting Rooms. The entry is under an archway, and if you go in and up the stairs you should find us in Meeting Room 15, or the open foyer area just outside it. We will be there from about 10:00am to about 5:30pm, and lunch will be provided.

If you are registered for the MoodleMoot, wireless network sign-in information should be available on arrival.

==Programme for the day==

In keeping with Moodle's open source philosophy, the day will be self-organising. You can turn up and talk to other developers about anything you like. However, within that general free-for-all, we will have a number of pre-announced discussions on particular topics at particular times. We have a number of other rooms available for these break-out sessions, but I don't know the room numbers right now.

Please feel free to add your own suggestions below.

Naturally, not all developers will be able to come, so it might be a good idea to start discussing some of these topics in the [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum] now. And if anything significant comes out of the discussions, we should try to record it on the wiki.

==Particular discussions==

These are significant topics, where it might be worth getting about 5-10 interested developers into a break-out room for a focussed discussion on one topic, or a demonstration of a particular idea.

Irrespective of these sessions, there will be other developers around talking about whatever interests them all day.

=== Accessibility demonstration ===
My colleague Chetz Colwell and I would like to give a brief demonstration of assistive technologies to developers, particularly core developers, and discuss future accessibility work on Moodle. We'll hopefully have a screen reader JAWS (Thunder?), screen magnifier, do a keyboard-only demo, and possibly speech recognition.
{|
|-
| Time: || 10:00 to 10:40
|-
| Room: || ??
|-
| Suggested by: || Nick Freear
|}

===Repository API===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || 10:40 - 11:20
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Social Networking tools===
{|
|-
| Time: || 11:20 - 12:00
|-
| Room: || ??
|-
| Suggested by: || Jenny Gray
|-
|}

The aim is to discuss recent user tagging in Moodle and how it can be used; to think about what else can be tagged (courses, resources, activities etc); and to think about how Moodle can be made more social. Here are some suggestions made to me recently:

* Learning twitter
* Learning shared to do
* Offering self-organising groups of learners their own activity areas (forums etc)
* shared activity reports

===Quiz developments===
{|
|-
| Time: || 1:40 to 2:20
|-
| Room: || ??
|-
| Suggested by: || Tim Hunt
|}
We can discuss some things that have happened recently:
* The implication of [[Development:Plan_to_Improve_Flexibility_of_Question_Category_Sharing_and_Permissions|Jamie's recent changes to the question bank]],
* Improvements to the question type API, especially [[Development:Plans_for_enhancing_import/export_in_questiontype_plugins|Howard's recent changes]],
some things that will probably happen soon:
* The OU's quiz navigation changes, that we hope to put into Moodle 2.0,
* The OU's [[Development:Plans_for_adaptive_mode|changes to adaptive mode]] that we hope to put into Moodle 2.0,
* Tony Gardner-Medwin's plans to introduce certainty-based marking,
known problems with the quiz architecture that no-one is working on right now:
* ... suggestions welcome ...
and anything else you want to raise.

Of course, you can talk to me about the quiz at any time time during the day too, if you have a more specific issue.

===ePortfolios===
{|
|-
| Time: || 2:20 to 3:00
|-
| Room: || ??
|-
| Suggested by: || Thanh Le
|}

===Conditional Activities===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || 3:00 - 3:40
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Offline Moodle (and particularly synchronisation issues)===
Offline Moodle reuses the core components on Backup and mNet(Moodle Network) and adds a synchronisation component to take care of tasks that Moodle doesn't already cater for.

The components are used because they are core components. They already offer functionality that we require and as they evolve the Offline Moodle feature will be able to take advantage of the extra features, functionality and reliability they provide.

Because this is a new feature I'll explain a little about how we use the comments and then jot a few questions down that have come up:
Backup and restore is used to get information in and out of Moodle in a standardised format well understood by Moodle. It is supported by most modules and features and is likely to be fixed quickly as changes to modules effect the backup process.
* Will the backup tool scale effectively
* Will changes for Offline Moodle harm the backup code?

Moodle Network is used to provide web service functionality.
* is Moodle Network the best option for this?
* has the web service been implemented correctly?

Synchronisation (Synch) Component
This component is really the main controller of synchronisation whic is the key feature of Offline Moodle at this time. We've spent a lot of our time developing code to get the content in and out of Moodle and transferred between Moodles in a reliable and well managed fashion. The synch component brings all this together.

So far we've proven that we can reliably get course content and related module content from Moodle Server to Offline Moodle. For forums we can get it back again. We've investigated lots more but haven't code it yet.

We would like the communities input. The plan is to improve it by adding functionality such as:
* merging content: this is a key feature. For example merging a forum discussion with posts from the Offline Moodle and the Moodle Server. Our original proof of concept proved this is possible for forums but the code has not been written for Offline Moodle
* filtering content: passwords, copyrighted material and other sensitive data all need to be removed at certain points through out the process
* security: checks for hacking, viruses and trojans, making sure the data doesn't get changed in transit. These are all key issues that need to be addressed.

{|
|-
| Time: || 3:40 - 4:20
|-
| Room: || ??
|-
| Suggested by: || Colin Chambers
|}

==Other things people want to do during the day==

=== PGP Keysiging ===
If any developers would like to exchange PGP Keys and expand their web of trust then this could be done during the Developer day.

I think it would be good to follow the [http://www.debian.org/events/keysigning Debian guidlines] for this.--[[User:Dan Poltawski|Dan Poltawski]] 18:03, 10 October 2007 (CDT)

===Enrollment 'Groups'===
I would like to discuss the concept of enrollment groups and thoughts on the reasons for such a feature to be incorporated into Moodle. It would be a useful opportunity to discuss approaches with developers. This is with the intention of implementing a solution and offering it for inclusion into core when I work on this in the coming months. --[[User:Dan Poltawski|Dan Poltawski]] 16:46, 16 October 2007 (CDT)

===Bug fixing prize?===

Should we offer a prize for the person who fixes most bugs during the day?--[[User:Tim Hunt|Tim Hunt]] 03:46, 14 October 2007 (CDT)

==See also==

* [[Developer conferences]]
* [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum]

[[Category:Developer]]

Development:MoodleMoot 2007 HackFest

2007-10-11T13:42:52Z

Jenny-gray: /* Social Networking tools */

Development:Course level ratings

2006-09-01T14:24:52Z

Jenny-gray: /* See also */

For users to be able to "rate" courses in a similar way to the way [[Forum module|forum]] ratings work.

==See also==

* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=53023 Course level ratings - request for comment] forum discussion

=== Functionality ===

For a course which has been set up to use ratings, through a block, the user can pick a value from a drop-down list and click a button "send my rating" to submit their rating. The block also displays the average of all ratings received so far and the number of ratings e.g 3 / 5 (2).

If a user has not yet rated the course, then the drop-down list will say "rate...". Otherwise it will display their current rating. If they amend and re-submit, the average rating will be updated, but the number of ratings does not change. No record of the first rating is retained.

This is basically the same as the way ratings are entered for forum posts.

Note that the rating average value and number of entries will also be displayed with other extended course metadata from the expanded display on the course categories pages.

The admin user, and teacher(s) for the course, can click on the current rating to see the list of who has rated the course and the score they gave. This information is not available to students.

Note, if ratings have not been enabled for the course, the block displays a message and link "please enable ratings in the course settings" for teachers/admin and is invisible to users.

=== Editing interface ===

The course settings screen will have two new fields:

* a check box whether ratings are to be used or not.
* a drop-down list of numbers 1-100 for the scale to be used.

The block will also need to appear in the Add blocks list.

====Extensions====

Like forums, it is possible that other types of grading might be possible, but these will be considered later. The use of this approach should mean that other forms of grading can be added.

Course scales allow a course can have custom scales defined. It would make sense to make 0-5 (our default) a site-wide scale, and allow the course admin screen to select any of the site-wide or custom scales for that course.

=== Database structure ===

New table course_ratings

* id
* userid
* course
* time
* rating

Additions to course

* assessed (true/false)
* scale

====Extensions====

To offer full similarity with forums, would need extra field:

* assesspublic which would be true/false depending on whether users can see each other's ratings. For now, will default assume true.

And extended field:

* assessed (0/1 as above then 2 for teacher only ratings)

[[Category:Developer]]