MoodleDocs - User contributions [en]

Moodle 2.0 release notes

2010-11-25T14:00:26Z

Iarenaza: Fix credits for Iñaki Arenaza (or my employer will complain ;-)

Release date: '''24th November, 2010'''

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

===Major new features===

====[[Community hub|Community hubs]]====

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

====[[Repositories|Repository support]]====

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

====[[Portfolios|Portfolio support]]====

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

====[[Completion]]====

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

====[[Conditional activities]]====

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

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

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

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

====[[Plagiarism Prevention|Plagiarism prevention]]====

* Moodle supports integration with plagiarism prevention tools such as Turnitin

===Major improvements to existing core features===

====[[Backup 2.0|Backup and restore]]====

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

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

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

====[[Comments 2.0|Comments]]====
* User comments (Glossaries, Databases, Blogs, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available

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

====[[File handling 2.0|File handling]]====

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

====[[Filters 2.0]]====

* In the past, you had to use the same filters everywhere in your Moodle site, and this could only be changed by admins.
* Now, you can have different filters in different courses, activities or categories.
* For example, you could turn on the LaTeX filter just for courses in the Maths and Physics categories.
* Or you could turn off glossary linking in the end of course exam.

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

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

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

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

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

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

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

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

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

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

===Major improvements to activity modules===

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

====Quiz module and question bank====

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

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

====SCORM====

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

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

====[[Workshop module 2.0|Workshop]]====

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

<noinclude>==System requirements==

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

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

==Upgrading==

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

For further information, see [[Upgrading to Moodle 2.0]].

==For developers: API changes==

See [[Development:Migrating contrib code to 2.0]]

* [[Development:Plugin system changes in Moodle 2.0]] - all the different types of plugin are now handles more consistently when it comes to installation and upgrading, capabilities, events, and so on.
* [[Development:DB_layer_2.0_migration_docs|Database layer changes]] - you will need to update your code.
* [[Development:Using_the_file_API|File handling changes]] - you will need to update your code.
* [[Development:Migrating your code code to the 2.0 rendering API|Rendering layer changes]] - should be mostly backwards compatible, but you are advised to upgrade your code.
* Require capability used to do an automatic require_login. It no longer does so. All pages must explicitly call require_login if they need it. MDL-19882
* [[Development:Moodle_2.0_question_type_API_changes|Changes to the question type API]]
* MNet has been refactored and tidied up - related third party code needs to be checked
* Changes and improvements to the [[Development:Local_customisation|Local customisation system]].
* Javascript
* YUI
* custom profile fields values are loaded into $USER->profile array instead of directly into $USER object

==Credits==

These people made check-ins to Moodle 2.0 code. Thanks to all of them, of course. Some of these people represent a team of people who actually worked on the code.

* Robert Allerstorfer (anet.at)
* Aaron Barnes, Peter Bulmer, Matt Clarkson, Jonathan Harker, Piers Harding, Luke Hudson, Martin Langhoff, Dan Marsden, Francois Marier, Donal McMullan, Jonathan Newman (catalyst.net.nz)
* Howard Miller (e-learndesign.co.uk)
* Iñaki Arenaza (mondragon.edu)
* Andreas Grabs (grabs-edv.de)
* Jamie Pratt (jamiep.org)
* Anthony Borrow (jesuits.net)
* Gordon Bateson (kanazawa-gu.ac.jp)
* Samuli Karevaara (lamk.fi)
* Penny Leach (liip.ch)
* Dan Poltawski (luns.net.uk)
* Matt Oquist (majen.net)
* Roberto Pinna (mfn.unipmn.it)
* Michael Ketcham (microsoft.com)
* Mitsuhiro Yoshida (mitstek.com)
* Aparup Banerjee, Dongsheng Cai, Nicolas Connault, Andrew Davis, Martin Dougiamas, Helen Foster, Sam Hemelryk, Eloy Lafuente, Jerome Mouneyrac, David Mudrak, Mathieu Petit-Clair, Petr Skoda, Rossiani Wijaya, Yu Zhang (moodle.com)
* Mark Nielsen (moodlerooms.com)
* Andrea Bicciolo (mtouch.it)
* John Beedell, Nicholas Freear, Jenny Gray, Tim Hunt, Sam Marshall, Gareth Morgan, Derek Woolhead (open.ac.uk)
* Ashley Holman (netspot.com.au)
* Patrick Malley (newschoollearning.com)
* Eric Merrill (oakland.edu)
* Mike Churchward (oktech.ca)
* Shane Elliott (pukunui.com)
* Shamim Rezaie (rezaie.info)
* Joseph Rezeau (rezeau.org)
* Lukas Haemmerle (switch.ch)
* Urs Hunkler (unodo.de)
* Jordi Piguillem (upc.edu.es)
* Pierre Pichet (uqam.ca)
* Gustav Delius (york.ac.uk)
* Ethem Evlice, Valery Fremaux, Dariem Garces, Wen Hao Chuang, Luis Rodrigues, Olli Savolainen, John Stabinger

==See also==

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

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

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

New enrolments in 2.0

2010-08-08T03:14:43Z

Iarenaza: LDAP enrolment implemented

{{Infobox Project
|name = New enrolments in 2.0
|state = Work in progress
|tracker = MDL-21782
|discussion = n/a
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]
}}
{{Moodle 2.0}}

=Overview=
The major difference from 1.6-1.9 enrolments is that the course enrolment information is stored again in a separate database table ''user_enrolments''. The enrolment related information was move from ''course'' table to new ''enrol'' table which holds plugin instances. The old enrolment plugins need to be completely rewritten. Course category enrolments via role assignments is not possible any more, existing category enrolments are migrated to new cohorts and cohort enrolment plugin.

The benefits are:
* we can use SQL to find enrolled users in any course extremely quickly (much better performance)
* multiple enrolment plugins per course are full supported (includes more instances of the same type)
* new enrolment overview interface
* user enrolments may be suspended and reactivated
* plugin may prevent users to change/break enrolment synchronised with external systems
* finer access control, more flexible/configurable course settings UI
* no hardcoded enrolment behaviour - it is possible to completely replace guest access, self enrolments, etc. with custom plugins

=Database structure changes=

==New user_enrolments table==
New table which stores users participating in courses (aka enroled users). It can be used directly in SQL joins.

{| class="nicetable"
! Field
! Type
! Default
! Description
|-
| '''id'''
| int(10)
| auto-incrementing
|
|-
| status
| int(10)
| 0
| 0 means active enrolment, 1 means suspended, anything else means inactive (user can not access course) and is defined by plugin
|-
| '''enrolid'''
| int(10)
|
| foreign key, references enrol.id
|-
| '''userid'''
| int(10)
|
| foreign key, references user.id
|-
| '''timestart'''
| int(10)
| 0
| time stamp, start of active participation period
|-
| '''timeend'''
| int(10)
| 0
| time stamp, end of active participation period
|-
| modifierid
| int(10)
|
| last user who modified enrolment, references user.id
|-
| timemodified
| int(10)
|
| timestamp, last modification
|}

==New enrol table==
Stores information about enrolment plugins used in course, includes plugin configuration data and instance status. The optional fields have plugin specific meanings, plugins may define other tables related via the enrol.id if necessary.

{| class="nicetable"
! Field
! Type
! Default
! Description
|-
| '''id'''
| int(10)
| auto-incrementing
|
|-
| '''enrol'''
| char(20)
|
| enrolment plugin name
|-
| '''status'''
| int(10)
| 0
| 0 means active plugin, anything else means inactive (user can not access course) and is defined by plugin
|-
| '''courseid'''
| int(10)
|
| foreign key, references course.id
|-
| sortorder
| int(10)
|
| order of instances in course
|-
| name
| char(255)
|
| optional plugin instance name, useful when multiple instances of the same plugin used in course
|-
| enrolperiod
| int(10)
| 0
| optional default enrolment period, in seconds
|-
| enrolstartdate
| int(10)
| 0
| timestamp, optional default enrolment start date
|-
| enrolenddate
| int(10)
| 0
| timestamp, optional default enrolment end date
|-
| expirynotify
| int(1)
| 0
| optional flag
|-
| expirythreshold
| int(10)
| 0
| timestamp, optional
|-
| notifyall
| int(1)
| 0
| optional flag
|-
| password
| char(255)
|
| optional enrolment password
|-
| cost
| char(20)
|
| optional cost field
|-
| currency
| char(3)
|
| optional currency field
|-
| roleid
| int(10)
|
| general optional field
|-
| customint1
| int(10)
|
| general optional field
|-
| customint2
| int(10)
|
| general optional field
|-
| customint3
| int(10)
|
| general optional field
|-
| customint4
| int(10)
|
| general optional field
|-
| customchar1
| char(255)
|
| general optional field
|-
| customchar2
| char(255)
|
| general optional field
|-
| customdec1
| decimal
|
| general optional field
|-
| customdec2
| decimal
|
| general optional field
|-
| customtext1
| text
|
| general optional field
|-
| customtext2
| text
|
| general optional field
|-
| timecreated
| int(10)
|
| timestamp, date when instance created
|-
| timemodified
| int(10)
|
| timestamp, date when instance last modified
|}

==Simplified role_assignments table==
No role assignment duration, it could never work for future dates and was not implemented for past dates anyway. The enrol field was renamed to component in order to properly support protected role assignments in auth plugins. The component+itemid is used for protection of each separate enrol instance or auth plugins.

==Simplified course table==
All enrol related info moved into enrol tables. All code that was looking for enrol related info in course table needs to be updated.

=Enrolment plugins=
Enrolment framework is fully pluggable, there should not be any hardcoded dependencies in code any more. Technically you may delete all enrol plugins and only new custom plugins. Plugins may integrate at:
* new admin settings pages
* login process hook - user enrol sync
* two require_login() hooks
* enrol page hoop
* unenrol support hook
* course edit page - plugin settings for each course
* course enrolment methods list - add, remove, hide enrol instances
* course admin navigation hook
* management of enrolled users
* cron script
* etc.

==Manual enrolments==
Implemented in /enrol/manual/*, true manual enrolments.

==Temporary guest access==
Implemented in /enrol/guest/*. This plugin does not use user_enrolments table. The course access is granted inside require_login() call together with a temporary guest role. Access key is optional.

==Self enrolment==
Implemented in /enrol/self/*. Users decide when to enrol. Enrolment key is optional, it can use group enrolment keys too.

==Cohort enrolment==
Implemented in /enrol/cohort/*. Synchronises cohort users with course enrolment, optionally assigns group too. The sync is implemented through event listeners.

==Course meta links==
Implemented in /enrol/meta/*. Replaces old metacourses. The difference is that every course may be child and parent course at the same time. The sync is implemented through event listeners. It is possible to mix meta enrolments with normal enrolments.

==External database==
Implemented in /enrol/database/*. Separate course creation and user synchronisation, more sync options implemented.

==LDAP==
Implemented in /enrol/ldap/*. Includes course creation and user synchronisation, more sync options implemented (e.g., nested groups on Active Directory).

==Authorize==
TODO - luckily we do not need any more hardcoded hooks all over the place ;-)

==Flat file==
TODO

==imsenterprise==
TODO

==PayPal==
TODO - it will be finally possible to set up multiple instances per course, each with different cost&role

==MNET==
TODO - this needs more internal changes in mnet stuff ...

=Upgrade=
The data from role assignments table and course table is used to create all necessary entries in enrol and user_enrolments tables. External sync plugins may need to do a full resync. No data is lost during the upgrade, the data from course table is automatically migrated into enrol table.

=Other changes=
==Course visibility==
Originally making category hidden forced hiding of course category. Now the category hiding affects only browsing of course, not the actual access. When hiding category all courses are hidden automatically. The new approach improves performance and allows some new scenarios such as hide all courses you are not enrolled in.

=See also=
* [[Enrolment usage overview]]
* [[Role archetypes]]
* [[New permissions evaluation in 2.0]]
* [[Obsolete:Enrolment rewrite and role tweaks proposal]]

[[Category:Enrolment]]
[[Category:Roles]]

User talk:Zak Fleming

2009-07-27T23:10:23Z

Iarenaza: New page: Zack, I wonder why you reverted revision 60623 of NTLM_authentication (where I did some formatting fixes). Was there anything wrong with them? ~~~~

Zack,

I wonder why you reverted revision 60623 of NTLM_authentication (where I did some formatting fixes). Was there anything wrong with them?

[[User:Iñaki Arenaza|Iñaki Arenaza]] 23:10, 27 July 2009 (UTC)

Git tips

2009-07-22T20:38:18Z

Iarenaza: Show how to setup a local share repository to work with

{{Work in progress}}

Many developers find git a useful tool to help them with moodle development, here some tips and workflows can be shared to help others.

== Thorough Resolved Bug QA review with git ==

The power of having fast access to all of moodle commit history means we can search and checkout any point in moodle source code history which allows us to powerfully QA a bug.

Please note this workflow might not be ideal for all scenarios (for example if lots of work has been done in the same area since).

Example Workflow to QA MDL-16600:

First checkout a new branch for us to work on testing the bug in MOODLE_19_STABLE. We can delete this branch later, its less dangerous than playing any of our 'live' branches.

<pre>
$ git checkout -b QA-MDL-16600 origin/MOODLE_19_STABLE
Branch QA-MDL-16600 set up to track remote branch refs/remotes/origin/MOODLE_19_STABLE.
Switched to a new branch "QA-MDL-16600"
</pre>

Now search for any commits related to this bug fix:
<pre>
$ git log --grep='MDL-16600'
commit 1c2c8b09469ac27a3829e7267f399356a05b9810
Author: tjhunt <tjhunt>
Date: Fri Sep 26 05:49:06 2008 +0000

MDL-16600 forcedownload broken for file resources.
</pre>

In order to test that these commits fixed the bug, we will revert this commit, and then try to reproduce the reported bug:

<pre>
$ git revert -n 1c2c8b09469ac27a3829e7267f399356a05b9810
</pre>

Once we've reproduced the problem, we will reset our repository back to HEAD:
<pre>
git reset --hard HEAD
</pre>

Now if the bug is fixed, it can be closed and we can delete our branch:
<pre>
git branch -D QA-MDL-16600
</pre>

== Backporting stuff from cvshead to stable git branches ==

I (Penny) have to do this all the time and it sucks. So I made a script to make it suck less.

http://cvs.moodle.org/contrib/tools/devtools/bugstogitformatpatch?view=markup

This little perl script takes a list of bug numbers, and generates patches that you can apply with git-am

I backported Tim's roles UI work and this is how I did it.

<pre>
# make a new branch to work on
$ git checkout -b mdl19-rolesbackport origin/MOODLE_19_STABLE
</pre>

Now create some file that contains a list of bug numbers... In the case that there's only one, you can do:

<pre>
$ echo MDL-xxxxx | bugstogitformatpatch --otherargs
</pre>

Else you can do either of:

<pre>
$ cat myplan | bugstogitformatpatch --otherargs
$ bugstogitformatpatch --grepfile myplan
</pre>

This file could be a whole file with documentation and everything, but the script '''does''' expect the bug numbers to be one per-line (but accepts other junk on the same line) and start with MDL-xxxx

The script has some other options, like where to put the patches it generates, and what the revlog spec should look like (by default it will just do origin/cvshead, but you can restrict it to a different branch or even abcdefg..12345678 if you want, anything git-log can understand - see man git-rev-parse).

See --help for more information.

Now the script will run and actually much faster than I expected, for Moodle's entire history. It will spit out git-format-patch formatted patches, which you can then happily apply with git-am.

TIP: For a large feature that goes into HEAD, it may happen that someone commits bugfixes to HEAD after you've backported it, which you'll then subsequently want to apply. To get around this, I did...

<pre>
$ git tag rolesbackportedtohead origin/cvshead
</pre>

After I was done... then the next time I wanted to run the script, I just used --revlist rolesbackportedtohere..origin/cvshead to only look at patches after the last time.

== Local collaboration ==
You want to do this...

* git.moodle.org
** my organisation's git repository: aka shared repo (pulled from git.moodle.org)
*** developer 1 (local git)
*** developer 3 (local git)
*** etc.

You want to collaboratively develop Moodle stuff pushing and pulling from your local shared repository. On top of that you want the upstream repository itself to pull updates from the upstream git.moodle.org.

Some names used in the examples:

* devel-1: the first developer
* devel-2: the second developer
* shared-repo: the name of the shared repository directory
* git-moodle: the name of the unix group needed to use the shared repository

Some assuptions for the examples:

* Linux/Unix environment
* All the repositories are on the same machine (if not, only need to change git transports from git:// to git+ssh://, etc.)

Devel-1: Create local repo and configure working environment:

<pre>
cd /path/to/devel-1/dir
mkdir devel-1.git
cd devel-1.git
git init
git config --global user.name 'Devel-1 Real Name'
git config --global user.email 'devel-1@email.address'
git config --global i18n.commitEncoding 'utf8'
git config --global i18n.logOutputEncoding 'utf8'
</pre>

Get branches from git.moodle.org repo:

<pre>
git remote add -t cvshead -t MOODLE_19_STABLE -t MOODLE_18_STABLE -m cvshead moodleorg git://git.moodle.org/moodle.git
git fetch moodleorg
</pre>

Create local (work) branches:

<pre>
git branch --track cvshead-devel-1 moodleorg/cvshead
git branch --track mdl19-devel-1 moodleorg/MOODLE_19_STABLE
git branch --track mdl18-devel-1 moodleorg/MOODLE_18_STABLE
</pre>

Create local shared repo and configure it:

<pre>
cd /path/to/shared-repo/dir
mkdir shared-repo.git
cd shared-repo.git
git --bare init --shared=all
chmod g=rwxs,o=rx . # Give appropiate permissions to users in
sudo chgrp -R git-moodle . # group 'git-moodle'.
</pre>

Populate shared repo from local devel-1 repo:

<pre>
cd /path/to/devel-1/dir/devel-1.git
git remote add shared-repo /path/to/shared-repo/dir/shared-repo.git
git push shared-repo +cvshead-devel-1: +mdl19-devel-1: +mdl18-devel-1:
</pre>

Configure Devel-1 local repo branches to merge the right remote branch when pulling. We need to do this only for the first developer, as the shared repo didn't exist when we created the branches.

<pre>
cd /path/to/devel-1/dir/devel-1.git
git config branch.cvshead-devel-1.remote shared-repo
git config branch.cvshead-devel-1.merge refs/heads/cvshead-devel-1
git config branch.mdl19-devel-1.remote shared-repo
git config branch.mdl19-devel-1.merge refs/heads/mdl19-devel-1
git config branch.mdl18-devel-1.remote shared-repo
git config branch.mdl18-devel-1.merge refs/heads/mdl18-devel-1
</pre>

Create Devel-2 local repo and configure working environment:

<pre>
cd /path/to/devel-2/dir
git clone -o shared-repo /path/to/shared-repo/dir/shared-repo.git devel-2.git
cd devel-2.git
git config --global user.name 'Devel-2 Real Name'
git config --global user.email 'devel-2@email.address'
git config --global i18n.commitEncoding 'utf8'
git config --global i18n.logOutputEncoding 'utf8'
</pre>

Get branches from git.moodle.org repo:

<pre>
cd devel-2.git
git remote add -t cvshead -t MOODLE_19_STABLE -t MOODLE_18_STABLE -m cvshead moodleorg git://git.moodle.org/moodle.git
git fetch moodleorg
</pre>

Create local (work) branches from moodle.org:

<pre>
git branch --track cvshead-devel-2 moodleorg/cvshead
git branch --track mdl19-devel-2 moodleorg/MOODLE_19_STABLE
git branch --track mdl18-devel-2 moodleorg/MOODLE_18_STABLE
</pre>

From the shared-repo:

<pre>
git branch --track cvshead-devel-1 shared-repo/cvshead-devel-1
git branch --track mdl19-devel-1 shared-repo/mdl19-devel-1
git branch --track mdl18-devel-1 shared-repo/mdl18-devel-1
</pre>

Configure local branches to merge the right remote branch when pulling:

<pre>
Nothing to do :-)
</pre>

Now you can pull and push from any of the configured remote repositories (git.moodle.org and your shared local repo) by specifiying the remote repository name when using 'git pull' or 'git push'

== More tips please ==
(Please add your own tips here!)

==See Also==
* [[Using GIT to backup moodledata]]
* [http://moodle.org/mod/forum/discuss.php?d=119016 Moodle Development with git]
* [http://moodle.org/mod/forum/discuss.php?d=124570 Local collaboration and Git - Yeah another git question!!]

[[Category:Git tips]]
[[Category:Developer tools|Git]]

Git tips

2009-06-02T22:18:05Z

Iarenaza: Another interesting thread

How to apply a patch

2009-03-09T23:57:59Z

Iarenaza: Add a note about not putting patch.exe in directories with white space in their path

==Introduction==
This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

Perhaps most critical is the usage of the -p flag, which tells patch about the relationship between the directory where the patch file is located and the files that will be patched. See the references below for details and DO NOT assume anything.

==Apply a Patch in Windows using [http://gnuwin32.sourceforge.net/packages/patch.htm gnuwin32]==

* Download and extract patch for windows from [http://gnuwin32.sourceforge.net/packages/patch.htm sourceforge] I placed the patch.exe binary in C:\bin (NOTE: Things are a lot easier if you put it in a directory that doesn't have white spaces in it.)

* Download and extract Moodle somewhere. eg: C:\moodle

* Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

* Open the patch file with Wordpad, and click 'File' >> 'Save as...', choose a different name for the file eg ('mynewpatch.diff') and "Save as type" >> 'Text Document - MS-DOS Format'

* Open up a command text window, and type:

cd \moodle
c:\bin\patch.exe --dry-run -p1 < mynewpatch.diff

:The number after <tt>'-p'</tt> option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the [http://www.rt.com/man/patch.1.html 'patch' utility manual page ] to see how the <tt>'-p'</tt> option works. You could also have a look at this [http://www.linuxtutorialblog.com/post/introduction-using-diff-and-patch-tutorial diff and patch tutorial].
* You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

patching file admin/settings/security.php
patching file lang/en_utf8/admin.php
patching file lib/moodlelib.php
patching file login/change_password.php
patching file login/signup.php
patching file user/edit.php
Hunk #1 succeeded at 430 (offset 2 lines).

:At this stage the patch <b>has not been applied</b>. We just simulated the application (with the <tt>'--dry-run'</tt> option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

===Potential problems and how to deal with them===
====Potential problems====
If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the 'patch' command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

* If you get any <tt>'Hunk #n succeeded...'</tt> messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the 'patch' command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension <tt>.orig</tt>.

* If you get any <tt>'Hunk #n failed...'</tt> messages, the patch would have not applied correctly. In this case the 'patch' command would have created two additional files for each of the files where the hunk was not applied correctly, called:
** <tt>original-file-name.orig</tt>    This would be the original file before the patch was applied, just like above.
** <tt>original-file-name.rej </tt>    This file would contain the hunks that could not be applied correctly, so you could inspect them.

====Dealing with potential problems====
Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you <b>should not apply</b> the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the <tt>'-b'</tt> option. That option automatically makes a backup of every file the patch applies to, with the <tt>.orig</tt> extension. That would allow you go back to the original files state by simply overwritting the modified files with their <tt>.orig</tt> backups.

Sometimes, there will be a large difference in line numbers since a patch was generated and the patch will not apply. You can tell patch allow larger differences in line numbers by using the fuzz option '-F' to increase the number of lines difference there can be. For example patch -F 100 would allow 100 lines difference.

===Actually applying the patch===
Now that we know what could go wrong and how to deal with it, let's see how to apply the patch. We only need to remove the <tt>'--dry-run'</tt>:

cd \moodle
c:\bin\patch.exe -p1 < mynewpatch.diff

and optionally use the <tt>'-b'</tt> option if we are going to try to fix the failed hunks by hand:

cd \moodle
c:\bin\patch.exe -b -p1 < mynewpatch.diff

==Apply a Patch in Linux using "patch"==
use something like:
patch -p1 < patchfile.diff
see [http://linux.about.com/od/commands/l/blcmdl1_patch.htm here] for more details on using Patch in Linux

==See Also==

* [[Patch]]
* [[How_to_create_a_patch]]
* [http://drupal.org/node/32875 Drupal - using Cygwin in Windows to apply a patch]
* [http://drupal.org/node/60818 Drupal - how to apply a patch in Mac OS X]
* [http://moodle.org/mod/forum/discuss.php?d=61379#p286372 moodle post - using gnuwin32 to apply a patch]

[[Category:Tutorial]]

[[es:Como_aplicar_un_parche]]

How to apply a patch

2008-12-30T22:12:25Z

Iarenaza: Spanish translation

==Introduction==
This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

Perhaps most critical is the usage of the -p flag, which tells patch about the relationship between the directory where the patch file is located and the files that will be patched. See the references below for details and DO NOT assume anything.

==Apply a Patch in Windows using [http://gnuwin32.sourceforge.net/packages/patch.htm gnuwin32]==

* Download and extract patch for windows from [http://gnuwin32.sourceforge.net/packages/patch.htm sourceforge] I placed the patch.exe binary in C:\bin

* Download and extract Moodle somewhere. eg: C:\moodle

* Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

* Open the patch file with Wordpad, and click 'File' >> 'Save as...', choose a different name for the file eg ('mynewpatch.diff') and "Save as type" >> 'Text Document - MS-DOS Format'

* Open up a command text window, and type:

cd \moodle
c:\bin\patch.exe --dry-run -p1 < mynewpatch.diff

:The number after <tt>'-p'</tt> option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the [http://www.rt.com/man/patch.1.html 'patch' utility manual page ] to see how the <tt>'-p'</tt> option works. You could also have a look at this [http://www.linuxtutorialblog.com/post/introduction-using-diff-and-patch-tutorial diff and patch tutorial].
* You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

patching file admin/settings/security.php
patching file lang/en_utf8/admin.php
patching file lib/moodlelib.php
patching file login/change_password.php
patching file login/signup.php
patching file user/edit.php
Hunk #1 succeeded at 430 (offset 2 lines).

:At this stage the patch <b>has not been applied</b>. We just simulated the application (with the <tt>'--dry-run'</tt> option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

===Potential problems and how to deal with them===
====Potential problems====
If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the 'patch' command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

* If you get any <tt>'Hunk #n succeeded...'</tt> messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the 'patch' command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension <tt>.orig</tt>.

* If you get any <tt>'Hunk #n failed...'</tt> messages, the patch would have not applied correctly. In this case the 'patch' command would have created two additional files for each of the files where the hunk was not applied correctly, called:
** <tt>original-file-name.orig</tt>    This would be the original file before the patch was applied, just like above.
** <tt>original-file-name.rej </tt>    This file would contain the hunks that could not be applied correctly, so you could inspect them.

====Dealing with potential problems====
Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you <b>should not apply</b> the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the <tt>'-b'</tt> option. That option automatically makes a backup of every file the patch applies to, with the <tt>.orig</tt> extension. That would allow you go back to the original files state by simply overwritting the modified files with their <tt>.orig</tt> backups.

Sometimes, there will be a large difference in line numbers since a patch was generated and the patch will not apply. You can tell patch allow larger differences in line numbers by using the fuzz option '-F' to increase the number of lines difference there can be. For example patch -F 100 would allow 100 lines difference.

===Actually applying the patch===
Now that we know what could go wrong and how to deal with it, let's see how to apply the patch. We only need to remove the <tt>'--dry-run'</tt>:

cd \moodle
c:\bin\patch.exe -p1 < mynewpatch.diff

and optionally use the <tt>'-b'</tt> option if we are going to try to fix the failed hunks by hand:

cd \moodle
c:\bin\patch.exe -b -p1 < mynewpatch.diff

==Apply a Patch in Linux using "patch"==
use something like:
patch -p1 < patchfile.diff
see [http://linux.about.com/od/commands/l/blcmdl1_patch.htm here] for more details on using Patch in Linux

==See Also==

* [[Patch]]
* [[How_to_create_a_patch]]
* [http://drupal.org/node/32875 Drupal - using Cygwin in Windows to apply a patch]
* [http://drupal.org/node/60818 Drupal - how to apply a patch in Mac OS X]
* [http://moodle.org/mod/forum/discuss.php?d=61379#p286372 moodle post - using gnuwin32 to apply a patch]

[[es:Como_aplicar_un_parche]]

How to apply a patch

2008-08-28T15:45:51Z

Iarenaza: Added section on potential problems and how to deal with them

==Introduction==
This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

==Apply a Patch in Windows using [http://gnuwin32.sourceforge.net/packages/patch.htm gnuwin32]==

* Download and extract patch for windows from [http://gnuwin32.sourceforge.net/packages/patch.htm sourceforge] I placed the patch.exe binary in C:\bin

* Download and extract Moodle somewhere. eg: C:\moodle

* Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

* Open the patch file with Wordpad, and click 'File' >> 'Save as...', choose a different name for the file eg ('mynewpatch.diff') and "Save as type" >> 'Text Document - MS-DOS Format'

* Open up a command text window, and type:

cd \moodle
c:\bin\patch.exe --dry-run -p1 < mynewpatch.diff

:The number after <tt>'-p'</tt> option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the [http://www.rt.com/man/patch.1.html 'patch' utility manual page ] to see how the <tt>'-p'</tt> option works. You could also have a look at this [http://www.linuxtutorialblog.com/post/introduction-using-diff-and-patch-tutorial diff and patch tutorial].
* You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

patching file admin/settings/security.php
patching file lang/en_utf8/admin.php
patching file lib/moodlelib.php
patching file login/change_password.php
patching file login/signup.php
patching file user/edit.php
Hunk #1 succeeded at 430 (offset 2 lines).

:At this stage the patch <b>has not been applied</b>. We just simulated the application (with the <tt>'--dry-run'</tt> option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

===Potential problems and how to deal with them===
====Potential problems====
If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the 'patch' command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

* If you get any <tt>'Hunk #n succeeded...'</tt> messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the 'patch' command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension <tt>.orig</tt>.

* If you get any <tt>'Hunk #n failed...'</tt> messages, the patch would have not applied correctly. In this case the 'patch' command would have created two additional files for each of the files where the hunk was not applied correctly, called:
** <tt>original-file-name.orig</tt>    This would be the original file before the patch was applied, just like above.
** <tt>original-file-name.rej </tt>    This file would contain the hunks that could not be applied correctly, so you could inspect them.

====Dealing with potential problems====
Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you <b>should not apply</b> the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the <tt>'-b'</tt> option. That option automatically makes a backup of every file the patch applies to, with the <tt>.orig</tt> extension. That would allow you go back to the original files state by simply overwritting the modified files with their <tt>.orig</tt> backups.

===Actually applying the patch===
Now that we know what could go wrong and how to deal with it, let's see how to apply the patch. We only need to remove the <tt>'--dry-run'</tt>:

cd \moodle
c:\bin\patch.exe -p1 < mynewpatch.diff

and optionally use the <tt>'-b'</tt> option if we are going to try to fix the failed hunks by hand:

cd \moodle
c:\bin\patch.exe -b -p1 < mynewpatch.diff

==Apply a Patch in Linux using "patch"==
use something like:
patch -p1 < patchfile.diff
see [http://linux.about.com/od/commands/l/blcmdl1_patch.htm here] for more details on using Patch in Linux

==See Also==
* [[How_to_create_a_patch]]
* [http://drupal.org/node/32875 Drupal - using Cygwin in Windows to apply a patch]
* [http://drupal.org/node/60818 Drupal - how to apply a patch in Mac OS X]
* [http://moodle.org/mod/forum/discuss.php?d=61379#p286372 moodle post - using gnuwin32 to apply a patch]

How to create a patch

2008-08-28T14:06:26Z

Iarenaza: Add sensible options (-N, -r) to the diff command

If you have made some changes to the code that you would like to share with the community, particularly if you want to send them to one of the core developers for possible inclusion in Moodle Core, it is very helpful if you can provide them as a patch file. Sometimes also called a diff file.

This page explains how you can make a patch file. Patch is a standard format, and there are many options for how to create one. Pick the one that is easiest for you.

''Note, I have not been able to test most of these instructions. They are about right, but I am hoping that as people use them, they will fill in any gaps, correct any details, and so on.[[User:Tim Hunt|Tim Hunt]] 08:40, 25 June 2007 (CDT)''

==Introduction: what does a patch file look like==

This is a simple example:

<pre><nowiki>
Index: lang/en_utf8/quiz.php
===================================================================
RCS file: /cvsroot/moodle/moodle/lang/en_utf8/quiz.php,v
retrieving revision 1.57.2.10
diff -u -r1.57.2.10 quiz.php
--- lang/en_utf8/quiz.php 29 May 2007 17:47:25 -0000 1.57.2.10
+++ lang/en_utf8/quiz.php 25 Jun 2007 12:58:34 -0000
@@ -252,7 +255,6 @@
$string['indivresp'] = 'Responses of Individuals to Each Item';
$string['info'] = 'Info';
$string['introduction'] = 'Introduction';
-$string['invalidcategory'] = 'Category ID is invalid';
$string['invalidnumericanswer'] = 'One of the answers you entered was not a valid number.';
$string['invalidnumerictolerance'] = 'One of the tolerances you entered was not a valid number.';
$string['invalidsource'] = 'The source is not accepted as valid.';
@@ -375,8 +377,10 @@
$string['questiontypesetupoptions'] = 'Setup options for question types:';
$string['quiz:attempt'] = 'Attempt quizzes';
$string['quiz:deleteattempts'] = 'Delete quiz attempts';
+$string['quiz:emailconfirmsubmission'] = 'Receive own quiz submission notification';
+$string['quiz:emailnotifysubmission'] = 'Receive student quiz submission notifications';
$string['quiz:grade'] = 'Grade quizzes manually';
-$string['quiz:ignoretimelimits'] = 'Ignores time limit on quizzes';
+$string['quiz:ignoretimelimits'] = 'Ignores time limit on quizs';
$string['quiz:manage'] = 'Manage quizzes';
$string['quiz:preview'] = 'Preview quizzes';
$string['quiz:view'] = 'View quiz information';
</nowiki></pre>

At the top it says which file is being affected. Changes to several files can be included in one patch. Lines added are shown with a '+', lines removed are shown with a '-', lines changed are shown as the old line being removed and the new one added.

Patch files are good because they only show the changed parts of the file. This has two advantages: it easy to understand the change; and if other parts of the same files change between the patch being made an being used, there is no problem, the patch will still apply.

==Creating a patch using diff==

diff is the a linux command line program, and is where patch files originated. It requires that you have two copies of the code, one with your changes, and one without. Suppose these two copies are in folders called 'standard_moodle' and 'my_moodle' which are subdirectories of the current folder. Then to create the patch, type:

diff -Naur standard_moodle my_moodle > patch.txt

==Creating a patch using CVS (command line)==

It is easier if you are using CVS to manage your development, because you don't need to keep the copy of 'standard_moodle'. CVS takes care of that for you. In you workspace (sandbox) type:

cvs diff -uN > patch.txt

If you have unversioned files to include in your patch, you will notice that the above command simply adds the file's name to the top of your patch, prefixed with a question mark. This is because your new file is not tagged for adding to the repository. Just do

cvs add newfile

Then

cvs diff -uNa > patch.txt

This should add the correct code to the patch, so that someone applying the patch to their working copy will have a new file created at the right place (hopefully!).

If your patch, for some reason, contains a lot of white space changes in many files, you might want to add -Bbw to the diff call. Make sure these changes are really not significant (like adding or removing a space at the end of a line - editors like Eclipse sometimes do this automatically). This can make a patch a lot smaller, and thus easier to review. The complete call would then be

cvs diff -uNawbB > patch.txt

==Creating a patch using Tortoise CVS==

[http://www.tortoisecvs.org/ Tortoise CVS] is a Windows GUI front end for CVS. To create a patch, right-click on a folder in CVS, and choose '''CVS -> Make patch ...''' from the context menu.

==Creating a patch using Eclipse==

See [[Setting_up_Eclipse#Creating_a_patch]]. Eclipse makes creating patches really easy, once you have got it set up correctly.

==Creating a patch using WinMerge==

[http://winmerge.org/ WinMerge] is a nice windows GUI for comparing folders. In this sense it is like the original command-line 'diff' program. You need a copy of 'standard_moodle' and 'my_moodle'. Use '''File -> Open...''' to open the two versions for comparison. This will give you a nice view of what you have changed. Then do '''Tools -> Generate patch ...'''. In the dialogue box, make sure you select Style: Unified in the Format box.
==See Also==
* [[How_to_apply_a_patch]]

How to apply a patch

2008-08-28T13:56:45Z

Iarenaza: Improve documentation a bit

Coding

2008-01-14T23:56:54Z

Iarenaza: Use escapeshellcmd/escapeshellarg when using shell_exec or other shell related functions.

Any collaborative project needs consistency and stability to stay strong.

These '''coding guidelines''' are to provide a goal for all Moodle code to strive to. It's true that some of the older existing code falls short in a few areas, but it will all be fixed eventually. All new code definitely must adhere to these standards as closely as possible.

==General rules==

# All code files should use the .php extension.
# All template files should use the .html extension.
# All text files should use Unix-style text format (most text editors have this as an option).
# All php tags must be 'full' tags like <?php ?> ... not 'short' tags like <? ?>.
# All existing copyright notices must be retained. You can add your own if necessary.
# Each file should include (require_once) the main config.php file.
# Any other include/require should use an absolute path beginning with $CFG->dirroot or $CFG->libdir, not relative includes, which [http://uk.php.net/manual/en/function.include.php sometimes behave strangely under PHP].
# Each file should check that the user is authenticated correctly, using require_login() and has_capability() or require_capability().
# All access to databases should use the functions in ''lib/dmllib.php'' whenever possible - this allows compatibility across a wide range of databases. You should find that almost anything is possible using these functions. If you must write SQL code then make sure it is: cross-platform; restricted to specific functions within your code (usually a lib.php file); and clearly marked.
# Don't create or use global variables except for the standard $CFG, $SESSION, $THEME, $SITE, $COURSE and $USER.
# All variables should be initialised or at least tested for existence using isset() or empty() before they are used.
# All strings should be translatable - create new texts in the "lang/en_utf8" files with concise English lowercase names and retrieve them from your code using get_string() or print_string(). Never delete strings to ensure backwards compatibility of the language packs is maintained.
# All errors should be printed using print_error() to maximise translation and help for users (it automatically links to the docs wiki).
# All help files should be translatable - create new texts in the "lang/en_utf8/help" directory and call them using helpbutton(). If you need to update a help file:
#* with a minor change, where an old translation of the file would still make sense, then it's OK to make the change but you should notify translation AT moodle DOT org.
#* for a major change you should create a new file by adding an incrementing number (eg filename2.html) so that translators can easily see it's a new version of the file. Obviously the new code and the help index files should also be modified to point to the newest versions.
# Incoming data from the browser (sent via GET or POST) automatically has magic_quotes applied (regardless of the PHP settings) so that you can safely insert it straight into the database. All other raw data (from files, or from databases) must be escaped with addslashes() before inserting it into the database. Because this is so often done incorrectly, there is more explanation on this issue of adding and stripping slashes on a [[Developer:Slashes|separate page]].
# VERY IMPORTANT: All texts within Moodle, especially those that have come from users, should be printed using the format_text() function. This ensures that text is filtered and cleaned correctly. More information can be found on the page about [[Output_functions|output functions]].
# User actions should be logged using the [[Logs|add_to_log()]] function. These logs are used for [[Settings#Show_activity_reports|activity reports]] and [[Logs]].
# When generating a HTML link, always make it relative to the full site root, i.e. link to ''$CFG->wwwroot/mod/blonk/view.php?id=99'' rather than just ''view.php?id=99''. This means that your code will work if called by a script in another folder, among other things.

==Coding style==

I know it can be a little annoying to change your style if you're used to something else, but balance that annoyance against the annoyance of all the people trying later on to make sense of Moodle code with mixed styles. There are obviously many good points for and against any style that people use, but the current style just is, so please stick to it.

1. Indenting should be consistently 4 spaces. Don't use tabs AT ALL.

2. Variable names should always be easy-to-read, meaningful lowercase English words. If you really need more than one word then run them together, but keep them short as possible. Use plural names for arrays of objects.

GOOD: $quiz
GOOD: $errorstring
GOOD: $assignments (for an array of objects)
GOOD: $i (but only in little loops)

BAD: $Quiz
BAD: $aReallyLongVariableNameWithoutAGoodReason
BAD: $error_string

3. Constants should always be in upper case, and always start with the name of the module. They should have words separated by underscores.

define("FORUM_MODE_FLATOLDEST", 1);
4. Function names should be simple English lowercase words, and start with the name of the module to avoid conflicts between modules. Words should be separated by underscores. Parameters should always have sensible defaults if possible. Note there is no space between the function name and the following (brackets).

function forum_set_display_mode($mode=0) {
global $USER, $CFG;

if ($mode) {
$USER->mode = $mode;
} else if (empty($USER->mode)) {
$USER->mode = $CFG->forum_displaymode;
}
}

5. Blocks must always be enclosed in curly braces (even if there is only one line). Moodle uses this style:

if ($quiz->attempts) {
if ($numattempts > $quiz->attempts) {
error($strtoomanyattempts, "view.php?id=$cm->id");
}
}

6. Strings should be defined using single quotes where possible, so that [http://php.net/types.string less memory is used].

$var = 'some text without any variables';
$var = 'with special characters like a new line '."\n";
$var = 'a very, very long string with a '.$single.' variable in it';
$var = 'some '.$text.' with '.$many.' variables '.$within.' it';

7. Comments should be added as much as is practical, to explain the code flow and the purpose of functions and variables.

* Every function (and class) should use the popular [http://www.phpdoc.org/ phpDoc format]. This allows code documentation to be generated automatically.
* Inline comments should use the // style, laid out neatly so that it fits among the code and lines up with it.

/**
* The description should be first, with asterisks laid out exactly
* like this example. If you want to refer to a another function,
* do it like this: {@link clean_param()}. Then, add descriptions
* for each parameter as follows.
*
* @param int $postid The PHP type is followed by the variable name
* @param array $scale The PHP type is followed by the variable name
* @param array $ratings The PHP type is followed by the variable name
* @return mixed
*/
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {
if (!$ratings) {
$ratings = array(); // Initialize the empty array
if ($rates = get_records("forum_ratings", "post", $postid)) {
// Process each rating in turn
foreach ($rates as $rate) {
....etc

8. Space should be used liberally - don't be afraid to spread things out a little to gain some clarity. Generally, there should be one space between brackets and normal statements, but no space between brackets and variables or functions:

foreach ($objects as $key => $thing) {
process($thing);
}

if ($x == $y) {
$a = $b;
} else if ($x == $z) {
$a = $c;
} else {
$a = $d;
}

9. When making a COPY of an object, always use the php5 clone() function (otherwise you may end up with just a reference to the first object). Moodle will make sure this works consistently on php4 too.

BAD: $b = $a;
GOOD: $b = clone($a);

If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead.

==Database structures==

To help you create tables that meet these guidelines, we recommend you use the built in [[XMLDB_defining_an_XML_structure#The_XMLDB_editor|database definition (XMLDB) editor]].

# Every table must have an auto-incrementing id field (INT10) as primary index. (see [[IdColumnReasons]])
# The main table containing instances of each module must have the same name as the module (eg widget) and contain the following minimum fields:
#* id - as described above
#* course - the id of the course that each instance belongs to
#* name - the full name of each instance of the module
# Other tables associated with a module that contain information about 'things' should be named widget_things (note the plural).
# Table and column names should avoid using [[Database reserved words|reserved words in any database]]. Please check them before creation.
# Column names should be always lowercase, simple and short, following the same rules as for variable names.
# Where possible, columns that contain a reference to the id field of another table (eg widget) should be called widgetid. (Note that this convention is newish and not followed in some older tables)
# Boolean fields should be implemented as small integer fields (eg INT4) containing 0 or 1, to allow for later expansion of values if necessary.
# Most tables should have a timemodified field (INT10) which is updated with a current timestamp obtained with the PHP time() function.
# Always define a default value for each field (and make it sensible)
# Each table name should start with the database prefix ($CFG->prefix). In a lot of cases, this is taken care of for you automatically. Also, under Postgres, the name of every index must start with the prefix too.
# In order to guarantee [[XMLDB problems#Table and column aliases - the AS keyword|cross-db compatibility]] follow these simple rules about the use of the '''AS''' keyword (only if you need table/colum aliases, of course):
#* '''Don't use''' the '''AS''' keyword for '''table aliases'''.
#* '''Do use''' the '''AS''' keyword for '''column aliases'''.
# '''Never''' create UNIQUE KEYs (constraints) at all. Instead use UNIQUE INDEXes. In the future, if we decide to add referential integrity to Moodle and we need UNIQUE KEYs they will be used, but not now. Please note that the XMLDB editor allows you to specify both XMLDB-only UNIQUE and FOREIGN constraints (and that's good, in order to have the XML well defined) but only underlying INDEXes will be generated.
# Those XMLDB-only UNIQUE KEYs (read previous point) only must be defined if such field/fields '''are going to be the target''' for some (XMLDB-only too) FOREIGN KEY. Else, create them as simple UNIQUE INDEXes.
# Tables associated '''with one block''' must follow this convention with their names: '''$CFG->prefix + "block_" + name_of_the_block + anything_else'''. For example, assuming that $CFG->prefix is 'mdl_', all the tables for the block "rss_client" must start by 'mdl_block_rss_client' (being possible to add more words at the end, i.e. 'mdl_block_rss_client_anothertable'...). This rule will be 100% enforced with Moodle 2.0, giving time to developers until then. See [http://tracker.moodle.org/browse/MDL-6786 Task 6786] for more info about this.
# '''Never''' make database changes in the STABLE branches. If we did, then users upgrading from one stable version to the next would have duplicate changes occurring, which may cause serious errors.
# When refering to integer variable in SQL queries, do not surround the value in quotes. For example, get_records_select('question', "category=$catid") is right. get_records_select('question', "category='$catid'") is wrong. It hides bugs where $catid is undefined. ([http://moodle.org/mod/forum/discuss.php?d=80629 This thread explains].)

==Security issues (and handling form and URL data)==

# Do not rely on 'register_globals'. Every variable must be properly initialised in every code file. It must be obvious where the variable came from.
# Initialise all arrays and objects, even if empty. $a = array() or $obj = new stdClass();.
# Do not use the optional_variable() function (this function is now deprecated). Use the optional_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Do not use the require_variable() function (this function is now deprecated). Use the required_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Use data_submitted(), with care. Data must still be cleaned before use.
# Do not use $_GET, $_POST or $_REQUEST. Use the appropriate required_param() or optional_param() appropriate to your need.
# Do not check for an action using something like if (isset($_GET['something'])). Use, e.g., $something = optional_param( 'something',-1,PARAM_INT ) and then perform proper test for it being in its expected range of values e.g., if ($something>=0) {....
# Wherever possible group all your required_param(), optional_param() and other variables initialisation at the beginning of each file to make them easy to find.
# Use 'sesskey' mechanism to protect form handling routines from attack. Basic example of use: when form is generated, include <input type="hidden" name="sesskey" value="<?php echo sesskey(); ?>" />. When you process the form check with if (!confirm_sesskey()) {error('Bad Session Key');}.
# All filenames must be 'cleaned' using the clean_filename() function, if this has not been done already by appropriate use of required_param() or optional_param()
# Any data read from the database must have [[Developer:Slashes|addslashes()]] applied to it before it can be written back. A whole object of data can be hit at once with addslashes_object().
# Wherever possible, data to be stored in the database must come from POST data (from a form with method="POST") as opposed to GET data (ie, data from the URL line).
# Do not use data from $_SERVER if you can avoid it. This has portability issues.
# If it hasn't been done somewhere else, make sure all data written to the database has been through the clean_param() function using the appropriate PARAM_XXXX for the datatype.
# If you write custom SQL code, make very sure it is correct. In particular watch out for missing quotes around values. Possible SQL 'injection' exploit.
# Check all data (particularly that written to the database) in every file it is used. Do not expect or rely on it being done somewhere else.
# Blocks of code to be included should contain a definite PHP structure (e.g, a class declaration, function definition(s) etc.) - straight blocks of code promote uninitialised variable usage.
# If you need to use shell_exec() (or any other shell invoking function), make sure you clean parameters first with escapeshellcmd()/escapeshellarg (otherwise, we open up for shell injection attacks).

[[Category:Coding]]

[[es:Manual de Estilo de Código]]
[[ja:コーディング]]
[[zh:代码指南]]
[[pl:Kodowanie]]

Setting up Eclipse

2007-05-04T23:17:02Z

Iarenaza: Updated the host to use for anonymous CVS access, to use one of the mirrors.

[http://www.eclipse.org/ Eclipse] is an IDE originally designed for Java, but now with plugins for many languages including PHP. It has lots of very powerful features, and it is the editor that some Moodle developers like to use. Other (more) popular choices are vim and emacs.

However, Eclipse is not the easiest program in the world to get started with, so I'm going to take you through it step by step. These instructions assume Eclipse 3.2, the current version at the time of writing. It should not change much between releases.

This article started off as a brain-dump by [[User:Tim Hunt|Tim Hunt]]. Since then, several other people have worked through it and made corrections, so the information here should be pretty accurate.

==Prerequisites==

Eclipse is written in Java, so I recommend getting the latest Java runtime environment from http://java.com/ for maximum speed and reliability.

Eclipse is quite big, so I recommend lots of memory in your computer. I have used it on Windows, MacOS X and Linux, in each case with 1GB of memory, and that is plenty.

==Installing Eclipse==

Go to http://www.eclipse.org/downloads/. Click on the link where it says '''Download now: Eclipse SDK 3.2''' It should have automatically detected which platform you are using. Choose a Mirror, and wait for the ~100MB download.

You will notice that what you have got is a zip file (unless your system automatically decompresses it for you).

On Windows, unzip it into '''C:\Program Files''' (all the files go into an '''Eclipse''' folder there). Then look in the Eclipse folder and drag Eclipse.exe to the Start menu/Desktop/Quicklaunch bar to make a shortcut for starting it.

On MacOS, unzip and copy the Eclipse folder into Applications. Go into the Eclipse folder and drag the Eclipse app to the Dock for ease of launching.

On Linux, unzip somewhere suitable, and make an easy way to launch it.

==The first time you run Eclipse==

The first time you launch Eclipse it does a bit of setup stuff, for instance, it create a '''workspace'''. This is where it stores the things you are working on. The default location is sensible on all platforms, so use that.

For some reason, every time you start Eclipse, it asks you which workspace you want to use. I have never seen the need to have more than one, so I recommend turning on the checkbox that says "Don't ask me this again".

Another thing that happens the first time you run Eclipse is that you arrive at a welcome screen. This has links to various bits of help, which you can read if you like, but you probably don't need to if you are following these instructions. So find the button on the welcome page that closes it and gets you to the main Eclipse screen.

==Installing the necessary plugins==

By default, Eclipse comes with the Java tools. For everything else you will need to install some plugins.

If you are sitting behind a web proxy, from the '''Window''' menu choose '''Preferences ...'''. Choose '''Install/Update''' from the tree view on the left, and enter the proxy information in the boxes on the right. If you aren't behind a proxy, ignore this step.

From the '''Help''' menu choose '''Software Updates -> Find and Install'''.

On the first screen of the wizard, make sure that "Search for new features to install" is selected, then click '''Next >'''.

The next screen is a list of upgrade sites to check. You need to add one to the list, so click the '''New Remote Site ...''' Button.

In the pop-up dialog, give the remote site a name like '''PHPeclipse Update Site'''; set the URL to http://phpeclipse.sourceforge.net/update/releases/; then click '''OK'''.

Back in the wizard, turn on just two things in the box "Sites to include in search":
* Your newly created '''Phpeclipse Update Site'''; and
* the one called '''Callisto Discovery Site'''.
Then click '''Finish'''.

It goes off sees what updates are available at those sites. As it does so, it may occasionally pop up a dialog asking you to choose a mirror. Each time, select a sensible one.

Eventually, you get to a new wizard for selecting and installing the updates you want. The ones you want (you may have to search the tree structure) are, '''PHPeclipse''' (from your newly created PHPEclipse Update Site) and all the '''Web Standard Tools (WST)''' (usually under Callisto Discovery Site --> Web and J2EE Development).

Next, and very importantly, you must click the '''Select Required''' button which should resolve dependencies and remove the warning message you are probably worrying about. Then you can click the '''Next >''' button.

Read and agree to all the license agreements. Then click '''Next >'''.

Click '''Finish''', and wait for the plugins to download.

Once the downloads have finished, a warning will pop-up telling you that all the plugins you downloaded are not digitally signed. The Eclipse Foundation build digital signing of plugins into their architecture as a security measure, and then did not sign any of their own plugins! Anyway, click the '''Install All''' button.

Finally, a window will pop up asking you to restart Eclipse. Do so.

==Setting the preferences for Moodle development==

Now go to the '''Window''' menu, and choose '''Preferences ...'''.

The Eclipse preferences are immense, with a tree view on the left, which selects which screen to display on the right. Don't panic, we'll guide you through it.

===General settings===

If you have strong feelings about fonts (I would hate to edit code an anything except Andale Mono), choose '''General -> Appearance -> Colors and Fonts''' from the tree on the left. Then on the right look under '''Basic''' and change '''Text Font'''. All the other editor font settings will inherit from this, so this is probably the only one you have to change.

Under '''General -> Content Types''', select PHP Source File, and add '''*.html''' to the box at the bottom.

Under '''General -> Editors -> File Associations''', if it is not already there, add '''*.php''' to the top box. With '''*.php''' selected in the top box, make sure '''PHP Editor''' is set to default in the bottom box. With '''*.html''' selected in the top box, select '''PHP Editor''' in the bottom box and click the '''Default''' button to change it, because in Moodle, most HTML files actually contain PHP code.

If you use a web proxy, enter the details under '''Internet -> Proxy Settings'''. (Yes, I know you have entered the somewhere else before. Now you have to enter them again here. I don't know why. You just do.)

===PHP Settings===

These are all hidden under the '''PHPeclipse Web Development''' bit of the tree.

Under '''PHPeclipse Web Development -> Browser Preview Defaults''', turn off both checkboxes.

Under '''PHPeclipse Web Development -> PHP''', on the '''Appearance''' tab, set '''Displayed tab width''' to 4.

Under '''PHPeclipse Web Development -> PHP''', on the '''Typing''' tab, turn off all the options except '''Pasting for correct indentation''', '''Insert spaces for tab''' and '''Close PHPdocs and comments''' and '''Remove trailing spaces on editor save'''. It would be nice to turn on more of these options, but most of the rest don't work very well.

Under '''PHPeclipse Web Development -> PHP -> Formatter''', on the '''New Lines''' tab, turn on '''Clear all blank lines'''.

Under '''PHPeclipse Web Development -> PHP -> Formatter''', on the '''Style''' tab, turn off '''Indentation is represented by a tab'''.

Under '''PHPeclipse Web Development -> PHP -> Templates''', I like to define a new template to help with debugging:
;Name
:dump
;Description
:Dump a PHP variable
;Pattern
<pre>echo '<pre>'; //DONOTCOMMIT
print_r(${cursor});
echo '</pre>';</pre>
You can do other useful things with templates too.

There is a really stupid bug. Under '''PHPeclipse Web Development -> Project Defaults''', you would like to add "." to the '''Include Paths''', but you can't using the GUI. You will have to edit one of the Eclipse config files by hand. So
# Note down the path to your Eclipse profile. On Windows it will be something like '''C:/Documents and settings/XXXX/workspace''', and on Unixy systems something like '''~/workspace'''.
# Close Eclipse.
# Open the file '''net.sourceforge.phpeclipse.ui.prefs''' that is in the directory '''(your workspace)/.metadata/.plugins/org.eclipse.core.runtime/.settings''' in a text editor.
# Look for a line in the file that starts '''_php_include_paths=''' If it is not there, add it at the end.
# Change this line to say '''_php_include_paths=.'''
# Run Eclipse again.

===CVS Settings===

These are all hidden under the '''Team''' bit of the tree.

Under '''Team -> CVS -> SSH2 Connection Method''', you can set up a public/private key pair. If you do this, you won't have to keep typing your Sourceforge password when doing CVS operations. See http://sourceforge.net/docs/F02/ for the instructions of what you have to do at the Sourceforge end to make this work. That should make it clear what you have to do in Eclipse.

The rest of the ones in this section are personal preferences, but I recommend them because the default settings are very irritating.

Under '''Team''', set '''Perspectives''' to '''None'''.

Under '''Team -> CVS -> Annotate''' set '''Use Quick Diff annotate mode for local file annotations''' to '''Yes''', and '''Open perspective after a 'Show Annotations' operation''' to '''No'''.

Under '''Team -> CVS -> Label Decorations''', switch to the '''Icon Decorations''' tab and turn on all the settings, and then on the '''Text Decorations''' tab change both '''File Decoration''' and '''Folder Decoration''' to be just '''{name}'''.

===Web and XML settings===

Foreach XXX in CSS, HTML, Javascript, XML:

Under '''Web and XML -> XXX Files ->XXX Source''', choose '''Indent using spaces''' and '''indentation size''' 4.

==Checking out the Moodle code==

From the '''File''' menu, choose '''New -> Project ...''', then click '''Next >'''.

In the wizard that pops up, choose '''CVS -> Projects from CVS''', then click '''Next >'''.

Select '''Create a new repository location''', then click '''Next >'''.

Fill in
<div style="float: right; border: 1px solid orange; padding: 0 1em;">
For anonymous CVS access use
;Host
:XX.cvs.moodle.org
where XX.cvs.moodle.org is one of [[CVS_for_Administrators#CVS_Servers|these mirrors]]
;Repository path
:/cvsroot/moodle
;User
:anonymous
;Password
:(leave blank)
;Connection type
:pserver
</div>
;Host
:moodle.cvs.sourceforge.net
;Repository path
:/cvsroot/moodle
;User
:(your sourceforge username)
;Password
:(if you set up the SSH2 key thing in preferences, leave this blank, otherwise, type in your sourceforge password.)
;Connection type
:extssh
(CVS experts, if you are confused by that last one, know it is an Eclipse-specific thing.) Then click '''Next >'''.

On the next screen of the Wizard, choose '''Use an existing module'''. Wait a moment, then select '''moodle''' from the list. Click '''Next >'''.

On the next screen, make sure the option '''Check out as a project configured using the New Project Wizard''' is selected, then click '''Next >'''.

Click '''Refresh Tags''', then choose the branch you want. For now leave it set to '''HEAD'''.

Click '''Finish'''.

Now you will find yourself back at the start of the '''New Project''' Wizard. This is because of the option you chose three paragraphs ago. This time you should select '''PHP -> PHP Project''', then click '''Next >'''.

Make up a project name. '''moodle''' would be sensible.

Click '''Finish''', and wait while all the moodle files are checked out of CVS.

Once it has finished, it will probably ask you if you want to switch to the PHP perspective. Answer '''Yes'''.

If you also need the 1.6 stable branch, or another branch, repeat all the other steps with a few changes:
* This time you can choose '''Use and existing repository location''' instead of typing all the sourceforge CVS details again.
* Select the appropriate branch.
* Use a different project name.

==Let your development web server know where your files are==

Either by editing you web server's config files, or using a symbolic link. Make sure your webserver can see your new working set of files at a sensible URL, so you can test the code you are working on.

==Quick tour of some cool features, and remaining configuration changes==

I find the default workbench setup is pretty good. Here is a quick guide to some of the bits.

===Navigator===

To the left is the '''Navigator'''. This is a tree view of all your files. If you double-click on a file, it opens in the editor in the middle. Try opening '''course/lib.php''' now. You will notice that it comes up nicely syntax-hightlighted.

===Error highlighting===

In the middle of the file, just type any old text, for example "I like Eclipse". Obviously, this is not valid PHP syntax, and Eclipse will notice this, and put a red underline under it. Also, by the scrollbar is a ruler with a red mark in it to show the error.

You will see some yellow marks lower down the ruler. There are warnings. Click on one, and you will be taked to where that warning is in the file. Hover your mouse over the warning, and you will get a tooltip explaining what the problem might be.

Save the edited file. (Don't worry that it is broken, we'll clean up the mess later.) Notice that a red error marker is added to the file in the navigator, so you can see that there is a problem. Also, error markers are added to the course folder, and the whole project, so you could see there was an error even if the navigator tree was collapsed.

You will probably find lots of warnings that the config.php file can't be found. In the navigator, find the file '''config-dist.php'''. Do '''Copy''' then '''Paste''' and choose to call the new file '''config.php'''. Edit this new config.php as normal. You should fine that most of the include file warnings have gone now.

Notice also that there is another marker on each file icon. A little yellow cylinder on most files, but a white-on-brown star on the one you have edited. This is telling you the CVS status of each file. The brown stars are changes you have made but not checked in yet.

===Outline===

Over to the right is the Outline view. This shows a list of functions and classes defined in this file. By default, they are listed in the same order as in the file, but if you click on the '''az''' toolbar button, they are sorted into alphabetical order.

Click on the function name '''add_course_module''' in the Outline. You will see that the editor scrolls to the definition of that function.

===Code navigation===

In that function, hover the mouse pointer over the function name '''insert_record'''. After a while, the documentation for that function will appear in a big tooltip.

Hold down CTRL, move the mouse pointer over the function name '''insert_record''', then click. Eclipse should load '''dmllib.php''', and scroll you to where this function is defined.

In the main Eclipse toolbar, there are forward and back arrows like in a web browser. Click back now to get back to '''course/lib.php'''.

===Open resource===

From the '''Navigate''' menu, choose '''Open Resource...'''. In the dialog that pops up, start typing a filename for instance type '''moodlel'''. In the box in the middle of the dialog, you will see it list all the files in the project whose names start that way. At the bottom is a box which lists the different folders that contain a file with that name. This can be a very quick way of opening files with fairly unique names like moodlelib.php, without having to click through the levels of the navigator tree. Of course, it is not so useful for an index.php file! Click OK now to open moodlelib.php. (It would actually work if you just did CTRL + Shift + R, moodlel, Enter.)

===Multi-file search===

Scroll down moodlelib a little bit, and double click on the name of the constant '''MOODLE_INTERNAL''' where it is defined, so that the text is selected. Then, from the '''Search''' menu, choose '''Search...'''. Notice that the '''Containing text''' box has already been filled in for you with the text you just selected. Of course you can just type text into this box without selecting it first. Notice that you can do regular expression searches, but leave that turned off for now. In the '''File name patterns''' box type '''*.css, *.html, *.inc, *.js, *.php, *.xml'''. (This is the most useful general setting for working on moodle. Eclipse will remember this setting, so you only have to enter it once.) Click '''Search'''.

The search results will appear in a new view underneath the editor. That view has a toolbar with yellow up and down arrows. Click the down arrow a few times and it will take you to the first few matches in the code, opening the relevant files as necessary.

===Synchronize view===

I think this is my favorite feature. From the '''Window''' menu, select '''Show View -> Other...'''. In the dialog that pops up, select '''Team -> Synchronize''', then click '''OK'''.

This opens the Synchronize view below the editor. The view has a toolbar. Click on the first toolbar button, which pops up the Synchronize wizard.

On the first screen, there will probably only be one option: '''CVS'''. Make sure that is selected, then click '''Next >'''.

Under '''Scope''', choose '''Workspace''', then click '''Finish'''.

Wait while it talks to the CVS server. After a while, you will see that the Synchronize view lists course/lib.php, and something called '''.project.... That is, it is listing just the files you have edited, but not checked in yet.

'''.project''' is something that belongs to Eclipse that we don't care about. So select it and bring up the context menu, and choose '''Add to .cvsignore...'''. In the dialog that pops up, choose the top option, then click '''OK'''. Then you will find the Synchronize view shows you a '''.cvsignore''' file that you aren't interested in, so add that to .cvsignore too!

If you double-click on '''course/lib.php''' here, you will see that it opens the compare editor, which is a nice graphical display of the changes in this file.

If you select a file or files here, then bring up the context menu, you will see the option to '''Commit...''' the changes. (But don't do that now!). This is the easiest way to commit things in Eclipse.

However, our changes were rubbish, so we want to undo them. So open the context menu again, and choose '''Override and Update'''. This checks a clean copy of the file out of CVS, removing our changes.

Note that the easiest way to do an ordinary CVS Update is to select the top-level project-folder in the Navigator view on the left, open the context menu, and choose '''Team -> Update'''.

That's all the really important features. I sure you can learn everything else on your own. An you could always read the built in help!

===Creating a patch===

In the synchronise view, right click on an item (file or folder) and choose '''Create Patch...'''. Or in the navigator, right click on an item and choose '''Team -> Create Patch...'''.

This brings up a two-page wizard. On the first page you can select where you want the patch made. For small patches it can be useful to create them on the clipboard, but normally you will want to save them in a file.

On the second page, you can set some options, but normally you don't need to change the defaults which are '''Unified''' diff format, and Patch root set to '''Workspace'''. Well, sometimes it is helpful to change the second one to '''Project''' but it is not important.

There is a corresponding apply patch wizard that you can use to apply a patch to a project.

==Related Links==

There is an excellent series of articles published by IBM on using Eclipse for Drupal developement here : [http://www-128.ibm.com/developerworks/ibm/osource/index.html Using open source software to design, develop, and deploy a collaborative Web site Tools and techniques for getting relatively complicated Web sites up and running quickly].

Multi authentication

2006-11-22T13:56:29Z

Iarenaza:

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples authentication instances (instances for short) of the same source type (LDAP, database, etc)
* Each instance has its own configuration
* The order in which we try the instances is configurable

=== How it works ===

* Each source (and thus each instance) has at least the auth_user_login function, like now. (this may change to class function user_login() once Jonathan Harker and Martin Langhoff work in multi-authentication is merged).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each instance in the configured order.
* For each instance, we call auth_user_login() (or user_login()) with the user credentials, and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the instances returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql syntax omitted for shortness)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`isinternal` tinyint(1) NOT NULL default '0',
`multiple` tinyint(1) NOT NULL default '1',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types (sources) present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'manual', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'isinternal' if this auth type is internal to Moodle (1) or not(0), i.e., if it doesn't depend on any external entity to provide authentication. Tipically this is for 'manual', 'email' and 'none'.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'manual', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'manual' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'manual' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0',
`enabled` tinyint(1) NOT NULL default '1',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to use each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.
* 'enabled': if this instance is enabled (1) or not (0).

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

'''ANSWER TO BIG QUESTION''': After talking with Martin Langhoff at MoodleMoot Spain '06, this is clearly a Bad(tm) thing. If we allow users to "float" between authentication instances, things like auth_ldap_sync_users.php could break havoc, deleting users it doesn't know about in this auth_instance (but perfectly valid in other auth_instance's). So storing the auth_instance 'id' in prefix_user and using it accordingly is The Right Thing(tm).

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Multiple instances login: If we use multiple Moodle instances, from my point it means that a user can have access to several instances. So it will be a good idea to think about a kind of Moodle portal that shows all the instances a user can access.
#:: I hadn't thought about this when posting the original questions, because I was thinking about one Moodle site and multiple authentication sources (our problem at the moment), but with [[Community_hub|Moodle Network]] around the corner, this is a real issue. Well thought out Hélène :-) -- [[User:Iñaki Arenaza|Iñaki Arenaza]] 07:56, 22 November 2006 (CST)
# Others?

[[Category:Future]]

Multi authentication

2006-09-30T21:24:19Z

Iarenaza: By default, all authentication types can have multiple instances.

Multi authentication

2006-09-28T21:04:22Z

Iarenaza: Minor corrections and 'enabled' field addition to prefix_auth_instance

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples authentication instances (instances for short) of the same source type (LDAP, database, etc)
* Each instance has its own configuration
* The order in which we try the instances is configurable

=== How it works ===

* Each source (and thus each instance) has at least the auth_user_login function, like now. (this may change to class function user_login() once Jonathan Harker and Martin Langhoff work in multi-authentication is merged).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each instance in the configured order.
* For each instance, we call auth_user_login() (or user_login()) with the user credentials, and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the instances returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql syntax omitted for shortness)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`isinternal` tinyint(1) NOT NULL default '0',
`multiple` tinyint(1) NOT NULL default '0',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types (sources) present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'manual', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'isinternal' if this auth type is internal to Moodle (1) or not(0), i.e., if it doesn't depend on any external entity to provide authentication. Tipically this is for 'manual', 'email' and 'none'.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'manual', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'manual' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'manual' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0',
`enabled` tinyint(1) NOT NULL default '1',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to use each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.
* 'enabled': if this instance is enabled (1) or not (0).

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

'''ANSWER TO BIG QUESTION''': After talking with Martin Langhoff at MoodleMoot Spain '06, this is clearly a Bad(tm) thing. If we allow users to "float" between authentication instances, things like auth_ldap_sync_users.php could break havoc, deleting users it doesn't know about in this auth_instance (but perfectly valid in other auth_instance's). So storing the auth_instance 'id' in prefix_user and using it accordingly is The Right Thing(tm).

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Others?

[[Category:Future]]

Multi authentication

2006-09-20T21:00:14Z

Iarenaza: Don't allow users to "float" between auth instances

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples sources of the same type (LDAP, database, etc)
* Each source has its own configuration
* The order in which we try the sources is configurable

=== How it works ===

* Each source has at least the auth_user_login function (like now).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each source in the configured order.
* For each order, we call auth_user_login with the user credentials and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the sources returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql gurus please adjust definition ;-)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`isinternal` tinyint(1) NOT NULL default '0',
`multiple` tinyint(1) NOT NULL default '0',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'internal', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'isinternal' if this auth type is internal to Moodle (1) or not(0), i.e., if it doesn't depend on any external entity to provide authentication. Tipically this is for 'manual', 'email' and 'none'.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'internal', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'internal' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'internal' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0'
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to user each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

'''ANSWER TO BIG QUESTION''': After talking with Martin Langhoff at MoodleMoot Spain '06, this is clearly a Bad(tm) thing. If we allow users to "float" between authentication instances, things like auth_ldap_sync_users.php could break havoc, deleting users it doesn't know about in this auth_instance (but perfectly valid in other auth_instance's). So storing the auth_instance 'id' in prefix_user and using it accordingly is The Right Thing(tm).

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Others?

[[Category:Future]]

UK MoodleMoot 06 hackfest

2006-07-07T10:20:50Z

Iarenaza: /* Performance profiling */

Monday 24th July, 2006

''Welcommen zum Hackfest'' (OK - I've been watching too much WorldCup on TV).

The first MoodleMoot hackfest is nearly upon us... and we don't have an agenda!

This is an open source agenda for the hackfest. We'll have a day before the Moot to geek out on some code, maybe develop a feature or two, fix some bugs and generally make our favorite learning system a happier place. But I leave it up to you to tell me exactly what we should do. We have four or five rooms with internet connections, a few projectors, and I'll try to get pizza.

Let's start by brainstorming some ideas here for a few days. If someone posts something you're interested in, put your name under it as a vote. The top votes become our central organizing ideas. For example

==1 Bug fixing==

Let's spend a few hours and hunt down as many outstanding bugs in 1.6 as possible. Bounties for most bugs killed, trickiest bug killed, and most unusual bug killed.

''I'm Interested:''
# Jason Cole
# skodak
# martin langhoff (auth & enrolment specifically).
# Martin Dougiamas

(iarenaza) I won't be there, but here are a couple of bugs for Martin L., related to auth: #4648 and #5373. Very easy to fix :-)

==2 What next for the quiz module?==

If any other quizzy people are there, we should have a talk about where we see the quiz module going.

I/the OU have the following priorities:

# Make question type plugins really plug-in-able. At the moment there are some limitations:
#* All the lang strings are still in lang/en_utf8/quiz.php.
#* qtype plugins cannot easily feed CSS and Javascript into the page.
#* pluggable qtypes and pluggable inport/export filters don't play nicely together.
# Write some new question types.
# Make some improvements to existing question types.
# Get RQP working again, so our in-house question engine can talk to Moodle.

''I'm Interested:''
# Tim Hunt

==Performance profiling==

Pick a (memory|database) hog and put it on a diet.

''I'm interested''

# martin langhoff

(iarenaza) Once again, I won't be there, but here's an unfixed bug in 1.6.x and HEAD (was fixed in 1.5.x, but not applied to HEAD at the moment): bug #4591

==Add your suggestion here ...==

Go on, you know you want to.

==See also==
* [http://moodlemoot.org/ http://moodlemoot.org/]

UK MoodleMoot 06 hackfest

2006-07-07T10:18:51Z

Iarenaza: /* 1 Bug fixing */

Monday 24th July, 2006

''Welcommen zum Hackfest'' (OK - I've been watching too much WorldCup on TV).

The first MoodleMoot hackfest is nearly upon us... and we don't have an agenda!

This is an open source agenda for the hackfest. We'll have a day before the Moot to geek out on some code, maybe develop a feature or two, fix some bugs and generally make our favorite learning system a happier place. But I leave it up to you to tell me exactly what we should do. We have four or five rooms with internet connections, a few projectors, and I'll try to get pizza.

Let's start by brainstorming some ideas here for a few days. If someone posts something you're interested in, put your name under it as a vote. The top votes become our central organizing ideas. For example

==1 Bug fixing==

Let's spend a few hours and hunt down as many outstanding bugs in 1.6 as possible. Bounties for most bugs killed, trickiest bug killed, and most unusual bug killed.

''I'm Interested:''
# Jason Cole
# skodak
# martin langhoff (auth & enrolment specifically).
# Martin Dougiamas

(iarenaza) I won't be there, but here are a couple of bugs for Martin L., related to auth: #4648 and #5373. Very easy to fix :-)

==2 What next for the quiz module?==

If any other quizzy people are there, we should have a talk about where we see the quiz module going.

I/the OU have the following priorities:

# Make question type plugins really plug-in-able. At the moment there are some limitations:
#* All the lang strings are still in lang/en_utf8/quiz.php.
#* qtype plugins cannot easily feed CSS and Javascript into the page.
#* pluggable qtypes and pluggable inport/export filters don't play nicely together.
# Write some new question types.
# Make some improvements to existing question types.
# Get RQP working again, so our in-house question engine can talk to Moodle.

''I'm Interested:''
# Tim Hunt

==Performance profiling==

Pick a (memory|database) hog and put it on a diet.

''I'm interested''

# martin langhoff

==Add your suggestion here ...==

Go on, you know you want to.

==See also==
* [http://moodlemoot.org/ http://moodlemoot.org/]

Multi authentication

2006-04-03T20:43:42Z

Iarenaza: Added 'isinternal' field to prefix_auth_type table

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples sources of the same type (LDAP, database, etc)
* Each source has its own configuration
* The order in which we try the sources is configurable

=== How it works ===

* Each source has at least the auth_user_login function (like now).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each source in the configured order.
* For each order, we call auth_user_login with the user credentials and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the sources returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql gurus please adjust definition ;-)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`isinternal` tinyint(1) NOT NULL default '0',
`multiple` tinyint(1) NOT NULL default '0',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'internal', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'isinternal' if this auth type is internal to Moodle (1) or not(0), i.e., if it doesn't depend on any external entity to provide authentication. Tipically this is for 'manual', 'email' and 'none'.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'internal', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'internal' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'internal' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0'
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to user each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Others?

[[Category:Future]]

Multi authentication

2006-03-25T22:59:20Z

Iarenaza: Remove 'interactive' field from this table. It doesn't make sense.

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples sources of the same type (LDAP, database, etc)
* Each source has its own configuration
* The order in which we try the sources is configurable

=== How it works ===

* Each source has at least the auth_user_login function (like now).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each source in the configured order.
* For each order, we call auth_user_login with the user credentials and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the sources returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql gurus please adjust definition ;-)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`multiple` tinyint(1) NOT NULL default '0',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'internal', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'internal', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'internal' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'internal' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0'
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to user each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Others?

[[Category:Future]]

Multi authentication

2006-03-04T22:12:55Z

Iarenaza: Initial version

Before starting to code anything about Multi Authentication support in Moodle, I would like to share what I have in mind, so others can see the flaws and everybody can spot the problems with this approach.

There are some big questions (see below) I don't know the answer for, so if others with more knowledge of Moodle internals (specially authentication internals) than me could answer them, that would be great.

== Some random notes about multi-auth in Moodle ==

=== Goals ===

* Multiple simultaneous sources for authentication
* Multiples sources of the same type (LDAP, database, etc)
* Each source has its own configuration
* The order in which we try the sources is configurable

=== How it works ===

* Each source has at least the auth_user_login function (like now).
* This function can return one of the following values:
** AUTH_OK: the user and the password are valid
** AUTH_DECLINED: The user or the password are not correct or unknown to this source
** AUTH_DENIED: This user cannot login, even if the username and password are valid
** AUTH_ERROR: The source found and error during user and password validation and can't say wether they are valid or not.
* We try each source in the configured order.
* For each order, we call auth_user_login with the user credentials and test the result.
** if the result is AUTH_DENIED, we break out of the loop and deny the user login.
** if the result is AUTH_OK, we break out of the loop and allow the user login.
** in any other case, we continue the loop.
* If we finish the loop, we deny the user login (all the sources returned either AUTH_DECLINED or AUTH_ERROR, so we can't let the user log in).

=== The (proposed) database tables ===

(MySQL syntax, Postgresql gurus please adjust definition ;-)

==== auth_type ====
<pre>
CREATE TABLE `prefix_auth_type` (
`id` integer(10) NOT NULL auto_increment,
`name` varchar(20) NOT NULL default '',
`multiple` tinyint(1) NOT NULL default '0',
`interactive` tinyint(1) NOT NULL default '0',
`candisable` tinyint(1) NOT NULL default '0',
`removable` tinyint(1) NOT NULL default '0',
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different authentication types present in this
Moodle installation: internal, none, ldap, db, cas, etc.

Each auth type has to autoregister in this table when it's installed,
specifying:

* 'id': the primary key of the record.
* 'name': The name of the autentication type: 'internal', 'none', 'ldap', 'db', etc. There can't be duplicated values in this field.
* 'multiple': if this auth type supports multiple instances (1) or not (0).
* 'interactive': if this auth type is interactive (1) or not (0).
* 'candisable': if this auth type can be temporarily disabled (1) or not (0)
* 'removable': if this auth type can be removed from the system (1) or not (0).

If we decide that 'internal', 'none' and/or 'email' are special
authentication types and are handled separately form the rest, then
this last field can be removed.

'''BIG QUESTION HERE''': Can 'internal' be disabled? I'm not sure
about this, as all the admin users can be locked out of Moodle if we
mistakenly disable all the auth types needed for admin users.

'''BIG QUESTION HERE''': Should 'internal' auth type be handled
separately from all this multi-auth mess? I guess there are some
benefits to it, but I'm not sure about it. For one, it would make the
above question irrelevant.

==== auth_instance ====
<pre>
CREATE TABLE `prefix_auth_instance` (
`id` integer(10) NOT NULL auto_increment,
`typeid` integer(10) NOT NULL default '0',
`name` varchar(20) NOT NULL default '',
`description` varchar(50) NOT NULL default '',
`sortorder` integer(10) NOT NULL default '0'
PRIMARY_KEY(`id`),
UNIQUE KEY(`name`)
)
</pre>

This table stores the different auth instances available for each auth
type. It's managed from the authentication setup page, using
the add/modify/delete functionality available there. We can also
specify the order in which we want to user each auth-instance when
authenticating users.

The meaning of the fields are:

* 'id': the primary key of the record. We will put this value into the 'auth' field in prefix_user table when we correctly authenticate a user using this auth instance (to later track where to update values from, where to check for password expiration, etc.)
* 'typeid': the auth type id of this instance. It's a foreign key into the 'type' field of auth_type table. We need this to check if there is already an instance of a given auth type, in case that auth type doesn't allow for multiple instances.
* 'name': the name of this instance. It's the text shown in the authentication setup page to refer to this instance.
* 'description': a short description text for this instance (e.g., 'UK Students LDAP server').
* 'sortorder': the order in which we use each auth instance when trying to authenticate users.

'''BIG QUESTION HERE''': If we use 'id' to fill in the 'auth' field in
prefix_user, then we should only use 'sortorder' when the user has
that field empty (i.e., we don't know where to authenticate this user
so far). Otherwise we could directly authenticate with the known
auth-instance. But this prevents users from "moving" between
authentication instances (i.e, this user "was" in our UK student's
LDAP server, but now "is" in our US staff database server). Is this
good or bad?

==== auth_instance_settings ====
<pre>
CREATE TABLE `prefix_auth_instance_settings` (
`id` integer(10) NOT NULL auto_increment,
`instanceid` integer(10) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`value` text NOT NULL
PRIMARY_KEY(`id`),
UNIQUE KEY `instancesetting` (`instanceid`,`name`)
)
</pre>

This table stores each auth instance configuration settings.

* 'id': the primary key for the record.
* 'instanceid': foreign key into the 'id' field of auth_instance table.
* 'name': name of the setting.
* 'value': value for that setting.

There can't be two (or more) identical 'name' values for the same 'instanceid'.

=== The questions ===

Some additional questions before starting to code all this mess

# If we store the 'prefix_auth_intance.id' value in the 'prefix_user.auth' field as suggested above, what should we do when we '''remove''' that auth instance from our system? Should we allow removal if any users are using that instance? Should we move those users to the default auth instance (internal)? Should we choose a new auth instance for those users as part of the removal? Or should we just ignore the 'prefix_user.auth' field during login and just proceed through the whole loop and try to find which new auth instance allows the user to login (if any)?
# Others?