MoodleDocs - User contributions [en]

Latest release notes

2007-10-03T09:00:49Z

Lazyfish: /* Headline features */

{{About Moodle}}

==Moodle 1.9 Beta==

Released: 14th August 2007

This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)

Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&styleName=Html&version=10190 the full list of fixed issues in 1.9 so far].

===Headline features===

* [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)
:: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.
* [[Development:Outcomes|Outcomes]] - Moodle.com
:: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).
* [[Development:Events|Events API]] - Moodle.com
::The new Events API provides a way for any code to "hook" into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.
* [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])
:: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.
* [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].
::Allows questions to be shared by the whole site, a course category, a singe course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.
* [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])
:: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).
* [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])
::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates.
* New Custom Corners theme - Urs Hunkler
:: Beautiful and curvy (in all browsers).

===Other major improvements===

* Groups and Groupings
:: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x.
* New theme settings
** Category themes - can now set the theme for a category which will apply to all sub-categories and courses
** Theme order - new setting ''$CFG->themeorder'' which sets the priority of the themes from highest to lowest.

===Module improvements===

* Quiz/Question improvements:
** Improved question bank, as above.
** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)
** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)
** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)
** Gift Import/Export format can now handle Essay and Description question types.
** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.
** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.

''Developers please add news here!''

===Notes===

* In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].

==Moodle 1.8.2==

Released: 8th July 2007

Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&styleName=Html&projectId=10011 the full list of fixed issues in 1.8.2].

===Highlights===
* Two XSS security vulnerabilities (one reported in the wild) were fixed.

==Moodle 1.8.1==

Released: 14th June 2007

Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&styleName=Html&projectId=10011 the full list of fixed issues in 1.8.1].

===Highlights===
* The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.

==Moodle 1.8==

Released: 31st March 2007

Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&styleName=Html&version=10130 the full list of fixed issues in 1.8].

===Headline features===

* [[Accessibility]] - Moodle.com
:: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.
* [[Moodle Network]] - Catalyst, Richard Wyles
:: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in "Hub" mode where any Moodle install can connect and users roam across.
* [[Web Services API]] - Catalyst, Richard Wyles
:: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.
* [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com
:: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.
* [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com
:: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.
* [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology
::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.
* Groups refactor - OU / Moodle.com
::Groups code has been reorganised to make it more flexible for the future (see 1.9).
* [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10221 Roles improvements] - Moodle.com
:: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the "front page course" and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.
* [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com
::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.

===Known problems===
* CAS auth not working

===Module improvements===
* [[Authorize.net Payment Gateway]] enrolment plugin
:: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.

''Developers please add news here!''

===See also===
*[[Upgrading to Moodle 1.8]]

==Moodle 1.7.2==

30th March, 2007

[http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&styleName=Html&version=10174 This page shows issues resolved in this version]

===Security===

* Unintended logouts are now prevented - sesskey added to logout.php script
* Fixed problem with visible posts in user profile when "forceloginforprofiles" disabled
* Fixed visibility of site blog entries
* Corrected wrong includes in lams
* XSS injection in SCORM 1.2 reports
* Fixed old problem with approvals in Data module, edited entries were approved automatically
* Fixed escaping in shell commands (Win32 platform only)
* Fixed visibility of blog drafts
* Rewritten parameter handling in repository plugin
* Fixed XSS in login block

==Moodle 1.7.1==

17th January, 2007

[http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&styleName=Html&version=10151 This page shows details about issues resolved in this version]

==Moodle 1.7==

7th November, 2006

[http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&styleName=Html&projectId=10011&Create=Create This page shows details about issues resolved in this version]

===Headline features===

* [[Roles]]
:: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people.
* [[Development:XMLDB Documentation|XML Database Schema]]
:: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle
* New Admin interface
:: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy.
* [[Unit tests|Unit testing framework]]
:: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle.
* [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!)
:: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!

===Module improvements===

* Improvements to the [[Assignment module]]
**New type Advanced uploading of files

* Improvements to the [[Database module]]
**Template/Field settings can now be saved as Presets and shared across a site.
**Presets are just zip files, and can also be shared between sites.
**Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come.
**New latitude/longitude data type

* Improvements to the [[Lesson module]]
**Now has a more unified view of lesson screens.
**Teacher editing:
***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages.
***Editing is now speedier by replacing 3 second redirect delays with a notification system.
**New feature: display default feedback.
***Default is '''On''' so previous lessons behave as before.
***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page.
**Graceful degrade of JavaScript.
**Several bug fixes.

* Improvements to the [[Quiz module]]
:* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score.

* Improvements to some core question types
:* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers.
:* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer.
:* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions.
:* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.)

* Improvements to the [[Wiki module]]
:* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock.
:* Minor bugfixes (mostly to fix problems that occured when using Postgres database).

===Enrolment plugin improvements===

* [[Authorize.net Payment Gateway]] enrolment plugin
:*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page.
:*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.

== See also ==
*[[Old releases|Old release notes]]

[[es:Notas de versiones]]
[[fr:Notes de mise à jour]]
[[pt:Versões do Moodle]]
[[ru:Примечания к версиям]]

Development:Grades

2007-08-17T06:02:27Z

Lazyfish: /* Default participant interface */

[http://moodle.org/mod/forum/discuss.php?d=69223 There is an ongoing discussion about this spec here]

== Executive Summary ==

The gradebook mechanisms must be rebuilt to:

# '''Improve performance and scalability''' - All grades from throughout the system will be pushed to a central system of tables. This means reports based on grades can be generated much faster, and the gradebook has ultimate control over the content.
# '''Improve flexibility''' - All aspects of the new gradebook will use simple plugin structures, namely: exports, imports and displays/reports. It is expected that the community will be very active in producing [[Development:Gradebook Report Tutorial |special-purpose reports]] analysing the basic grade data in new ways, for example, or writing plugins to transfer grades to student information systems.
# '''Allow rubrics for outcomes (aka standards,competencies,goals)''' - As well as numerical grades, each grading item can consist of a number of scores made on a rubric against a standard outcome statement. These can be automatically converted to a numerical grade if desired or just shown as is.
# '''Implement an event-oriented architecture''' - Such an architecture allows all parts of Moodle to interact with the gradebook, but particularly gradebook plugins can react instantly to grading events throughout the system.
# '''Allow arbitrary columns and derived columns''' - Arbitrary columns of data can be added (either manually or via import). Columns can also be automatically filled based on formulas.

== Glossary ==

Here are some terms used in the gradebook, both in the development and the user interface. Using these terms in discussions about the gradebook will help to reduce confusion.

{| border="1" cellpadding="2" cellspacing="0"
|'''Term'''
|'''Definition'''
|-
|Activity
|An instance of an activity module [[Category:Modules|Module]] (e.g. a single quiz, assignment etc...)
|-
|Calculation
|A formula used to calculate grades, based (optionally) on other grade items. Not the same as [[Calculated_question_type|Calculated question types]].
|-
|Category
|A set of Grade Items. A Category also has its own aggregated Grade which is calculated from its Grade Items. There is no limit to the level of nesting of Categories (a Category may belong to another Category). However, each Grade Item may belong to only one Category.
|-
|Course completion
|The concept of meeting certain criteria for completing a course. In the context of the gradebook, this means a set of grades that must be reached, or a number of outcomes/competencies to complete/master.
|-
|[[Development:Events|Event]]
|Events are a new feature of Moodle 1.9, of which the [[Development:Grades#Overview_of_module_communication|Gradebook will take full advantage]]. Modules that have grades to publish will define Events for which the Gradebook will listen. When an Event matches an Event Handler set up in the Gradebook, an Event Reaction will be triggered, performing any steps required (such as aggregating multiple grades, storing the grades etc...). Modules can also have their Event Handlers set up to respond to Events sent by the Gradebook (such as updating their internal grades).
|-
|Grade
|A Grade is a single assessment. It may be a number or an item on a scale (possibly tied to an Outcome).
|-
|[[Gradebook|Gradebook]]
|A central location in Moodle where students' Grades are stored and displayed. Teachers can keep track of their students' progress and organise which set of Grades their students will be able to see. Students see their own Grades.
|-
|Grade Item
|A "column" of Grades. It can be created from a specific Activity or other module, calculated from other Grade Items, or entered manually.
|-
|[[Development:Grades#Locked_grades|Grade Locks]]
|See linked section of this page
|-
|History
|The gradebook has its own type of log, which keeps a History of all changes made to grades.
|-
|[[Development:Outcomes|Outcome]]
|[[Development:Outcomes|Outcomes]] are specific descriptions of what a person is expected to be able to do or understand at the completion of an activity or course. An activity might have more than one outcome, and each may have a grade against it (usually on a scale). Other terms for Outcomes are ''Competencies'' and ''Goals''. See some [[Development:Outcomes_examples|Examples]].
|-
|[[Scales|Scale]]
|A scale is a set of responses from which the teacher can choose one. eg A,B,C,D,E,F
|}

== Database structures ==
=== grade_items ===

This table keeps information about gradeable items (ie columns). If an activity (eg an assignment or quiz) has multiple grade_items associated with it (eg several outcomes or numerical grades), then there will be a corresponding multiple number of rows in this table.

idnumber is a unique tag identifying the grade_item, useful for identifying data in exports and for referring to the grade_item in calculations. Usually it will be the same as the idnumber in course_modules but if one is not specified then it's automatically set as itemmodule.iteminstance-itemnumber (eg forum3).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|

|autoincrementing
|-
|'''courseid'''
|int(10)
|

|The course this item is part of
|-
|'''categoryid'''
|int(10)
|<center>NULL</center>
|(optional) the category group this item belongs to
|-
|itemname
|varchar(255)
|<center>NULL</center>

|The name of this item (pushed in by the module)
|-
|itemtype
|varchar(30)
|

|'mod', 'blocks', 'import', 'calculated', 'category' etc
|-
|itemmodule
|varchar(30)
|<center>NULL</center>

|'forum', 'quiz', 'csv', etc
|-
|iteminstance
|int(10)
|<center>NULL</center>

|id of the item module
|-
|itemnumber
|int(10)
|<center>NULL</center>
|Can be used to distinguish multiple grades for an activity
|-
|iteminfo
|text
|<center>NULL</center>

|Info and notes about this item XXX
|-
|idnumber
|varchar(255)
|<center>NULL</center>
|Arbitrary idnumber provided by the module responsible (must be defined and unique)
|-
|calculation
|text
|<center>NULL</center>
|Spreadsheet-type formula used to process the raw grades into final grades
|-
|gradetype
|int(4)
|<center>1</center>
|0 = none, 1 = value, 2 = scale, 3 = text
|-
|grademax
|float(10,5)
|<center>100</center>
|What is the maximum allowable grade?
|-
|grademin
|float(10,5)
|<center>0</center>
|What is the minimum allowable grade?
|-
|'''scaleid'''
|int(10)
|<center>NULL</center>
|If this grade is based on a scale, which one is it?
|-
|'''outcomeid'''
|int(10)
|<center>NULL</center>
|If this grade is related to an outcome, which one is it?
|-
|gradepass
|float(10,5)
|<center>0</center>
|What grade is needed to pass? grademin <= gradepass <= grademax
|-
|multfactor
|float(10,5)
|<center>1.0</center>
|Multiply all grades by this
|-
|plusfactor
|float(10,5)
|<center>0.0</center>
|Add this to all grades
|-
|aggregationcoef
|float(10,5)
|<center>0.0</center>
|Weight applied to all grades in this grade item during aggregation with other grade items.
|-
|sortorder
|int(10)
|<center>0</center>
|Sorting order of the columns
|-
|hidden
|int(10)
|<center>0</center>
|1 is hidden, 1 is hide always, > 1 is a date to hide until (prevents viewing of all user grades)
|-
|locked
|int(10)
|<center>0</center>
|0 is not locked, > 0 is a date when was item locked (no final grade or grade_item updates possible)
|-
|locktime
|int(10)
|<center>0</center>
|0 no auto locking, > 0 is a date to lock grade item and final grades after automatically
|-
|deleted
|int(10)
|<center>0</center>
|1 means the associated module instance has been deleted
|-
|needsupdate
|int(10)
|<center>0</center>
|If this flag is set, then the whole column will be recalculated

|-
|timecreated
|int(10)
|
|The first time this grade_item was created

|-
|timemodified
|int(10)
|
|The last time this grade_item was modified
|}

=== grade_categories ===

This table keeps information about categories, used for grouping items. An associated grade_item will be maintained for each category to store the aggregate data.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''courseid'''
|int(10)
|
|The course this grade category is part of
|-
|'''parent'''
|int(10)
|<center>NULL</center>
|Parent grade_category (hierarchical)
|-
|depth
|int(10)
|<center>0</center>
|How deep is this category from the highest level (0,1,2)? Used for table display purposes.
|-
|path
|varchar(255)
|
|Shows the path as /1/2/3 (like course_categories)
|-
|fullname
|varchar(255)
|
|The name of this grade category
|-
|aggregation
|int(10)
|<center>0</center>
|A constant pointing to one of the predefined aggregation strategies (none, mean,median,sum, etc)
|-
|keephigh
|int(10)
|<center>0</center>
|Keep only the X highest items
|-
|droplow
|int(10)
|<center>0</center>
|Drop the X lowest items
|-
|timecreated
|int(10)
|
|The first time this grade_category was created
|-
|timemodified
|int(10)
|
|The last time this grade_category was modified
|}

=== grade_grades ===

This table keeps individual grades for each user and each item. The raw grade is exactly as imported or submitted by modules. The rawgrademax/min and rawscaleid are stored here to record the values at the time the grade was stored, because teachers might change this for an activity! All the results are normalised/resampled/calculated for the finalgrade, which is relative to the max/min/scaleid values stored in the grade_item. The finalgrade field is effectively a cache and values are rebuilt whenever raw values or the grade_item changes.

Note that the finalgrade for a scale-based item may be non-integer! It needs to be rounded on display.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''itemid'''
|int(10)
|
|The item this grade belongs to
|-
|'''userid'''
|int(10)
|
|The user who this grade is for
|-
|rawgrade
|float(11,10)
|<center>NULL</center>
|The raw grade that came into the system
|-
|rawgrademax
|float(11,10)
|<center>100</center>
|The maximum allowable grade when this was created
|-
|rawgrademin
|float(11,10)
|<center>0</center>
|The minimum allowable grade when this was created
|-
|'''rawscaleid'''
|int(10)
|<center>NULL</center>
|If this grade is based on a scale, which one was it?
|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified the raw grade value
|-
|finalgrade
|float(11,10)
|<center>NULL</center>
|The final grade (cached) after all calculations are made
|-
|hidden
|int(10)
|<center>0</center>
|0 is not hidden, 1 is hide always, > 1 is a date to hide until
|-
|locked
|int(10)
|<center>0</center>
|0 is not locked, > 0 when was the grade locked
|-
|locktime
|int(10)
|<center>0</center>
|0 is never, > 0 is a date to lock the final grade after automatically
|-
|exported
|int(10)
|<center>0</center>
|0 is not exported, > 0 is the last exported date
|-
|timecreated
|int(10)
|
|the time this grade was first created
|-
|timemodified
|int(10)
|
|the time this grade was last modified
|}

=== grade_grades_text ===

This table keeps additional textual information about each individual grade, whether it be automatically generated from the module or entered manually by the teacher. It's here separate from the all-numeric grade_grades for database efficiency reasons.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|

|autoincrementing
|-
|'''gradesid'''
|int(10)
|

|The exact grade in grade_grades this corresponds to
|-
|information
|text
|<center>NULL</center>
|Further information like forum rating distribution 4/5/7/0/1
|-
|informationformat
|int(10)
|<center>0</center>
|Text format for information
|-
|feedback
|text
|<center>NULL</center>
|Manual feedback from the teacher. Could be a code like 'mi'.
|-
|feedbackformat
|int(10)
|<center>0</center>
|Text format for feedback
|-
|timecreated
|int(10)
|

|the time these entry was first created
|-
|timemodified
|int(10)
|

|the time this entry was last updated
|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified this entry
|}

=== grade_outcomes ===

This table describes the outcomes used in the system. An outcome is a statement tied to a rubric scale from low to high, such as “Not met, Borderline, Met” (stored as 0,1 or 2). For more info about these see [[Development:Outcomes]].

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''courseid'''
|int(10)
|<center>NULL</center>
|Mostly these are defined site wide ie NULL

|-
|shortname
|varchar(255)
|
|The short name or code for this outcome statement

|-
|fullname
|text
|
|The full description of the outcome (usually 1 sentence)

|-
|'''scaleid'''
|int(10)
|
|The recommended scale for this outcome.

|-
|timecreated
|int(10)
|
|the time this outcome was first created

|-
|timemodified
|int(10)
|
|the time this outcome was last updated

|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified this outcome
|}

=== grade_outcomes_courses ===
An intersection table used to make standard outcomes available to courses.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''courseid'''
|int(10)
|
|The id of the course being assigned the outcome

|-
|'''outcomeid'''
|int(10)
|
|The id of the outcome being assigned to the course
|}

=== grade_import_newitem ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|itemname
|varchar(255)
|
|*TODO* Document

|-
|importcode
|int(12)
|
|*TODO* Document
|}

=== grade_import_values ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''itemid'''
|int(10)
|NULL
|*TODO* Document

|-
|newgradeitem
|int(10)
|NULL
|*TODO* Document

|-
|'''userid'''
|int(10)
|
|*TODO* Document

|-
|finalgrade
|float(10,5)
|0
|*TODO* Document

|-
|feedback
|text
|NULL
|*TODO* Document

|-
|importcode
|int(12)
|
|*TODO* Document
|}

=== History tables ===

These table keep track of changes to most of the grade tables. Using these it should be possible to reconstruct the grades at any point in time in the past, or to audit grade changes over time. It should be quicker to use these tables for that, rather than storing this information in the main Moodle log. The following tables are set up for that purpose:

#grade_categories_history
#grade_grades_history
#grade_items_history
#grade_outcomes_history

Each of them has exactly the same DB structure as their matching table (e.g. grade_categories), with 3 extra fields:

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|action
|int(10)
|0
|The action that lead to the change being recorded (insert, update, delete)

|-
|'''oldid'''
|int(10)
|
|The id of the record being changed or inserted (PK of the main table, not the history table)

|-
|source
|varchar(255)
|NULL
|The URL from which the action originated
|}

== Overview of module communication ==

Modules will often store internal copies of grades for calculations or for showing grades to students etc, but these are ''purely'' internal. The gradebook system will never access these directly.

A new feature in Moodle 1.9 is a simple [[Development:Events|event handler]]. The new gradebook will be the first feature in Moodle to take advantage of events, and all communication between the gradebook and the modules will take place via event messages. See [[Development:Events]] for full details.

There are two ways that data are transferred between the module and the gradebook:

;'''1. Modules post grade events''' : Whenever a new grade is created, the module should post a ''grade_updated'' event so that the gradebook can pick it up. As long as that column in the gradebook is not “locked” then the new grades will be entered (overwriting any existing ones).
;'''2. Gradebook posts grade events''' :Whenever a grade is altered in the gradebook (for example, a teacher may want to change an assignment grade), then a ''grade_updated_external'' event is posted so that the module can pick it up. If the module implements this “reverse” function then the internal grade in the module can be changed.

=== Backward compatibility with Moodle 1.8 and earlier ===

:For backward compatibility with old third-party modules, we will add a new function called grade_grab_legacy_grades() to admin/cron.php to search all mod/xxx/lib.php files for functions named xxx_grades().

:These legacy functions will be called to extract all the grades for all the activities in each course. Once the data is extracted, the ''grade_updated'' event is triggered as usual and copy/upgrade the data in the gradebook tables.

:A similar function will be added to upgraded modules to trigger a “mass copy” of all the existing grades into the new gradebook. This will be useful during the upgrade from 1.8 as well as being available in the normal gradebook interface to “refresh” a column from primary data.

== Core API functions ==

Even though most of the communication will take place via events, there are a few core functions in lib/gradelib.php that will be useful for modules:

===grade_is_locked()===

eg grade_is_locked($courseid, $itemtype, $itemmodule, $iteminstance, $itemnumber, $userid=NULL)

This function will tell a module whether a grade (or grade_item if $userid is not given) is currently locked or not. If it's locked to the current user then the module can print a nice message or prevent editing in the module. If no $userid is given, the method will always return the grade_item's locked state. If a $userid is given, the method will first check the grade_item's locked state (the column). If it is locked, the method will return true no matter the locked state of the specific grade being checked. If unlocked, it will return the locked state of the specific grade.
([http://moodle.org/mod/forum/discuss.php?d=69223#p311329 info])

===grade_regrade_final_grades()===

grade_regrade_final_grades($courseid=NULL, $userid=NULL, $updated_item=NULL)

Updates all grade_grades->finalgrade records for each grade_item matching the given attributes. The search is further restricted, so that only grade_items that have needs_update == true or that use calculation are retrieved and used for the update. The function returns the number of grade_items updated (NOT the same as the number of grades_grades updated!).

===grade_update()===

grade_update($source, $courseid, $itemtype, $itemmodule, $iteminstance, $itemnumber, $grades=NULL, $itemdetails=NULL)

Submit new or update grade; update/create grade_item definition. Grade must have userid specified, rawgrade and feedback with format are optional. rawgrade NULL means 'Not graded', missing property or key means do not change existing. Only following grade item properties can be changed 'itemname', 'idnumber', 'gradetype', 'grademax', 'grademin', 'scaleid', 'multfactor', 'plusfactor', 'deleted'.

===grade_verify_idnumber()===

grade_verify_idnumber($idnumber, $grade_item = null, $cm = null, $gradeitem)

Verify new value of idnumber - checks for uniqueness of new idnubmers, old are kept intact.

===remove_course_grades()===

remove_course_grades($courseid, $showfeedback)

Remove all grade related course data - history is kept

===grade_get_outcomes()===

grade_get_outcomes($courseid, $itemtype, $itemmodule, $iteminstance,$userid=0)

Returns list of outcomes used in course together with current outcomes for this user.

===build_percentages_array()===

build_percentages_array($steps = 1, $order = 'desc', $lowest = 0, $highest = 100)

Builds an array of percentages indexed by integers for the purpose of building a select drop-down element.

== Dealing with multiple grades ==

Modules will often produce several grade items. This may be several attempts, say, like the quiz module, or more commonly, ratings based on several outcomes. It is '''up to the module''' whether these grades are aggregated BEFORE sending to the gradebook as a single number, or are sent in raw form to the gradebook.

Pre-aggregration makes the most sense for a quiz, say, which already implements algorithms to calculate a single number for each student. In such a case there will only be one grade item from a particular quiz.

For anything that uses outcomes with grades against multiple rubrics (such as an assignment), it would make the most sense to just pass all the results through to the gradebook as individual grade items.

If the gradebook receives multiple grade items from a module, then they are automatically grouped together in a unique grade category (with the same name as the module instance). This is simply done by checking/creating the category whenever a second item from the same instance is being added. All the grading items will by default appear separate in the gradebook GUI, but can be easily “combined” by choosing an aggregation algorithm from a list (such as “Sum, Mean, Median, etc ...), plus “Keep X high, Drop X Low” together with scaling/shifting via the Multiplication and Plus factors etc.

For more info about multiple grade items see [[Development:Outcomes]].

== Calculated grade items ==

A calculated grade item can operate on any arbitrary other items. It is not connected to any particular module.

The final calculated values are re-calculated and stored in the grade_grades table whenever any of the values in the source items is changed. To avoid doing this for every grade_post event, we just set the ''needsupdate'' field on grade_items every time grades are added or changed.

At the next display time or export time (ie whenever grades_grades->finalgrade is accessed) we do this:

If any current grade_items are flagged as ''needsupdate'' then
# for each grade_item with the flag, update all grade_grades->final for them and remove the grade_item flag
# for each grade_item with a calculation, update their grade_grades->finalgrade

The format for the calculations may as well use the same format as Excel and Openoffice, as that is what most people are probably used to.

eg: MEAN(quizstart1, quizend1) + assignment1 + 20.0

== Adjustment of grades ==
Grade_item contains optional rules for adjusting the raw grade before it is cached into a final grade. These rules are processed BEFORE the calculation discussed above, because they may include reprocessing the grade's place within a different scale or grade range.

=== Adjustment to a new range ===
A raw grade may have been initially calculated within a module inside a range of 0 to 100 (grademin - grademax). However, the grade_item may be given a different grademin and grademax. For example, it could be 30 to 70. If you take a raw value of 30 on the original range (i.e. 30%), after adjusting this score for the new range, you should obtain 42, not 30 (30 being the equivalent of 0 on the previous range). This calculation takes place before the multfactor and plusfactor are applied, and before the calculation formula is applied.

=== Adjustment to a new scale ===
A raw grade may also have a scale value, which always starts at 0 (for the first item in the scale), and has a maximum set by the number of items in the scale. Because this value is always an integer, the above calculation is performed in addition to a rounding up to the nearest integer. Also, multfactor and plusfactor are both ignored, because using them makes no sense in the context of a scale value.

== Displaying the grades to ordinary participants ==

The module takes responsibility for displaying grades within the module (to a student, say). Normally they would use internal tables to do so. However, there is a grade_get_grades() function available for modules to query the core gradebook for grades (if required).

For full display of grades in a whole course say, the student uses the same link as teachers use to access the gradebook. However, due to their different permissions they will only have access to specific reports. By default this is the “singleuser” report which only shows their own grades and has very few configuration options.

== Locked grades ==

Both whole columns and individual grades can be locked in the gradebook, via the "locked" field. Teachers may want to do this to prevent further changes from the modules, or from other teachers. When a grade is locked, any grading events that might affect that grade are ignored. When the graded is unlocked, an "unlock" event is triggered, which allows a module to handle it by sending the latest new grades back.

In the main GUIs the lock toggling will be achieved by clicking on a little padlock icon beside each entry or column.

== Manually modified grades ==

Grades can be manually modified (overriden) in the gradebook. When this is done to grade_items derived from a module's grades, and the new value is different from the original one, then the field will automatically be given a locked status (it can of course be unlocked immediately if one wishes). This is to prevent new grading events from changing the manually entered values unexpectedly.

== Clean up after old activities ==

By default columns (grade items) will remain in the gradebook even when activities are deleted. A manual 'clean-up' button can delete old columns if required.

When you click the 'Clean up' button, it shows you a list of columns that should be deleted, with a checkbox next to each one (on by default, but you can turn it off if you want to keep that column still) and then another button click to really delete the marked columns.

Otherwise there will be a site option to do this automatically whenever activities are deleted.

== Logging ==

As well as datestamps and userids in the tables, all grading events will be logged in case an audit needs to be made.

== Security Issues ==

For security an option to force SSL for the gradebook might be good.

==Overall grade==

Having an overall grade handy allows us to know exactly when a course is "finished". Exactly how do we specify the "overall" grade? It's a special case, and might not always be just the sum.

The best solution is probably to have a special calculated column (grade_item) for every course that can not be deleted. It's made special because the itemtype is 'total' (one per course). The calculation formula should be updated automatically whenever grade_items are changed in that course to be the "sum" of all the grade_items in the course.

However, if the calculation is edited manually then we should lock the calculation formula. We could do this by setting the iteminfo field to something. Clearing the calculation to an empty string could force it back to an automatic calculation formula.

== Report plugins ==
All the main interface of the gradebook will be implemented as report plugins. Each plugin is fully responsible for defining the interface between the header and footer. They can even define their own capabilities and extra tables if the core tables are not enough, as they'll have a full /grade/report/xxxx/db directory.

Each report will need to define one capability to allow people to see that report, so that admins have control over who can see what reports. For example, the participant interface can be a totally separate report plugin.

This allows for the widest flexibility and safety in how grades are presented.

=== Default teacher interface ===
This interface will be what teachers see by default, and will subsume everything the current interface (in Moodle 1.8) does.

Some snippets of functionality:
{{Moodle 1.9}}
Overall it's a grid, with participant names down one side and grade items along the top.

Columns will be able to be collapsed together by grouping them into categories. Grades for categories can be calculated via various means.

“Eye-cons” on the columns and checkboxes by every grade (this bit possibly controlled with a switch) allow hiding by category, by column, by individual grade.

Textual notes can be added to each grade for more info. These show up to participants as well.

A groups menu allows the teacher to switch between showing EACH of the groups they have access to, or ALL the groups they have access to.

All grade items will link to modulepath/grade.php?id=44 which will work out what the current person should be allowed to see and either redirect them to the correct page or just show them immediately. This copes with situations like the quiz, say, where we want editing teachers to go to the detailed reports there while participants just see their own grade or whatever the quiz is set to show.

User preference to SWITCH between showing raw grades, percentage grades, or both, or grade letters (A/B/C etc).

Settings for grade letters not only define the transformation from percentage to grades, but also the transformation from letters to grades (in case the teacher edits some of the letter grades).

Categories are shown above the headings for each column. Clicking for more info on a category will just show the category with a summary column showing total/average for just that category (PLUS the summary column for the whole course).

All columns should be sortable up/down.

At the bottom of each column is a row with the mean course score. If in groups mode, then add ANOTHER row with just the group mean. Add the number of grades used in brackets. eg 56% (11). When the report is paged, these means are still for the whole course/group (not the page!)

{{Moodle 2.0}}

Teachers can type “straight into” the grid using AJAX or fallback to forms. No popup menus for values.

Later on we can support customisable shorthand codes to make data entry quick (eg type 'ab' for absent, or 'nge' for not good enough).

See [http://test.moodle.com/grade/report/grader/index.php?id=2 the test site] for a live demo of this report.

=== Default participant interface ===
This interface will be what participants see by default:

Some snippets of functionality:

*Invert the grid to show one item per row, with the total/average at the bottom.
*Use second/third columns to show categories.
*Include ranking score in another column.
*Show feedback
*Show percentage
*No editing functionality.

See [http://test.moodle.com/grade/report/user/index.php?id=2 the test site] for a live demo of this report.

=== Outcomes report ===
This simple informational report displays all the outcomes used by the course, with the following information:

*Outcome name
*Overall average: If the outcome is used by more than one activity, this shows you the mean across all these activities in the current course
*Site-wide: Yes or No: A site-wide outcome is automatically made available to all courses.
*Activities: A list of links to the activities in the current course that use each outcome. One row per activity (table splits here)
*Average: For each activity using the outcome, the average score is shown.
*Number of grades: For each activity using the outcome, the number of grades is shown (non-graded participants are ignored)

See [http://test.moodle.com/grade/report/outcomes/index.php?id=2 the test site] for a live demo of this report.

=== Overview report ===
Another basic report, showing a participant's course averages in each of the courses in which s/he has received grades.

See [http://test.moodle.com/grade/report/overview/index.php the test site] for a live demo of this report.

== Export plugins ==

The API for these is extremely simple. Each export plugin should occupy a directory under /grade/export/xyz and needs to provide only an index.php file as a the primary interface. This file can accept parameters that produce a subset of the grades:

* courseid
* groupid
* categoryid
* itemid
* userid

The index.php can choose to simply dump something (eg an Excel spreadsheet) and return, or it can show an interface for further options and selections. Ideally even if it dumps something it should also show some feedback about what was exported to make it easier to double check what was sent, but this is up to the plugin to implement.

Further if the plugin contains a lib.php and an xyz_visible() function then the gradebook can check this function to make sure the current user can see/use the plugin (eg by checking access permissions). If this function returns false then the export method won't appear in the main gradebook interfaces.

The export plugins are a "full" Moodle plugin, so it can have tables, cron functions, event handlers, capabilities etc. For example, an export plugin might not even have a GUI (ie xyz_visible() is always false and/or index.php doesn't exist) - it might operate solely off cron or event triggers.

== Import plugins ==

Each import plugin should occupy a directory under /grade/import/xyz and needs to provide only an index.php file as a the primary interface. This file just accepts a 'courseid' parameter.

The index.php will show an interface for further options and selections.

Further if the plugin contains a lib.php and an xyz_visible() function then the gradebook can check this function to make sure the current user can see/use the plugin. If this function returns false then the import method won't appear in the main gradebook interfaces.

The import plugins are a "full" Moodle plugin, so it can have tables, cron functions, event handlers, capabilities etc. For example, an import plugin might not even have a GUI (ie xyz_visible() is always false and/or index.php doesn't exist) - it might operate solely off cron or event triggers.

The entire import must be treated as one operation. If it fails, then no records should be imported and the database is unchanged.

Some sample import plugins are:

===Import from CSV===

Accepts an upload of (or URL to) a CSV file. Multiple options describe how to process the file, which columns to add etc. These should be sticky, and retained via user preferences to make future imports easier.

===Import from XML===

Accepts an upload of (or URL to) an XML file with this kind of format (from OU).

<results batch="[someuniqueimportnumber]">
<result>
<state>['new' or 'regrade']</state>
<assignment>[idnumber]</assignmentid>
<student>[studentid]</student>
<score>[score]</score>
</result>
<result>
<state>['new' or 'regrade']</state>
<assignment>[idnumber]</assignmentid>
<student>[studentid]</student>
<score>[score]</score>
</result>
[...]
</results>

== Capabilities and Permissions ==

* moodle/grade:view - view your own grades

* moodle/grade:viewall - view grades of other users

* moodle/grade:viewhidden - see grades that are marked as hidden for the owner

* moodle/grade:hide - be able to hide/unhide cells, items or categories

* moodle/grade:lock - be able to lock cells, items or categories

* moodle/grade:unlock - be able to unlock cells, items or categories

* moodle/grade:manage - manage grade items and categories in gradebook (create, edit, lock, hide, delete, etc.)

* moodle/grade:import - import grades

* moodle/grade:export - export grades

* moodle/grade:override - edit or override individual grades

* gradereport/grader:view - can view the grader report

* gradeimport/csv:view - can view/use the csv import plugin

* gradeexport/csv:view - can view/use the csv export plugin

* moodle:site/accessallgroups

== Interface Demo ==

The mockup is no longer applicable. Instead you can play with the live demo at the following site:

[http://test.moodle.com/grade/report/grader/index.php?id=2 Gradebook live demo]

Please base your future feedback on that interface.

== Development Tasks and Tracking ==

See [http://tracker.moodle.org/browse/MDL-9137 MDL-9137] for the full details.

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69223&mode=3 Gradebook Development ideas] forum discussion
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=51107 New gradebook for Moodle] forum discussion
* [[Development:Events]]
* [[Development:Gradebook Report Tutorial]]

[[Category:Developer|Grades]]
[[Category:Grades]]

Capabilities/mod/forum:initialsubscriptions

2007-08-15T05:54:19Z

Lazyfish:

*This allows a user to be subscribed initially to forums
*This capability is allowed for default teacher, non-editing teacher and student roles
*This capability is not set for default admin and course creator roles so they don't receive unwanted forum subscription emails. If this is set for any role that is used at system level (e.g. admin, course creators), assigning users to these roles will take a long time because users will be subscribed in forums in all courses.

[[Category:Capabilities|Forum]]
[[Category:Forum]]

Capabilities/moodle/role:switchroles

2007-07-27T06:01:15Z

Lazyfish:

*This allows a user to switch temporarily to another role so that they can see what the course would look like to someone with that role (much like the "student view" functionality in Moodle 1.6).
*The roles available in the "Switch role to..." drop-down menu are the same as the roles that a user is [[Allow role assignments|allowed to assign]] to other users.
*A user can only switch to roles he/she can assign. That means he/she needs moodle/role:assign at the course context as well the correct settings in the "Allow role assignments" setting.
[[Category:Capabilities|Role]]
[[Category:Roles]]

[[fr:Capacités/moodle/role:switchroles]]
[[ja:ケイパビリティ/moodle/role:switchroles]]

Development:Grades

2007-04-27T06:58:32Z

Lazyfish: /* grade_items */

>>Still under construction<<

[http://moodle.org/mod/forum/discuss.php?d=69223 There is an ongoing discussion about this spec here]

== Executive Summary ==

The gradebook mechanisms must be rebuilt to:

# '''Improve performance and scalability''' - All grades from throughout the system will be pushed to a central system of tables. This means reports based on grades can be generated much faster, and the gradebook has ultimate control over the content.
# '''Improve flexibility''' - All aspects of the new gradebook will use simple plugin structures, namely: exports, imports and displays/reports. It is expected that the community will be very active in producing special-purpose reports analysing the basic grade data in new ways, for example, or writing plugins to transfer grades to student information systems.
# '''Allow rubrics for outcomes (aka standards,competencies,goals)''' - As well as numerical grades, each grading item can consist of a number of scores made on a rubric against a standard outcome statement. These can be automatically converted to a numerical grade if desired or just shown as is.
# '''Implement an event-oriented architecture''' - Such an architecture allows all parts of Moodle to interact with the gradebook, but particularly gradebook plugins can react instantly to grading events throughout the system.
# '''Allow arbitrary columns and derived columns''' - Arbitrary columns of data can be added (either manually or via import). Columns can also be automatically filled based on formulas.

== Glossary ==

Here are some terms used in the gradebook, both in the development and the user interface. Using these terms in discussions about the gradebook will help to reduce confusion.

{| border="1" cellpadding="2" cellspacing="0"
|'''Term'''
|'''Definition'''
|-
|Activity
|An instance of an activity module [[Category:Modules|Module]] (e.g. a single quiz, assignment etc...)
|-
|Calculation
|A formula used to calculate grades, based (optionally) on other grade items. Not the same as [[Calculated_question_type|Calculated question types]].
|-
|Category
|A set of Grade Items. A Category also has its own aggregated Grade which is calculated from its Grade Items. There is no limit to the level of nesting of Categories (a Category may belong to another Category). However, each Grade Item may belong to only one Category.
|-
|Course completion
|The concept
|-
|[[Development:Events|Event]]
|Events are a new feature of Moodle 1.9, of which the [[Development:Grades#Overview_of_module_communication|Gradebook will take full advantage]]. Modules that have grades to publish will define Events for which the Gradebook will listen. When an Event matches an Event Handler set up in the Gradebook, an Event Reaction will be triggered, performing any steps required (such as aggregating multiple grades, storing the grades etc...). Modules can also have their Event Handlers set up to respond to Events sent by the Gradebook (such as updating their internal grades).
|-
|Grade
|A Grade is a single assessment. It may be a number or an item on a scale (possibly tied to an Outcome).
|-
|[[Gradebook|Gradebook]]
|A central location in Moodle where students' Grades are stored and displayed. Teachers can keep track of their students' progress and organise which set of Grades their students will be able to see. Students see their own Grades.
|-
|Grade Item
|A "column" of Grades. It can be created from a specific Activity or other module, calculated from other Grade Items, or entered manually.
|-
|[[Development:Grades#Locked_grades|Grade Locks]]
|See linked section of this page
|-
|History
|The gradebook has its own type of log, which keeps a History of all changes made to grades.
|-
|[[Development:Outcomes|Outcome]]
|[[Development:Outcomes|Outcomes]] are specific descriptions of what a person is expected to be able to do or understand at the completion of an activity or course. An activity might have more than one outcome, and each may have a grade against it (usually on a scale). Other terms for Outcomes are ''Competencies'' and ''Goals''. See some [[Development:Outcomes_examples|Examples]].
|-
|[[Scales|Scale]]
|A scale is a set of responses from which the teacher can choose one. eg A,B,C,D,E,F
|}

== Database structures ==
=== grade_items ===

This table keeps information about gradeable items (ie columns). If an activity (eg an assignment or quiz) has multiple grade_items associated with it (eg several outcomes or numerical grades), then there will be a corresponding multiple number of rows in this table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|

|autoincrementing
|-
|'''courseid'''
|int(10)
|

|The course this item is part of
|-
|'''categoryid'''
|int(10)
|<center>NULL</center>
|(optional) the category group this item belongs to
|-
|itemname
|varchar(255)
|

|The name of this item (pushed in by the module)
|-
|itemtype
|varchar(30)
|

|'mod', 'blocks', 'import', 'calculated', 'category' etc
|-
|itemmodule
|varchar(30)
|

|'forum', 'quiz', 'csv', etc
|-
|iteminstance
|int(10)
|

|id of the item module
|-
|itemnumber
|int(10)
|<center>NULL</center>
|Can be used to distinguish multiple grades for an activity
|-
|iteminfo
|text
|

|Info and notes about this item XXX
|-
|idnumber
|varchar(255)
|<center>NULL</center>
|Arbitrary idnumber provided by the module responsible
|-
|gradetype
|int(4)
|<center>0</center>
|0 = value, 1 = scale, 2 = text
|-
|grademax
|float(11,10)
|<center>100</center>
|What is the maximum allowable grade?
|-
|grademin
|float(11,10)
|<center>0</center>
|What is the minimum allowable grade?
|-
|'''scaleid'''
|int(10)
|<center>NULL</center>
|If this grade is based on a scale, which one is it?
|-
|'''outcomeid'''
|int(10)
|<center>NULL</center>
|If this grade is related to an outcome, which one is it?
|-
|gradepass
|float(11,10)
|<center>0</center>
|What grade is needed to pass? grademin <= gradepass <= grademax
|-
|multfactor
|float(11,10)
|<center>1.0</center>
|Multiply all grades by this
|-
|plusfactor
|float(11,10)
|<center>0.0</center>
|Add this to all grades
|-
|sortorder
|int(10)
|<center>0</center>
|Sorting order of the columns
|-
|hidden
|int(10)
|<center>0</center>
|1 is hidden, > 1 is a date to hide until (prevents viewing)
|-
|locked
|int(10)
|<center>0</center>
|1 is locked, > 1 is a date to lock after (prevents update)

|-
|needsupdate
|int(10)
|<center>0</center>
|If this flag is set, then the whole column will be recalculated

|-
|timecreated
|int(10)
|
|The first time this grade_item was created

|-
|timemodified
|int(10)
|
|The last time this grade_item was modified
|}

=== grade_categories ===

This table keeps information about categories, used for grouping items. An associated grade_item will be maintained for each category to store the aggregate data.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''courseid'''
|int(10)
|
|The course this grade category is part of
|-
|'''parent'''
|int(10)
|<center>NULL</center>
|Parent grade_category (hierarchical)
|-
|depth
|int(10)
|<center>0</center>
|How many parents does this category have?
|-
|path
|varchar(255)
|
|Shows the path as /1/2/3 (like course_categories)
|-
|fullname
|varchar(255)
|
|The name of this grade category
|-
|aggregation
|int(10)
|<center>0</center>
|A constant pointing to one of the predefined aggregation strategies (none, mean,median,sum, etc)
|-
|keephigh
|int(10)
|<center>0</center>
|Keep only the X highest items
|-
|droplow
|int(10)
|<center>0</center>
|Drop the X lowest items
|-
|hidden
|int(10)
|<center>0</center>
|1 is hidden, > 1 is a date to hide until
|-
|timecreated
|int(10)
|
|The first time this grade_category was created
|-
|timemodified
|int(10)
|
|The last time this grade_category was modified
|}

=== grade_calculations ===

This table describes the calculated grade_items in more details.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''itemid'''
|int(10)
|
|The grade_item this relates to
|-
|calculation
|text
|<center>NULL</center>
|Formula describing how to derive this grade from other items, referring to them using [idnumber] ... eg something like:sin(square([XXXXX])) + [YYYY]
|-
|timecreated
|int(10)
|
|the time this calculation was first created
|-
|timemodified
|int(10)
|
|the time this calculation was last modified
|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified this calculation

|}

=== grade_grades_raw ===

This table keeps individual grades for each user and each item, exactly as imported or submitted by modules. The grademax/min and scaleid are stored here to record the values at the time the grade was stored, because teachers might change this for an activity! All the results are normalised/resampled for the grade_grades_final table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''itemid'''
|int(10)
|
|The item this grade belongs to
|-
|'''userid'''
|int(10)
|
|The user who this grade is for
|-
|gradevalue
|float(11,10)
|<center>NULL</center>
|If the grade is a float value (or has been converted to one)
|-
|gradescale
|int(10)
|<center>NULL</center>
|If the grade is a scale value
|-
|grademax
|float(11,10)
|<center>100</center>
|The maximum allowable grade when this was created
|-
|grademin
|float(11,10)
|<center>0</center>
|The maximum allowable grade when this was created
|-
|'''scaleid'''
|int(10)
|<center>NULL</center>
|If this grade is based on a scale, which one was it?
|-
|timecreated
|int(10)
|
|the time this grade was first created
|-
|timemodified
|int(10)
|
|the time this grade was last modified
|-
|'''usermodified'''
|int(10)
|NULL
|the userid of the person who last modified this grade
|}

=== grade_grades_final ===

This table keeps individual grades for each user and each item/category– they have undergone all scaling and other calculations, and are ready for display. This table is effectively a cache and values are rebuilt whenever source values change. The gradevalue or gradescale values are all normalised to the max/min or scaleid as defined in the grade_item table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|
|autoincrementing
|-
|'''itemid'''
|int(10)
|
|The associated grade_item these grades belong to
|-
|'''userid'''
|int(10)
|
|The user who this grade is for
|-
|hidden
|int(10)
|<center>0</center>
|1 is hidden, > 1 is a date to hide until
|-
|locked
|int(10)
|<center>0</center>
|1 is locked, > 1 is a date to lock after
|-
|exported
|int(10)
|<center>0</center>
|0 is not exported, > 1 is the last exported date
|-
|timecreated
|int(10)
|
|the time this grade was first created
|-
|timemodified
|int(10)
|
|the time this grade was last modified
|-
|'''usermodified'''
|int(10)
|NULL
|the userid of the person who last modified this grade
|}

=== grade_grades_text ===

This table keeps additional textual information about each individual grade, whether it be automatically generated from the module or entered manually by the teacher. It's here separate from the all-numeric grade_grades for database efficiency reasons.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''
|-
|'''id'''
|int(10)
|

|autoincrementing
|-
|'''gradesid'''
|int(10)
|

|The exact grade in grade_grades_raw this corresponds to
|-
|information
|text
|<center>NULL</center>
|Further information like forum rating distribution 4/5/7/0/1
|-
|feedback
|text
|<center>NULL</center>
|Manual feedback from the teacher. Could be a code like 'mi'.
|-
|timecreated
|int(10)
|

|the time these entry was first created
|-
|timemodified
|int(10)
|

|the time this entry was last updated
|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified this entry
|}

=== grade_outcomes ===

This table describes the outcomes used in the system. An outcome is a statement tied to a rubric scale from low to high, such as “Not met, Borderline, Met” (stored as 0,1 or 2)

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''courseid'''
|int(10)
|<center>NULL</center>
|Mostly these are defined site wide ie NULL

|-
|shortname
|varchar(255)
|
|The short name or code for this outcome statement

|-
|fullname
|text
|
|The full description of the outcome (usually 1 sentence)

|-
|'''scaleid'''
|int(10)
|
|The recommended scale for this outcome.

|-
|timecreated
|int(10)
|
|the time this outcome was first created

|-
|timemodified
|int(10)
|
|the time this outcome was last updated

|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|the userid of the person who last modified this outcome
|}

=== grade_history ===

This table keeps track of grade changes. Using this it should be possible to reconstruct the grades at any point in time in the past, or to audit grade changes over time. It should be quicker to use this table for that, rather than storing this information in the main Moodle log.

Note we use itemid and userid as a key rather than grade_grade id, just in case one of the things we want to log here is the deletion of a grade entirely.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''itemid'''
|int(10)
|
|The grade_item the grade is from

|-
|'''userid'''
|int(10)
|
|The user that the grade belongs to

|-
|oldgrade
|float
|NULL
|The original grade before the change

|-
|newgrade
|float
|NULL
|The new grade after the change

|-
|note
|text
|NULL
|An optional note about why this change was made

|-
|howmodified
|varchar(255)
|manual
|What caused the modification? manual/module/import/...

|-
|'''usermodified'''
|int(10)
|<center>NULL</center>
|The user id of the person who made the change

|-
|timemodified
|int(10)
|
|The exact time this change was made
|}

== Overview of module communication ==

Modules will often store internal copies of grades for calculations or for showing grades to students etc, but these are ''purely'' internal. The gradebook system will never access these directly.

A new feature in Moodle 1.9 is a simple [[Development:Events|event handler]]. The new gradebook will be the first feature in Moodle to take advantage of events, and all communication between the gradebook and the modules will take place via event messages. See [[Development:Events]] for full details.

There are two ways that data is transferred between the module and the gradebook:

;'''1. Modules post grade events''' : Whenever a new grade is created, the module should post a grading event so that the gradebook can pick it up. As long as that column in the gradebook is not “locked” then the new grades will be entered (overwriting any existing ones).
;'''2. Gradebook posts grade events''' :Whenever a grade is altered in the gradebook (for example, a teacher may want to change an assignment grade), then an event is posted so that the module can pick it up. If the module implements this “reverse” function then the internal grade in the module can be changed.

=== Backward compatibility with Moodle 1.8 and earlier ===

:For backward compatibility with old third-party modules, we will add a new function called grades_grab_grades() to admin/cron.php to search all mod/xxx/lib.php files for functions named xxx_grades().

:These legacy functions will be called to extract all the grades for all the activities in each course. Once the data is extracted, the moodle_event_post() function can be called to initiate an event as usual and copy/upgrade the data in the gradebook tables.

:A similar function will be added to new modules to trigger a “mass copy” of all the existing grades into the new gradebook. This will be useful during the upgrade from 1.8 as well as being available in the normal gradebook interface to “refresh” a column from primary data.

== Core API functions ==

Even though most of the communication will take place via events, there are a few core functions in lib/gradelib.php that will be useful for modules:

===grade_get_items()===

eg grade_get_items($courseid, $itemname=NULL, $itemtype=NULL, $itemmodule=NULL, $iteminstance=NULL, $itemnumber=NULL, $idnumber=NULL)

For extracting all the information about what grading items are attached to something. For example, an assignment may want to retrieve all the grade_items for itself, and get three outcome scales in return. This will affect the grading interface.

===grade_create_item()===

To create a new grade_item in case it doesn't exist. This function would be called when a module is created or updated, for example, to ensure grade_item entries exist. It's not essential though - if grades are being added later and a matching grade_item doesn't exist yet, the gradebook will create them on the fly.

===grade_create_category()===

eg grade_create_category(fullname, array of items, aggregation, etc ...)
For a given set of items, create a category to group them together (if one doesn't exist yet). Modules may want to do this when they are created. However, the ultimate control is in the gradebook interface itself.

===grade_is_locked()===

eg grade_is_locked($itemtype, $itemmodule, $iteminstance, $userid=NULL)

This function will tell a module whether a grade (or grade_item if $userid is not given) is currently locked or not. This is a combination of the actual settings in the grade tables and a check on moodle/course:editgradeswhenlocked. If it's locked to the current use then the module can print a nice message or prevent editing in the module. ([http://moodle.org/mod/forum/discuss.php?d=69223#p311329 info])

== Dealing with multiple grades ==

Modules will often produce several grade items. This may be several attempts, say, like the quiz module, or more commonly, ratings based on several outcomes. It is '''up to the module''' whether these grades are aggregated BEFORE sending to the gradebook as a single number, or are sent in raw form to the gradebook.

Pre-aggregration makes the most sense for a quiz, say, which already implements algorithms to calculate a single number for each student. In such a case there will only be one grade item from a particular quiz.

For anything that uses outcomes with grades against multiple rubrics (such as an assignment), it would make the most sense to just pass all the results through to the gradebook as individual grade items.

If the gradebook receives multiple grade items from a module, then they are automatically grouped together in a unique grade category (with the same name as the module instance). This is simply done by checking/creating the category whenever a second item from the same instance is being added. All the grading items will by default appear separate in the gradebook GUI, but can be easily “combined” by choosing an aggregation algorithm from a list (such as “Sum, Mean, Median, etc ...), plus “Keep X high, Drop X Low” together with scaling/shifting via the Multiplication and Plus factors etc.

== Calculated grade items ==

A calculated grade item can operate on any arbitrary other items. It is not connected to any particular module.

The calculated values are re-calculated and stored in the grade_grades_final table whenever any of the values in the source items is changed. To avoid doing this for every grade_post event, we just set the “needsupdate” field on the relevant calculated grade item columns, then recalculate those columns at the next display time and reset the flag.

== Displaying the grades to ordinary participants ==

The module takes responsibility for displaying grades within the module (to a student, say). Normally they would use internal tables to do so. However, there is a grade_get_grades() function available for modules to query the core gradebook for grades (if required).

For full display of grades in a whole course say, the student uses the same link as teachers use to access the gradebook. However, due to their different permissions they will only have access to specific reports. By default this is the “singleuser” report which only shows their own grades and has very few configuration options.

== Locked grades ==

Both whole columns and individual grades can be locked in the gradebook, via the "locked" field. Teachers may want to do this to prevent further changes from the modules, or from other teachers. When a grade is locked, any grading events that might affect that grade are ignored. When the graded is unlocked, an "unlock" event is triggered, which allows a module to handle it by sending the latest new grades back.

In the main GUIs the lock toggling will be achieved by clicking on a little padlock icon beside each entry or column.

== Manually modified grades ==

Grades can be manually modified (overriden) in the gradebook. When this is done to grade_items derived from a module's grades, and the new value is different from the original one, then the field will automatically be given a locked status (it can of course be unlocked immediately if one wishes). This is to prevent new grading events from changing the manually entered values unexpectedly.

== Clean up after old activities ==

By default columns (grade items) will remain in the gradebook even when activities are deleted. A manual 'clean-up' button can delete old columns if required.

When you click the 'Clean up' button, it shows you a list of columns that should be deleted, with a checkbox next to each one (on by default, but you can turn it off if you want to keep that column still) and then another button click to really delete the marked columns.

Otherwise there will be a site option to do this automatically whenever activities are deleted.

== Logging ==

As well as datestamps and userids in the tables, all grading events will be logged in case an audit needs to be made.

== Security Issues ==

For security an option to force SSL for the gradebook might be good.

==Overall grade==

Having an overall grade handy allows us to know exactly when a course is "finished". Exactly how do we specify the "overall" grade? It's a special case, and might not always be just the sum.

The best solution is probably to have a special calculated column (grade_item) for every course that can not be deleted. It's made special because the itemtype is 'total' (one per course). The calculation formula should be updated automatically whenever grade_items are changed in that course to be the "sum" of all the grade_items in the course.

However, if the calculation is edited manually then we should lock the calculation formula. We could do this by setting the iteminfo field to something. Clearing the calculation to an empty string could force it back to an automatic calculation formula.

== Metacourses ==

All grades in sub-courses should also be viewable from a metacourse.

== Report plugins ==
All the main interface of the gradebook will be implemented as report plugins. Each plugin is fully responsible for defining the interface between the header and footer. They can even define their own capabilities and extra tables if the core tables are not enough, as they'll have a full /grade/report/xxxx/db directory.

Each report will need to define one capability to allow people to see that report, so that admins have control over who can see what reports. For example, the student interface can be a totally separate report plugin.

This allows for the widest flexibility and safety in how grades are presented.

=== Default teacher interface ===
This interface will be what teachers see by default, and will subsume everything the current interface (in Moodle 1.8) does.

Some snippets of functionality:

Overall it's a grid, with student names down one side and grade items along the top.

Teachers can type “straight into” the grid using AJAX or fallback to forms. No popup menus for values.

Columns will be able to be collapsed together by grouping them into categories. Grades for categories can be calculated via various means.

“Eye-cons” on the columns and checkboxes by every grade (this bit possibly controlled with a switch) allow hiding by category, by column, by individual grade.

Textual notes can be added to each grade for more info. These show up to students as well. Later on we can support customisable shorthand codes to make data entry quick (eg type 'ab' for absent, or 'nge' for not good enough).

A groups menu allows the teacher to switch between showing EACH of the groups they have access to, or ALL the groups they have access to.

All grade items will link to modulepath/grade.php?id=44 which will work out what the current person should be allowed to see and either redirect them to the correct page or just show them immediately. This copes with situations like the quiz, say, where we want editing teachers to go to the detailed reports there while students just see their own grade or whatever the quiz is set to show.

User preference to SWITCH between showing raw grades, percentage grades, or both, or grade letters (A/B/C etc).

Settings for grade letters not only define the transformation from percentage to grades, but also the transformation from letters to grades (in case the teacher edits some of the letter grades).

Categories are shown above the headings for each column. Clicking for more info on a category will just show the category with a summary column showing total/average for just that category (PLUS the summary column for the whole course).

All columns should be sortable up/down.

At the bottom of each column is a row with the mean course score. If in groups mode, then add ANOTHER row with just the group mean. Add the number of grades used in brackets. eg 56% (11). When the report is paged, these means are still for the whole course/group (not the page!)

=== Default student interface ===
This interface will be what students see by default:

Some snippets of functionality:

Invert the grid to show one item per row, with the total/average at the bottom.

Use second/third columns to show categories.

Include ranking score in another column.

Include class mean scores in a final column for comparison.

No editing functionality.

== Export plugins ==

The API for these is extremely simple. Each export plugin should occupy a directory under /grade/export/xyz and needs to provide only an index.php file as a the primary interface. This file can accept parameters that produce a subset of the grades:

* courseid
* groupid
* categoryid
* itemid
* userid

The index.php can choose to simply dump something (eg an Excel spreadsheet) and return, or it can show an interface for further options and selections. Ideally even if it dumps something it should also show some feedback about what was exported to make it easier to double check what was sent, but this is up to the plugin to implement.

Further if the plugin contains a lib.php and an xyz_visible() function then the gradebook can check this function to make sure the current user can see/use the plugin (eg by checking access permissions). If this function returns false then the export method won't appear in the main gradebook interfaces.

The export plugins are a "full" Moodle plugin, so it can have tables, cron functions, event handlers, capabilities etc. For example, an export plugin might not even have a GUI (ie xyz_visible() is always false and/or index.php doesn't exist) - it might operate solely off cron or event triggers.

== Import plugins ==

Each import plugin should occupy a directory under /grade/import/xyz and needs to provide only an index.php file as a the primary interface. This file just accepts a 'courseid' parameter.

The index.php will show an interface for further options and selections.

Further if the plugin contains a lib.php and an xyz_visible() function then the gradebook can check this function to make sure the current user can see/use the plugin. If this function returns false then the import method won't appear in the main gradebook interfaces.

The import plugins are a "full" Moodle plugin, so it can have tables, cron functions, event handlers, capabilities etc. For example, an import plugin might not even have a GUI (ie xyz_visible() is always false and/or index.php doesn't exist) - it might operate solely off cron or event triggers.

The entire import must be treated as one operation. If it fails, then no records should be imported and the database is unchanged.

Some sample import plugins are:

===Import from CSV===

Accepts an upload of (or URL to) a CSV file. Multiple options describe how to process the file, which columns to add etc. These should be sticky, and retained via user preferences to make future imports easier.

===Import from XML===

Accepts an upload of (or URL to) an XML file with this kind of format (from OU).

<results batch="[someuniqueimportnumber]">
<result>
<state>['new' or 'regrade']</state>
<assignment>[idnumber]</assignmentid>
<student>[studentid]</student>
<score>[score]</score>
</result>
<result>
<state>['new' or 'regrade']</state>
<assignment>[idnumber]</assignmentid>
<student>[studentid]</student>
<score>[score]</score>
</result>
[...]
</results>

== Capabilities and Permissions ==

* moodle/course:viewcoursegrades

* moodle/course:downloadcoursegrades

* moodle/user:viewusergrades

* moodle/grade:viewhidden

* moodle/grade:editlocked

* moodle:site/accessallgroups

== Interface Mockups ==

Nicolas is working on a mock-up interface that you can play with:

[http://test.moodle.com/gradebook/ Mock Gradebook]

It's changing rapidly in response to your feedback.

== Rough Development Timeline ==

# Develop Event API
## Core tables
## events.php to load/maintain handlers
## Core API functions lib/eventslib.php and unit tests
# Develop Core Gradebook
## Core tables
## Core API functions lib/gradelib.php and unit tests
## Core handler for grade changes
## Define plugin directory structure
## Cron job for support of legacy grade functions in modules
# Core Moodle improvements
## Support for all grades-based plugins for db, cron, access.php, events.php etc
# Develop Core activity modules
## Triggers for all major activity modules
## Handlers for all major activity modules
# Reports
## Standard report for teachers
## Standard report for students
# Exports
## Standard exports (like 1.8)
## XML export (OU format)
# Imports
## CSV format

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69223&mode=3 Gradebook Development ideas] forum discussion
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=51107 New gradebook for Moodle] forum discussion
* [[Development:Events]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:54:41Z

Lazyfish: /* events_queue_handlers */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 3 core tables for events. Note that if a handler is queued, and yet to be processed or processing failed, then all subsequent calls on that handler must be queued.

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queues===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queues table. When no further reference is made to the event_queues table, the corresponding entry in the event_queues table should be deleted. Entry should get deleted (?) after a successful event processing by the specified handler.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queues table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|errormessage
|text
|if an error happened last time we tried to process this event, record it here.
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:54:01Z

Lazyfish: /* events_queued_events */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 3 core tables for events. Note that if a handler is queued, and yet to be processed or processing failed, then all subsequent calls on that handler must be queued.

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queues===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted. Entry should get deleted (?) after a successful event processing by the specified handler.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|errormessage
|text
|if an error happened last time we tried to process this event, record it here.
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:33:52Z

Lazyfish: /* Database structure */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 3 core tables for events. Note that if a handler is queued, and yet to be processed or processing failed, then all subsequent calls on that handler must be queued.

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted. Entry should get deleted (?) after a successful event processing by the specified handler.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|errormessage
|text
|if an error happened last time we tried to process this event, record it here.
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:28:09Z

Lazyfish: /* events_queue_handlers */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted. Entry should get deleted (?) after a successful event processing by the specified handler.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|errormessage
|text
|if an error happened last time we tried to process this event, record it here.
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:10:22Z

Lazyfish: /* events_queue_handlers */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|errormessage
|text
|if an error happened last time we tried to process this event, record it here.
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:09:48Z

Lazyfish: /* events_queued_events */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|stackdump
|text
|serialized debug_backtrace showing where the event was fired from
|-
|userid
|int(10)
|$USER->id when the event was fired
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:07:38Z

Lazyfish: /* event_queue_handlers_todo */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===events_queue_handlers===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T06:06:53Z

Lazyfish: /* event_queued_events */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:56:36Z

Lazyfish: /* event_queue_handlers_todo */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===

This is the list of queued handlers for processing. The event object is retrieved from the event_queued_events table. When no further reference is made to the event_queued_events table, the corresponding entry in the event_queued_events table should be deleted.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:55:04Z

Lazyfish: /* event_queued_events */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the event_queue_handlers_todo table.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:53:36Z

Lazyfish: /* events_queue */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:52:45Z

Lazyfish: /* event_queue_handlers_todo */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queued_events table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:52:25Z

Lazyfish: /* event_queue_handlers_todo */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|foreign key id corresponding to the id of the event_queue table
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:49:55Z

Lazyfish: /* event_queue_handlers_todo */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|queuedeventid
|int(10)
|id referencing queued event
|-
|handlerid
|int(10)
|id referencing event handler
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:47:55Z

Lazyfish: /* event_queued_events */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===
{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|}

===event_queue_handlers_todo===

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-18T05:44:37Z

Lazyfish: /* Database structure */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===event_queued_events ===

===event_queue_handlers_todo===

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=69103 General Developer Forum thread for discussing this proposal].
* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-13T07:25:42Z

Lazyfish: /* Database structure */

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

==Overview==

We'll be using the example of a grade being posted from a module into the [[Development:Grades|new gradebook in Moodle 1.9]], but there are obviously all kinds of events possible.

===Triggering an event===

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object;
$eventdata->courseid = $course->id;
$eventdata->itemname = $quiz->name;
$eventdata->itemtype = 'mod';
$eventdata->itemmodule = 'quiz';
$eventdata->iteminstance = $quiz->id;
$eventdata->itemnumber = 1;
$eventdata->iteminfo = $quiz->info;
$eventdata->idnumber = $cm->idnumber; // new field in 1.9
$eventdata->grademax = $quiz->grade;
$eventdata->grademin = 0;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

trigger_event('grade_added', $eventdata);

===Handling an event===

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$events = array (
'grade_added' => array (
'file' => '/grade/export/banner/lib.php',
'function' => 'banner_handle_grade', // argument to call_user_func(), could be an array
'timing' => 'cron'
);
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

include_once($CFG->dirroot.$events['grade_added']['file'];
call_user_func($events['grade_added']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_added' events (and of course any other events).

==Database structure==

There are 2 core tables for events.

- do we need a separate events_log table too?

===events_handlers===

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|eventname
|varchar(255)
|name of the event, e.g. 'grade_added'
|-
|handlermodule
|varchar(255)
|e.g. moodle, mod/forum, block/rss_client
|-
|handlerfile
|varchar(255)
|path to the file of the function, eg /grade/export/lib.php
|-
|handlerfunction
|text
|serialized string or array describing function, suitable to be passed to '''call_user_func()'''
|}

===events_queue===

The event queue table should put all responding events into the queue. For example, an event triggered by grade book 'grade_updated' can result in the response of all modules. Each response should be either queued or processed instantly. If an "instant" event is not processed successfully it is then queued. So a 'grade_updated' event could insert multiple records into the event_queue table. The status field counts failures - if the failures reach some high number then some action should be taken (alert the admin etc).

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Info'''
|-
|id
|int(10)
|auto increment identifier
|-
|handlerid
|int(10)
|foreign key id corresponding to the id of the event_handlers table
|-
|eventdata
|longtext
|serialized version of the data object passed to the event handler.
|-
|schedule
|varchar(255)
|'cron' or 'instant'.
|-
|status
|int(10)
|number of failed attempts to process this handler
|-
|timecreated
|int(10)
|time stamp of the first time this was added
|-
|timemodified
|int(10)
|time stamp of the last attempt to run this from the queue
|}

==Standards for naming events==

All event names should follow a consistent naming pattern, such as modulename_noun_verb

== See also ==

* [[Development:Grades]]

[[Category:Developer]]
[[Category:Grades]]

Development:Events API

2007-04-12T07:17:53Z

Lazyfish: /* event queue */

Development:Events API

2007-04-12T07:16:37Z

Lazyfish: /* event queue */

Development:Events API

2007-04-12T07:15:08Z

Lazyfish: /* event table */

Development:Events API

2007-04-12T07:12:58Z

Lazyfish: /* event queue */

Development:Events API

2007-04-12T07:12:43Z

Lazyfish: /* event table */

Development:Events API

2007-04-12T07:12:20Z

Lazyfish: /* event table */

Development:Events API

2007-04-12T07:11:44Z

Lazyfish: /* Database structure */

Projects for new developers

2007-03-26T07:53:01Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 26 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc) This could potentially use an AJAX implementation for multiple filtering/selection of required students for bulk operations.
** Overhall the CSV upload features to allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877 MDL-8877])
* Notes
** Allow teachers to put notes for each student in every course, much requested feature ([http://tracker.moodle.org/browse/MDL-7077 MDL-7077])
Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

====Moodle Voice====

*Objective
Adapt Moodle interface to output the needed VoiceXML so you can navigate with your voice with a VoiceXML enabled browser, such as Opera.

*Benefits
Making Moodle voice enabled will help disabled people, specially blind and motor disabled, to interact with this great e-Learning tool. Not only that, but also this gives another input interface which can be used to interact faster with the application.

*Scope
Due to the large Moodle code, the scope of what to make voice enabled will be decided in the Analysis phase, although it will be at least all navigational stuff, such as course selection, profile configuration and resource selection.

*State of the Art of VoiceXML
VoiceXML is a well known technology that has been used and supported by IVR several years. Now it has finally come to our desktop. Currently, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror]. Some examples of this technology can be found at:
# http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
# http://dev.opera.com/articles/view/temporary-x-v-by-example/
# http://dev.opera.com/articles/view/xhtml-voice-in-action/

*Architecture Description
**We have the option of using [http://moodle.org/mod/forum/discuss.php?d=31895 Customized Scripts] so we will [https://docs.moodle.org/en/Developer_Overview_of_MFM_Code not interfere with normal Moodle development]. On the other hand, we can directly merge it in the current CVS.
**Our code will detect whether the user browser is VoiceXML enabled or not and send the corresponding code
**In the "future roadmap" it will be included how to embed the code in Moodle core (in case it isnt) and make a Moodle configuration option to activate voice features. (It can be done in the project if we have enough time)

*Related Work
** [https://docs.moodle.org/en/Moodle_for_Mobiles Moodle for Mobiles] [http://moodle.cvs.sourceforge.net/moodle/contrib/patches/mobile/ CVS]: Outputs [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ Compact HTML], uses [http://moodle.org/mod/forum/discuss.php?d=31895 Customized Scripts]

*Also see
**More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].
**More info on the [http://gsoc.davidhorat.com/index.php?title=Project_Proposal Project Proposal].

'''Possible Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-26T07:49:08Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 26 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CSV upload features to allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877 MDL-8877])
* Notes
** Allow teachers to put notes for each student in every course, much requested feature ([http://tracker.moodle.org/browse/MDL-7077 MDL-7077])
Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

====Moodle Voice====

*Objective
Adapt Moodle interface to output the needed VoiceXML so you can navigate with your voice with a VoiceXML enabled browser, such as Opera.

*Benefits
Making Moodle voice enabled will help disabled people, specially blind and motor disabled, to interact with this great e-Learning tool. Not only that, but also this gives another input interface which can be used to interact faster with the application.

*Scope
Due to the large Moodle code, the scope of what to make voice enabled will be decided in the Analysis phase, although it will be at least all navigational stuff, such as course selection, profile configuration and resource selection.

*State of the Art of VoiceXML
VoiceXML is a well known technology that has been used and supported by IVR several years. Now it has finally come to our desktop. Currently, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror]. Some examples of this technology can be found at:
# http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
# http://dev.opera.com/articles/view/temporary-x-v-by-example/
# http://dev.opera.com/articles/view/xhtml-voice-in-action/

*Architecture Description
**We have the option of using [http://moodle.org/mod/forum/discuss.php?d=31895 Customized Scripts] so we will [https://docs.moodle.org/en/Developer_Overview_of_MFM_Code not interfere with normal Moodle development]. On the other hand, we can directly merge it in the current CVS.
**Our code will detect whether the user browser is VoiceXML enabled or not and send the corresponding code
**In the "future roadmap" it will be included how to embed the code in Moodle core (in case it isnt) and make a Moodle configuration option to activate voice features. (It can be done in the project if we have enough time)

*Related Work
** [https://docs.moodle.org/en/Moodle_for_Mobiles Moodle for Mobiles] [http://moodle.cvs.sourceforge.net/moodle/contrib/patches/mobile/ CVS]: Outputs [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ Compact HTML], uses [http://moodle.org/mod/forum/discuss.php?d=31895 Customized Scripts]

*Also see
**More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].
**More info on the [http://gsoc.davidhorat.com/index.php?title=Project_Proposal Project Proposal].

'''Possible Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-23T03:17:18Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 27 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students. The former one is to set parameters such as file type and size, submission times, compiler and grade program type and so on; the latter one is to decide all parameters, perform a specific compiler and finally realize to grade.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CVS upload features to allow allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877 MDL-8877])
* Notes
** Allow teachers to put notes for each student in every course, much requested feature ([http://tracker.moodle.org/browse/MDL-7077 MDL-7077])
Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

====Making Moodle VoiceXML enabled====

Think about navigating through Moodle just with your voice ...

How about making Moodle one of the first Open Source applications [http://www.voicexml.org/ VoiceXML] enabled? It will be a very good method of helping mobility disabled people. As far as I know, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror].

More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-23T01:53:11Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 27 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students. The former one is to set parameters such as file type and size, submission times, compiler and grade program type and so on; the latter one is to decide all parameters, perform a specific compiler and finally realize to grade.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CVS upload features to allow allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877 MDL-8877])

Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

====Making Moodle VoiceXML enabled====

Think about navigating through Moodle just with your voice ...

How about making Moodle one of the first Open Source applications [http://www.voicexml.org/ VoiceXML] enabled? It will be a very good method of helping mobility disabled people. As far as I know, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror].

More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-23T01:52:50Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 27 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students. The former one is to set parameters such as file type and size, submission times, compiler and grade program type and so on; the latter one is to decide all parameters, perform a specific compiler and finally realize to grade.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CVS upload features to allow allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877 MDL8877])

Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

====Making Moodle VoiceXML enabled====

Think about navigating through Moodle just with your voice ...

How about making Moodle one of the first Open Source applications [http://www.voicexml.org/ VoiceXML] enabled? It will be a very good method of helping mobility disabled people. As far as I know, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror].

More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-23T01:52:15Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 27 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students. The former one is to set parameters such as file type and size, submission times, compiler and grade program type and so on; the latter one is to decide all parameters, perform a specific compiler and finally realize to grade.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CVS upload features to allow allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments ([http://tracker.moodle.org/browse/MDL-8877])

Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

====Making Moodle VoiceXML enabled====

Think about navigating through Moodle just with your voice ...

How about making Moodle one of the first Open Source applications [http://www.voicexml.org/ VoiceXML] enabled? It will be a very good method of helping mobility disabled people. As far as I know, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror].

More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Projects for new developers

2007-03-23T01:51:13Z

Lazyfish: /* User Management Improvements */

This page currently lists the projects available Moodle's participation in the [http://code.google.com/soc Google Summer of Code 2007]. Each project here is a nice self-contained project suitable for student programmers to complete in three months or less, and must have an associate mentor who is a regular Moodle developer.

'''Moodle Developers''', please add your project ideas to this page using the existing format. Make sure you include your own name as a mentor.

'''Students''', please try and choose projects that already have mentors - there is a much better chance that your application might be accepted.

[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants YOU HAVE UNTIL MONDAY MARCH 27 TO APPLY]!!

==Google Summer of Code 2007 Projects==

===Projects with Mentors===

The following projects are in no particular order!

====Developing new question types for the quiz====

The quiz has a plug-in architecture for question types. We currently have implementations of most of the basic question types, it would be nice to have implementations of some more interesting types, perhaps using the YUI JavaScript library to do some interesting interactions (but with an accessible fall-back). Which question types could be left up to the student, but some suggestions are:

* Drag and drop versions of ordering and matching question types.
* Place a marker or draw a line on an image question types.
* Drag the missing words into the sentence/onto an image question type.

Another way to find question types to implement would be to review other systems and make sure Moodle supports all the question types that other systems support.

I envisage that some of these question types would be incorporated into the standard Moodle install, but others would just be put in the contrib area. Part of the project could also be improving the plugin API. There are some minor know issues with it that make it harder that it needs to be to install new question types from contrib.

'''Mentor:''' Tim Hunt

====Enterprise-level improvements====

Here are a few things you could do to help Moodle run in a heavy environment (either big Moodles or many multiple Moodles).

* Adapt all the DB installation and upgrade scripts to run from the command line, so fully scripted installations are possible without using the web interface.

* Develop a profiling system for developers to use when testing their code. Aim to spot and fix performance bottlenecks in Moodle with good reports and suggestions about what developers could do.

Mentor: Martin Langhoff or Penny Leach

====Chat revamp====

mod/chat needs a bit of an overhaul. Possible interesting approaches:

* Simplify chatd and rewrite as a proper forking daemon. Great process control and networking project, and properly a good case for a bit of AJAX.
* Integrate Moodle with a Jabber backend, plus frontend glue.
** On the backend, we need to consider authentication, chatroom creation, and logging.
** On the frontend, ensuring that we can get Jabber clients started reliably on the end-user's machine, and integrate a preexisting web-based Jabber client for Jabber-impaired users.
** Installation matter: a clear install HowTo for the Jabber + Moodle.

Mentors: Martin Langhoff, [[User:Geoff Cant|Geoff Cant]] (ejabberd)

Notes from Geoff (who's a keen Erlang hacker):

:ejabberd (http://ejabberd.jabber.ru/) is the worlds most scalable jabber server (tested to 600k concurrent connections :) and written in Erlang so I'm keen on it and able to hack on it.

:ejabberd supports http bind (http://www.xmpp.org/extensions/xep-0124.html) which will allow the integration of a jabber client directly into moodle web pages. ejabberd also supports traditional GUI jabber clients.

:We could hack ejabberd to authenticate against a moodle and probably create MUC/groupchats automatically based on moodle course information.

:jwchat (http://jwchat.sourceforge.net) seems like it could provide the basis for a generic http jabber client for moodle. The chat revamp could be two projects - one PHP/HTML to integrate jwchat into moodle and an Erlang one to alter ejabberd to do SSO, auth, automatic roster creation and so on.

====Messaging improvements====

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

Mentors: Martin Dougiamas, Dan Poltawski (and others?)

====Automated grading for Computer Programming Assignments====

From Arkaitz Garro <arkaitz.garro@gmail.com>:

My name is Arkaitz Garro, and I'm actually studing computer science
engineering at Basque Country University (Spain).

As a part of my master thesis (graduating final work), I'm developing a plugin
for Moodle that consists in automated grading system designed to process
computer programming assignments, bassed on actual Assignment plugin.

Computer Programming students will submit their programming assignments
(developed in Java, C++, C# or other OOP language) to Moodle, and our plugin
will test that the output of these programs is correct (or not). Besides that,
our plugin will test security and performance issues before and during the
grading automation.

From Xing Shi <paradiseHIT@gmail.com>

I also want to join this project, and I have developed a similar plugin (I call it "PA-Plugin") one years ago. But it can only work for language C and C++, and only for one source file(such as main.c), not for a project. Till now it works very well on our department web. And I want to develop more functions for the plugin, such as add the java language, and make a more better architecture.

Mainly, PA-Plugin realizes two functions: delivery of programming assignments by teachers and submission of programming assignments by students. The former one is to set parameters such as file type and size, submission times, compiler and grade program type and so on; the latter one is to decide all parameters, perform a specific compiler and finally realize to grade.

To the teachers, PA-Plugin can set lots of parameters to the programming assignments, such as compiler type, grader type, max time and the max memory limitation, the resubmit times, the test data for the grader, and the grade standard data. Also the teacher can regrade all the programming assignments when one (or many) parameter is changed.

To the students, the PA-Plugin will firstly detective the submitted file's type, size. If OK, then the server will compile the file to produce the bin-file, and the grader will execute the bin-file and grade the output, such as acm(Association for Computing Machinery).

Mentor: Penny Leach

==== User Management Improvements ====

* Improve the User features in moodle to allow bulk-operations.
** Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc)
** Overhall the CVS upload features to allow allow more flexibility (more options, features to auto-generate more fields such as usernames)
* Enrolment
** Specify time of manual enrollments (MDL-8877)

Mentor: Yu Zhang

==== Email interface to Moodle ====

The idea is to let people reply naturally to email they receive from Moodle to change settings or add further comments into forums etc. Moodle activities can then be accessed like a mailing list.

* Add a setting so admins can specify if they want an email interface enabled. Without it, none of the following is active and Moodle functions just as it does today.
* Improve the outgoing emails in Moodle to contain a unique and robust code in the headers and potentially also in the subject line (switchable by user setting) that encrypts information about the receiver, the activity instance and the specific data. For example, all the information to securely identify a forum post.
* Write a PHP script designed to run from the commandline as part of an email filter, that accepts emails on standard input, parses them and then calls a function in the relevant module. For example forum_incoming_email() in mod/forum/lib.php.
* Write function for forum module (at least) to parse the content of the email and add it as a post from the user. Other modules can be worked on if there's time ... resources could be sent back as attachments, quizzes could send questions and accept multiple choice answers, the course could send back a listing of activities with further codes for each one, etc.
* Security is essential!

Mentor: Martin Dougiamas

==== Secure RSS feeds ====

Currently RSS is less than useful because:
* Either we can't publish private information to the outside world because it's too sensitive.
* We open up sensitive information to the outside world

We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.

* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).
* Store these codes in a new field per-user and per-course.
* Add GUIs to let the user recreate their code to something else should they suspect a breach.
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.
* Explore/research other methods of opening up RSS in a safe way to the outside world.

Mentor: Petr Škoda

==== External RSS feeds into Blogs ====

A lot of people already have their own blogs and don't want to use Moodle's blogs. Fair enough!

This project would add user settings allowing users to specify an external RSS feed to their own external blog. Moodle will parse the feed and insert entries as internal blog entries for that user. other features include:

* Specifying tags that identify required posts in that feed (eg "school").
* Specifying default access permissions and Moodle tags for those entries.
* Keeping links to the external entry, so that when you want to "comment" on the blog entry you are taken to that external blog system.
* Tools for admins to monitor information flow.
* Other things the community may ask for.

Mentor: Martin Dougiamas

==== Social Networking features ====

Explore the possibilities of social networking features by expanding the user profile page:

* add user tags that describe interests etc, as links to "interest pages" eg constructivism
* interest pages that contain information about all the people who share that interest, as well as blog entries that use that tag, google searches, other info using standard Moodle blocks etc
* allow users to add other users as "friends", which are displayed on their user profile pages
* think about controls to prevent abuse of these features in a school environment.

Mentor: Martin Dougiamas

==== Roles interface improvements ====

Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:

* Improve the order of the capabilities and implement better grouping.
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.
* Add floating tooltip help when you hover over any given capability.
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the moodle comunity (rather than having to describe the permissions setup)
* Analyse the problem carefully with feedback from the community for more ideas.

'''Mentor''': Martin Dougiamas

----

===Projects without Mentors===

====Integration with bibliographic systems such as Wikindx====

Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.

Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).

Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:

* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items
* Generate reading lists / bibliographies
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)

See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too

====Implement CATs in Moodle====

[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online.

Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would

# Make Moodle an even better teaching tool.
# Provide some good exemplars of how to do interesting things with database templates.
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.

This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.

====Making Moodle VoiceXML enabled====

Think about navigating through Moodle just with your voice ...

How about making Moodle one of the first Open Source applications [http://www.voicexml.org/ VoiceXML] enabled? It will be a very good method of helping mobility disabled people. As far as I know, this technology is only supported by [http://dev.opera.com/articles/voice/ Opera] in the standard browsers field, but since it is a [http://www.w3.org/TR/voicexml20/ W3C Standard], I hope it will become the defacto technology for this kind of service in all browsers. There are already plans to implement it in [http://wiki.mozilla.org/Firefox:2.0_Accessibility Firefox] and [http://www.qsos.org/sheets/webbrowser/konqueror/konqueror-3.5.5.html Konqueror].

More info about [http://en.wikipedia.org/wiki/Multimodal_interaction Multimodal Interaction].

==== Blog Assignment Type ====

'''What is it for?'''

Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.

A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).

I suggest a blog assignment type that functions as follows:

'''Teacher:'''
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.

The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.

'''Students:'''
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.

'''Assessment:'''
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.

The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).

==Google Summer of Code 2006 Projects==
#[[Student projects/Presets for Database module|Presets for Database module project notes]]
#[[Student projects/Integrated bug tracker|Integrated bug tracker project notes]]
#[[Student projects/AJAX course format|AJAX course format project notes]]
#[[Student projects/Admin page cleanup|Admin page cleanup project notes]]
#[[Student projects/Global search|Global search project notes]]

==Other Projects==

#[[Student projects/ical|Calendar export to iCal]]

[[Category:Developer]]
[[Category:Project]]

Roles and permissions

2006-11-29T03:51:26Z

Lazyfish: /* Roles */

{{Roles}}
{{Moodle 1.7}}

==Roles==

Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system.

With Roles, authorised users can [[Manage roles|create]] any number of customised roles and assign them to users. From 1.7, an organisation can create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.

Definitions
*A '''role''' is an identifier of the user's status in some context. For example, teacher, student and forum moderator are examples of roles.
*A '''capability''' is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.
*A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role. For example, allow or prevent.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks etc. Roles will only work if the role assignment is made at the correct context level. For example, a "teacher" role should be assigned at course context level, a "forum moderator" for a particular forum should be assigned at the activity level, an "administrator" should be assigned at the system level and so on.

The list of contexts in hierarchical order:

**The System context is accessible via the administrator's block. (no parent)
**The Course category context is accessbile in the course category page. (parent = site)
**The Course context is accessible via the course administration block (old admin block). (parent = course category or site)
**The Module context is accessible during updating the module. (parent = course)
**The Block context is accessible when editting mode is on. (parent = site or course)
**The User context is accessbile by viewing the user profile and click on "Roles" tab (parent = site)

Inheritance will kick in if a role is assigned at a higher level. For example, assigning a "teacher" to a course category will make this user the teacher for ALL courses within the category.

==Capabilities==

Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle (eg delete discussions, add activities etc). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

==Upgrading to 1.7==

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

==See also==
*[[Development:Roles]]
*Using Moodle [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum]

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

Roles and permissions

2006-11-29T03:50:07Z

Lazyfish: /* Roles */

{{Roles}}
{{Moodle 1.7}}

==Roles==

Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system.

With Roles, authorised users can [[Manage roles|create]] any number of customised roles and assign them to users. From 1.7, an organisation can create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.

Definitions
*A '''role''' is an identifier of the user's status in some context. For example, teacher, student and forum moderator are examples of roles.
*A '''capability''' is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.
*A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role. For example, allow or prevent.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks etc. Roles will only work if the role assignment is made at the correct context level. For example, a "teacher" role should be assigned at course context level, a "forum moderator" for a particular forum should be assigned at the activity level, an "administrator" should be assigned at the system level and so on.

The list of contexts in hierarchical order:

The System context is accessible via the administrator's block. (no parent)
The Course category context is accessbile in the course category page. (parent = site)
The Course context is accessible via the course administration block (old admin block). (parent = course category or site)
The Module context is accessible during updating the module. (parent = course)
The Block context is accessible when editting mode is on. (parent = site or course)
The User context is accessbile by viewing the user profile and click on "Roles" tab (parent = site)

Inheritance will kick in if a role is assigned at a higher level. For example, assigning a "teacher" to a course category will make this user the teacher for ALL courses within the category.

==Capabilities==

Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle (eg delete discussions, add activities etc). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

==Upgrading to 1.7==

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

==See also==
*[[Development:Roles]]
*Using Moodle [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum]

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

Roles and permissions

2006-11-29T03:47:02Z

Lazyfish: /* Roles */

{{Roles}}
{{Moodle 1.7}}

==Roles==

Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system.

With Roles, authorised users can [[Manage roles|create]] any number of customised roles and assign them to users. From 1.7, an organisation can create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.

Definitions
*A '''role''' is an identifier of the user's status in some context. For example, teacher, student and forum moderator are examples of roles.
*A '''capability''' is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.
*A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role. For example, allow or prevent.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks etc. Roles will only work if the role assignment is made at the correct context level. For example, a "teacher" role should be assigned at course context level, a "forum moderator" for a particular forum should be assigned at the activity level, an "administrator" should be assigned at the system level and so on.
The System context is accessible via the administrator's block.
The Course category context is accessbile in the course category page.
The Course context is accessible via the course administration block (old admin block).
The Module context is accessible during updating the module.
The Block context is accessible when editting mode is on.
The User context is accessbile by viewing the user profile and click on "Roles" tab

==Capabilities==

Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle (eg delete discussions, add activities etc). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

==Upgrading to 1.7==

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

==See also==
*[[Development:Roles]]
*Using Moodle [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum]

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

Development:Roles

2006-11-16T02:52:02Z

Lazyfish: /* Core-level Capabilities */

'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.

==Definitions==

A role is an identifier of the user's status in some context. For example, teacher, student and fourm moderator are examples of roles.

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

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

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

==The existing system==

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

==The new roles and capability system==

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

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

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

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

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

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

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

Capabilities can have the following permissions:

#CAP_INHERIT
#CAP_ALLOW
#CAP_PREVENT
#CAP_PROHIBIT

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

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

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

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

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

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

==Upgrading from 1.6==

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

===Admins===

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

===Course Creators===

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

===Teachers===

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

===Students===

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

===Guests===

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

==Capabilities==

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

===Core-level Capabilities===

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

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

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

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

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

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

===Enrolment-level Capabilities===

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

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

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

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

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

==Programming Interface==

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

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

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

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

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

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

==Metacourses==

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

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

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

==Problem areas we are working on ==

===Student view===

The "Student view" button has been removed completely.

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

===Teacher forum===

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

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

===Enrolment plugins===

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

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

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

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

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

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

====Process of enrolling====

(more soon)

==Scenario brainstorming==

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

===Student===
Obviously.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===Visitor===

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

===Guest Speaker===

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

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

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

===Librarian===

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

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

===Teacher===

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

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

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

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

===Secretary/Student Worker===

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

===Teaching Assistant===

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

===Student - FERPA rights===

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

===Help Desk===

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

===Admin - Catgory based===

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

===Process Roles===

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

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

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

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

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

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

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

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

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

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

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

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

==See also==

*Using Moodle forum discussion
**[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
**[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]
[[Category:Developer]]
[[Category:Future]]
[[Category:Roles]]

Capabilities/moodle/site:approvecourse

2006-10-31T06:19:09Z

Lazyfish:

moodle/site:approvecourse allows a user to approve a pending course request

Context:
System

Capabilities/moodle/site:config

2006-10-31T06:13:32Z

Lazyfish:

moodle/site:config allows a user to config various site settings accessible from the admin menu, view phpmyadmin (mysql only), and so on.

Contexts:
System

Capabilities/moodle/course:setcurrentsection

2006-10-31T06:07:05Z

Lazyfish:

allows a user to set the current section

Capabilities/moodle/course:viewhiddensections

2006-10-31T06:06:50Z

Lazyfish:

allows a user to view hidden course sections

Capabilities/moodle/course:sectionvisibility

2006-10-31T06:06:21Z

Lazyfish:

allows a user to hide/unhide course sections

Capabilities/moodle/question:managecategory

2006-10-31T06:05:59Z

Lazyfish:

allows a user to manage question categories

Capabilities/moodle/course:reset

2006-10-31T06:05:12Z

Lazyfish:

allows a user to reset a course

Capabilities/moodle/course:managegroups

2006-10-31T06:04:46Z

Lazyfish:

allows a user to add/delete/update groups in a course

Capabilities/moodle/course:managescales

2006-10-31T06:04:27Z

Lazyfish:

allows a user to add/update/delete course scales

Capabilities/moodle/course:viewscales

2006-10-31T06:04:03Z

Lazyfish:

allows a user to view course scales