update enrol/ldap to work with roles.
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).
update enrol/database to use roles.
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.
- Foreign keys are really cool (at the XMLDB Editor). Define them as necessary
as they allow as one "formal" structure of the DB. They won't cause problems
on generation, mainly because only the underlying index will be created.
- Please, put comments inside each table/field/key/index field, mainly because
XML comments will be deleted if the file is edited by
- The XMLDB Editor. Please use it ;-)
- Also, one unique index was wrong in the XML file, fixed now.
Fix for MDL-6212. Forum searches now respect the qanda forums. In these forums, the user should not be able to see posts from discussions where the user has not yet posted, unless a post is the first post in the discussion (the question), or unless the user has the capabilitiy mod/forum:viewqandawithoutposting.
some fixes for the main load_user_capablitiies() function, need pair c1, c2 to impose uniqueness. should use c2.id instead for override. no restriction on c2 for assignments
Added a checking flag to check_enrolment_plugins() to make sure that it
never repeats more than once in an invocation. Otherwise it's sometimes
possible for role_assign() during the enrolment process to cause loops.
Drop all the unique keys inside PostgreSQL DB and convert them to
their equivalest unique indexes. We aren't going to allow unique
keys from 1.7 and upwards (until we decide to enforce referential
intregrity and until ADOdb support it)
Added one new function find_key_name() to retrieve the
name og any key in the DB. This hasn't too much sense
for now (until we start to use referencial integrity) and
it is far from perfect, because it doesn't seach for the
key really in DB (due to the lack of support for this of ADOdb).
This is a first cut of a new formslib.php a library of classes for creating and securely processing forms in Moodle, based on PEAR QuickForms. Only uses XHTML and CSS and no table tags.
This is NOT YET PART OF THE MOODLE API it is here for experimental purposes.
projects / moodle.git / log