Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Enrolment plugins: Difference between revisions

From MoodleDocs
m (link edit)
Line 1: Line 1:
==Testing paypal using the paypal developer sandbox==
==Testing paypal using the paypal developer sandbox==
(for moodle 1.4 - 1.6)
(for moodle 1.4 - 1.8)
If you follow these steps, you can test paypal payments using the paypal developer sandbox instead of the real paypal site.  No money is actually charged to any account.  All other actions are the same as if you were using the real paypal site.
If you follow these steps, you can test paypal payments using the paypal developer sandbox instead of the real paypal site.  No money is actually charged to any account.  All other actions are the same as if you were using the real paypal site.
* create a paypal developer account at https://developer.paypal.com/cgi-bin/devscr?cmd=_home
* create a paypal developer account at https://developer.paypal.com/cgi-bin/devscr?cmd=_home

Revision as of 09:17, 30 July 2007

Testing paypal using the paypal developer sandbox

(for moodle 1.4 - 1.8) If you follow these steps, you can test paypal payments using the paypal developer sandbox instead of the real paypal site. No money is actually charged to any account. All other actions are the same as if you were using the real paypal site.

  • create a paypal developer account at https://developer.paypal.com/cgi-bin/devscr?cmd=_home
  • change the address being used to send data to paypal to use the sandbox. in enrol/paypal/enrol.html:
  • change the address that is used to check the acknowledgment from paypal. in enrol/paypal/ipn.php, change:
    • $fp = fsockopen ('www.paypal.com', 80, $errno, $errstr, 30);
  • to
    • $fp = fsockopen ('www.sandbox.paypal.com', 80, $errno, $errstr, 30);
  • create a couple of user accounts in the paypal sandbox and test enrolling in a course that requires payment (note that you need to be logged into the paypal sandbox while doing this testing)

Enrolment plugins 1.7

Background

  1. isteacher(), isstudent(), isadmin(), iscoursecreator() are all deprecated and should be replaced with checks on has_capability instead.
  2. enrol_student() and add_teacher() are obsolete, so use the generic role_assign() or the convenience function for "students" called enrol_into_course() instead.
  3. unenrol_student() and remove_teacher() are obsolete, so use the generic role_unassign() instead.
  4. All the roles have a "shortname", so by default we can refer to them using "teacher", "student", "editingteacher" etc. Note that new roles may have different names. Enrolment plugins can use these to map outside data onto the inside roles without needing to know internal role id numbers. For example, it would be really handy for the flatfile plugin to refer to roles directly like this.
  5. Each plugin used to implement get_student_courses() and get_teacher_courses() for use at login time. These now need to be converted to one new function called $enrol->setup_enrolments($user) which looks up sets all enrolments for a given user (using role_assign and role_unassign).
  6. All the session arrays like $USER->student[] and $USER->teacher[] are gone and should not be relied on. You can check what roles a user already has by calling get_user_roles() on that course context.

What's been done

  1. enrol/manual has been converted to use the new functions
  2. enrol/imsenterprise has been converted - testing needed though

What still needs to be done

  1. enrol/authorize
  2. enrol/database
  3. enrol/flatfile
  4. enrol/ldap
  5. enrol/paypal

See also