moodle/enrol
2006-10-03 09:05:38 +00:00
..
authorize No need extra $order->status check. These functions expired() and settled() do it for us. Merged from 16stable. 2006-10-03 09:05:38 +00:00
database enrol/db/enrol.php ignore delt'd usrs when enroling 2006-09-28 01:20:42 +00:00
flatfile Flatfile enrolment plugin upgraded to new use roles. Credit: Alastair Pharo, new Catalyst ninja ;) <alastair@catalyst.net.nz> 2006-09-21 00:04:43 +00:00
imsenterprise Fixed PHP 4 compatibility re MDL-6753 2006-09-30 17:46:15 +00:00
ldap update enrol/ldap to work with roles. 2006-09-26 01:31:33 +00:00
manual renamed field in context table 2006-09-22 06:21:48 +00:00
paypal Fixes to user new Roles 2006-09-22 16:19:24 +00:00
enrol.class.php Changing error to notify so that it's not fatal (and doesn't leak server data) 2006-09-26 04:38:00 +00:00
index.html Stop people browsing enrolment modules 2005-01-23 04:17:41 +00:00
README.txt Updated some docs 2006-09-11 08:25:49 +00:00

ENROLMENT MODULES
-----------------

(Yes, that's the correct English spelling  ;-) )

enrol.class.php contains a simple 'factory' method that
will instantiate your class when called. For an example
of a complete class, take a look at the 'manual' class.

Each plugin is in a subfolder here.

Except for the configuration methods, most methods 
defined in the API are optional -- callers will use
method_exists() to determine whether your plugin offers
the functionality they are after.


Mandatory methods
=================

  config_form()
  process_config()


Login-time methods
==================

  Before Moodle 1.7
  -----------------

      get_student_courses()
      get_teacher_courses()
  
  You probably will want to offer at least get_student_courses().
  
  These methods are triggered when a user logs in successfully,
  and they are expected to populate $USER->student and 
  $USER->teacher arrays and maintain (add/delete) entries from
  user_students and user_teachers.
  
  These methods are relevant for most plugins, and are the main
  interest for plugins that work with a read-only backend such
  as LDAP or a database.
  
  Note that with the multi-enrol infrastructure two things have 
  changed. We now have an 'enrol' field in those tables, and 
  each plugin must maintain only its own enrolment records. 
  Conversely, the $USER->student and ->teacher arrays have the
  enrolment type as value, like
  
     $USER->student = array ( $courseid => $plugintype );
  

  Moodle 1.7 and later
  --------------------

      setup_enrolments()

  With the advent of roles, there could well not be students and 
  teachers any more, so enrolment plugins have to be more flexible
  about how they map outside data to the internal roles.
  
  This one method should do everything, calling functions from 
  lib/accesslib.php as necessary to set up relationships.
  
  
Interactive enrolment methods
=============================

  print_entry()
  check_entry()
  check_group_entry()
  get_access_icons()

These methods are for enrolment plugins that allow for user
driven enrolment. These methods are relevant for plugins 
that implement payment gateways (credit card, paypal),
as well as "magic password" schemes. 

Only one interactive enrolment method can be active for
a given course. The site default can be set from
Admin->Enrolment, and then individual courses can be
set to specific interactive enrolment methods.


Cron
====

If your class offers a cron() method, it will be invoked by
the standard Moodle cron every 5 minutes. Note that if the
tasks are not lightweight you must control how frequently they
execute, perhaps offering a config option.

For really heavy cron processing, an alternative is to have
a separate script to be called separately. Currently the LDAP
and DB plugins have external scripts. 


Guilty Parties
--------------

Martin Dougiamas and Shane Elliott, Moodle.com
Martin Langhoff and Patrick Li, Catalyst IT