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.
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.
you want to completely reload the capabilities for the current user.
Basically it will deal nicely with the default site-wide permissions
depending on the current user.
More background in the comments on MDL-6963
Merged from stable
* 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.
* 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.
Previously the import process would throw a non-fatal error when it found a
non-one number of users with the remote key. This meant that
when there was a deleted user with the same remote key as an existing user, it
would throw an error, and report that there were no users for that remote key.
Fixed it so that it now ignores deleted users, and provides more accurate
and more precise error messages in the event that there are further
problems.
Author: Peter Bulmer
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.
