+ Restore an_test to original state after account verification. If admin clicks Save Changes after account verification, all transactions go to test mode.
This new messaging system replaces all the various email_to_user() calls.
They are now replaced by events triggers, and the messages are then
processed centrally according to user preferences and sent to one or more
processors (email, popup, jabber etc...)
This code is not finished yet, a lot of work still has to be done on the
interface. However, the basic structure is there and should be working.
Luis and I will be reviewing and polishing this heavily in the next few weeks.
In one cron, 250-500 orders may be processed (based on 5 minutes).
If an admin sets cron time up smaller than 5 minutes and
250-500> new transactions are made after last cron executed, it can be blocked.
Authorize cron sets up an_lastcron every time when admin/cron.php executes.
This must be set up after blocking check code.
As result, if pending orders aren't accepted with in 30 days at payment management page, they expired and users cannot enrol.
When an admin enabled order review, he is guaranteed 'Payment managers accept/deny transactions manually'.
Scheduled-Capture is designed for forgotten orders only ;)
Fatal error: Call to undefined method enrolment_plugin_authorize::print_enrolmentkeyfrom() in /usr/local/www/data/moodle/enrol/manual/enrol.html on line 7
* Don't show login name, password and transaction key at the configuration page.
* RC4Encrypt these fields and move to the config_plugins table from the config table.
* Config page is fully https.
Because this field will be used to refund both cc and echeck.
Business checkings can be refunded, too; so mark as 1 this field for business checkings.
That is; refundinfo: is last four digit for credit cards, business checking for echecks.
Merged from MOODLE_17_STABLE.
MDL-7561
MDL-7562
Need to be used new forms api.
Please see also:
* enrol.php: check_entry(), config_form(), process_config()
* localfuncs.php: validate_cc_form(), validate_echeck_form()
Some users may not wish to use their credit cards on the internet directly for security reasons.
In this case, you need to obtain an authorization code from user's bank.
Initially, ask for credit card information from the customer
like bank name, name on card, card number, expiry date and card validation code
by means of phone, face-to-face or a billing application.
Then, call the customer services of user's bank giving this information and demand an authorization code.
Finally, after obtaining it, login as user to get the user enrolled.
Alternatively, you can give it to the user saying enrol using this code.
* AN_RETURNZERO: No connection was made on authorize.net.
* AN_APPROVED: The transaction was accepted.
* AN_DECLINED: The transaction was declined.
* AN_REVIEW: The transaction was held for review.
+ Fix: Speacial handling for echecks: REVIEW; 'Under Review', 'Approved Review', 'Review Failed'
+ New feature: Upload a CSV file for echecks (capability: enrol/authorize:uploadcsv level: user)
+ New feature: Search payments by orderid and transid
+ New function: send_welcome_messages()
merged from 17stable.
This is actually good thing, because we can send our welcome message.
* enrol_into_course() added in Moodle(2006091700), so authorize plugin requires this version.
