and admins can approve or reject pending courses.
Also, contains the ability to restrict activity modules on a per course basic. Strict config options:
enable restricting modules at ALL (for all courses, no courses, requested courses), what to do by default for newly created courses
as well as what modules to enable for above category by default.
This feature was created for the aim of building a community side to moodle - for institutes that have strict courses and enrolments, allowing normal users to request interest courses is a good feature,
but some modules may be redundant (assignment, lesson, quiz etc)
Please test!
If the admin specifies a Policy Agreement (via URL in the config variables)
then each user is required to see and agree to that document once before
continuing.
To get everyone to see it again (on an update, say) one just needs to issue:
UPDATE user SET policyagreed = 0
Student and teacher enrolments now unique + version bump
Made student and teacher enrolments unique, enforced at the database level. This patch also removes a cleanup job in moodle's cron that removed duplicate enrolments.
Merge of patchset arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-422
These patches add an 'enrol' column to the user_students and user_teachers tables for the enrolment plugins to be able to keep track of source of the enrolments. Follows similar conventions to the user table with its 'auth' field.
This is a merge of the following patches:
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-187
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-192
Add a unique key to guarantee that course,sortorder is unique. Allows fix_course_sortorder and ordering operations to be much faster. (martinlanghoff)
Plus more indexes for user table (mjollnir_)
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-231
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-236
Code based on the work of Daryl Hawes for the blog module. Thanks, Daryl!
Please test the hell out of it as it's sure to have issues that need to be
ironed out.
This can be userd to store "global unique identifier" from external databases
like Windows SID or eDirectorys guid . This will keep upcoming user syncronization
feature reliable in case of renamed users.
Mysql files are untested.
php -l mysql.php does not show any syntax errors, so files
should work.
authentication mechanism used to create that user record.
Also added code to upgrade existing systems to have entries in that
field, and for new users to also have that field defined.
This will allow us to later improve the login procedure to be able to
handle various types of authentication.
