Credit: Alastair Pharo <alastair@catalyst.net.nz>
1) Some config settings have changed (ones that related specifically to
teachers and students). There is a check in place however to migrate
old configurations to new ones.
2) Perviously two syncs happened - one for students, one for teachers.
Now sync gets called the same number of times as there are roles.
Those roles that have config settings associated with them then run
through all the records. This means syncing takes longer the more
roles you configure (which is expected anyway I suppose).
Credit: Alastair Pharo <alastair@catalyst.net.nz>
Database
--------
1) This plugin previously only worked for students. I have made it so
that you can _optionally_ specify a third column in your external
database that contains some kind of role information (similar to the
other two fields, you can choose any column in the mdl_role table
to map to). If you do this, then the code loops over for each different
kind of role and queries the external database.
2) There is a *slight* problem to be aware of, if a moodle
configuration was upgraded to use the new role columns, then downgraded
again, some roles might get left behind in the database when the
large-scale sync thing goes through (that is, record pruning doesn't
scale back quite properly). These would be cleaned away by
setup_enrolments at login time, however, and the scenario was unlikely
enough for me to decide to leave it for now.
3) If you don't have role columns there is a 'default role' setting
that you can set (made by Martin D). This will only be obeyed when no
role columns are specified. If this is set to 'default', then the
course default role is used, on a per-course basis (which usually
means student apparently).
4) From (3), my understanding is that if no config settings are
changed, and the default role for all upgraded courses is student, that
a smooth upgrade to 1.7 will occur for users of the database enrolment
plugin.
new-style setup_enrolments() function that uses roles
to do the tasks required when a user logs in.
Other enrolment plugins should use this as an example/guide
The sync parts of this plugin are not yet fixed.
authorizenetlib.php autoconfigures payment method as AN_METHOD_CC if the merchant doesn't accept AN_METHOD_ECHECK. First real echeck transaction is enough for this.
Error message isn't shown when user clicked without key.
Multienrol is enabled (course enrol key with authorize)
This patch allows showing error message when user clicked button without key.
Authorize.Net provides an exclusive, fully integrated electronic check payment method, eCheck.Net.
Using eCheck.Net, merchants can accept and process payments from consumer and corporate bank accounts
directly from their Web site or through the Authorize.Net Virtual Terminal. By accepting electronic checks,
you expand the payment options available to new and existing customers, enhancing customer loyalty and
potentially increasing sales.
+ Lower Fees - Lower rates than credit cards or PayPal.
+ More Efficient - eCheck.Net does everything online, eliminating the cost and inconvenience of manually
processing paper checks and waiting for checks in the mail.
+ Fully Integrated Solution - No third-party integration required implementing eCheck.Net is easy
for merchants already using the Authorize.Net Payment Gateway.
+ Integrated Reporting - Provides a combined view of all eCheck.Net and credit card payment transactions.
Reconcile payment and billing activity using online reports and statements.
+ Ship Product Sooner - Improved up-front transaction validation that returns the status of transactions faster.
+ Security - Authorize.Net uses the latest 128-bit Secure Socket Layer (SSL) technology for
secure Internet Protocol (IP) transactions.
