2004-08-21 17:15:07 +00:00
< ? php // $Id$
2004-08-14 12:47:24 +00:00
2006-09-19 16:29:43 +00:00
require_once ( $CFG -> dirroot . '/enrol/enrol.class.php' );
2004-08-14 12:47:24 +00:00
2006-03-09 02:48:29 +00:00
class enrolment_plugin_database {
2004-08-14 12:47:24 +00:00
2007-09-21 11:02:30 +00:00
var $log ;
2004-08-14 12:47:24 +00:00
2008-06-02 21:02:52 +00:00
/**
2006-09-19 16:29:43 +00:00
* For the given user , let ' s go out and look in an external database
2007-09-21 11:02:30 +00:00
* for an authoritative list of enrolments , and then adjust the
2006-09-19 16:29:43 +00:00
* local Moodle assignments to match .
*/
function setup_enrolments ( & $user ) {
2008-06-02 21:02:52 +00:00
global $CFG , $DB ;
2004-08-14 12:47:24 +00:00
2006-01-16 03:03:21 +00:00
// NOTE: if $this->enrol_connect() succeeds you MUST remember to call
2008-06-05 20:35:28 +00:00
// $this->enrol_disconnect() as it is doing some nasty vodoo with table prefix
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.
2006-09-26 01:30:32 +00:00
$enroldb = $this -> enrol_connect ();
if ( ! $enroldb ) {
2006-12-06 09:49:05 +00:00
error_log ( '[ENROL_DB] Could not make a connection' );
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.
2006-09-26 01:30:32 +00:00
return ;
}
// If we are expecting to get role information from our remote db, then
// we execute the below code for every role type. Otherwise we just
// execute it once with null (hence the dummy array).
$roles = ! empty ( $CFG -> enrol_db_remoterolefield ) && ! empty ( $CFG -> enrol_db_localrolefield )
2008-11-13 08:40:57 +00:00
? get_all_roles ()
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.
2006-09-26 01:30:32 +00:00
: array ( null );
//error_log('[ENROL_DB] found ' . count($roles) . ' roles:');
foreach ( $roles as $role ) {
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
//error_log('[ENROL_DB] setting up enrolments for '.$role->shortname);
2004-08-14 12:47:24 +00:00
2006-09-19 16:29:43 +00:00
/// Get the authoritative list of enrolments from the external database table
/// We're using the ADOdb functions natively here and not our datalib functions
2008-05-31 22:18:41 +00:00
/// because we didn't want to mess with the $ db global
2004-09-23 17:02:40 +00:00
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.
2006-09-26 01:30:32 +00:00
$useridfield = $enroldb -> quote ( $user -> { $CFG -> enrol_localuserfield });
2004-09-23 17:02:40 +00:00
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.
2006-09-26 01:30:32 +00:00
list ( $have_role , $remote_role_name , $remote_role_value ) = $this -> role_fields ( $enroldb , $role );
2006-09-19 16:29:43 +00:00
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.
2006-09-26 01:30:32 +00:00
/// Check if a particular role has been forced by the plugin site-wide
/// (if we aren't doing a role-based select)
2007-09-21 11:02:30 +00:00
if ( ! $have_role && $CFG -> enrol_db_defaultcourseroleid ) {
2008-06-02 21:02:52 +00:00
$role = $DB -> get_record ( 'role' , array ( 'id' => $CFG -> enrol_db_defaultcourseroleid ));
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.
2006-09-26 01:30:32 +00:00
}
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
/// Whether to fetch the default role on a per-course basis (below) or not.
$use_default_role = ! $role ;
/*
if ( $have_role ) {
error_log ( '[ENROL_DB] Doing role-specific select from db for role: ' . $role -> shortname );
} elseif ( $use_default_role ) {
error_log ( '[ENROL_DB] Using course default for roles - assuming that database lists defaults' );
} else {
error_log ( '[ENROL_DB] Using config default for roles: ' . $role -> shortname );
} */
2007-09-21 11:02:30 +00:00
2007-01-15 19:57:12 +00:00
if ( $rs = $enroldb -> Execute ( " SELECT { $CFG -> enrol_remotecoursefield } as enrolremotecoursefield
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.
2006-09-26 01:30:32 +00:00
FROM { $CFG -> enrol_dbtable }
WHERE { $CFG -> enrol_remoteuserfield } = " . $useridfield .
( isset ( $remote_role_name , $remote_role_value ) ? ' AND ' . $remote_role_name . ' = ' . $remote_role_value : '' ))) {
// We'll use this to see what to add and remove
$existing = $role
2008-06-02 21:02:52 +00:00
? $DB -> get_records_sql ( " SELECT *
FROM { role_assignments }
WHERE userid = ? AND roleid = ? " ,
array ( $user -> id , $role -> id ))
: $DB -> get_records ( 'role_assignments' , array ( 'userid' => $user -> id ));
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.
2006-09-26 01:30:32 +00:00
if ( ! $existing ) {
$existing = array ();
}
2004-09-23 17:02:40 +00:00
2007-10-10 12:19:27 +00:00
if ( ! $rs -> EOF ) { // We found some courses
2006-09-19 16:29:43 +00:00
2007-10-10 12:19:27 +00:00
//$count = 0;
2006-09-19 16:29:43 +00:00
$courselist = array ();
2008-06-09 19:48:24 +00:00
while ( $fields_obj = ( object ) $rs -> FetchRow ()) { // Make a nice little array of courses to process
2008-08-14 12:01:34 +00:00
$fields_obj = ( object ) array_change_key_case (( array ) $fields_obj , CASE_LOWER );
2007-01-29 23:56:55 +00:00
$courselist [] = $fields_obj -> enrolremotecoursefield ;
2007-10-10 12:19:27 +00:00
//$count++;
2004-09-23 17:02:40 +00:00
}
2008-06-09 19:48:24 +00:00
$rs -> close ();
2004-09-23 17:02:40 +00:00
2007-10-10 12:19:27 +00:00
//error_log('[ENROL_DB] Found '.count($existing).' existing roles and '.$count.' in external database');
2006-09-19 16:29:43 +00:00
foreach ( $courselist as $coursefield ) { /// Check the list of courses against existing
2008-06-02 21:02:52 +00:00
$course = $DB -> get_record ( 'course' , array ( $CFG -> enrol_localcoursefield => $coursefield ));
2007-03-26 06:51:17 +00:00
if ( ! is_object ( $course )) {
if ( empty ( $CFG -> enrol_db_autocreate )) { // autocreation not allowed
2007-07-20 08:57:05 +00:00
if ( debugging ( '' , DEBUG_ALL )) {
error_log ( " Course $coursefield does not exist, skipping " ) ;
}
2007-03-26 06:51:17 +00:00
continue ; // next foreach course
2004-09-23 17:02:40 +00:00
}
2007-03-26 06:51:17 +00:00
// ok, now then let's create it!
// prepare any course properties we actually have
$course = new StdClass ;
2007-04-05 01:54:44 +00:00
$course -> { $CFG -> enrol_localcoursefield } = $coursefield ;
$course -> fullname = $coursefield ;
$course -> shortname = $coursefield ;
2007-07-20 08:57:05 +00:00
if ( ! ( $newcourseid = $this -> create_course ( $course , true )
2008-06-02 21:02:52 +00:00
and $course = $DB -> get_record ( 'course' , array ( 'id' => $newcourseid )))) {
2007-07-20 08:57:05 +00:00
error_log ( " Creating course $coursefield failed " );
2007-03-26 06:51:17 +00:00
continue ; // nothing left to do...
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.
2006-09-26 01:30:32 +00:00
}
2007-03-26 06:51:17 +00:00
}
2005-08-26 06:11:38 +00:00
2007-07-20 13:03:19 +00:00
// if the course is hidden and we don't want to enrol in hidden courses
// then just skip it
if ( ! $course -> visible and $CFG -> enrol_db_ignorehiddencourse ) {
continue ;
}
2007-03-26 06:51:17 +00:00
/// If there's no role specified, we get the default course role (usually student)
if ( $use_default_role ) {
$role = get_default_course_role ( $course );
}
2007-09-21 11:02:30 +00:00
2007-03-26 06:51:17 +00:00
$context = get_context_instance ( CONTEXT_COURSE , $course -> id );
2007-09-21 11:02:30 +00:00
2007-03-26 06:51:17 +00:00
// Couldn't get a role or context, skip.
if ( ! $role || ! $context ) {
continue ;
}
2007-09-21 11:02:30 +00:00
2007-03-26 06:51:17 +00:00
// Search the role assignments to see if this user
// already has this role in this context. If it is, we
// skip to the next course.
foreach ( $existing as $key => $role_assignment ) {
if ( $role_assignment -> roleid == $role -> id
&& $role_assignment -> contextid == $context -> id ) {
unset ( $existing [ $key ]);
//error_log('[ENROL_DB] User is already enroled in course '.$course->idnumber);
continue 2 ;
2006-09-19 16:29:43 +00:00
}
2005-08-26 06:11:38 +00:00
}
2007-09-21 11:02:30 +00:00
2007-03-26 06:51:17 +00:00
//error_log('[ENROL_DB] Enrolling user in course '.$course->idnumber);
role_assign ( $role -> id , $user -> id , 0 , $context -> id , 0 , 0 , 0 , 'database' );
2004-09-23 17:02:40 +00:00
}
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.
2006-09-26 01:30:32 +00:00
} // We've processed all external courses found
/// We have some courses left that we might need to unenrol from
/// Note: we only process enrolments that we (ie 'database' plugin) made
2007-11-21 11:06:46 +00:00
/// Do not unenrol anybody if the disableunenrol option is 'yes'
if ( ! $CFG -> enrol_db_disableunenrol ) {
foreach ( $existing as $role_assignment ) {
if ( $role_assignment -> enrol == 'database' ) {
//error_log('[ENROL_DB] Removing user from context '.$role_assignment->contextid);
role_unassign ( $role_assignment -> roleid , $user -> id , '' , $role_assignment -> contextid );
2008-08-14 12:01:34 +00:00
}
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.
2006-09-26 01:30:32 +00:00
}
2004-09-23 17:02:40 +00:00
}
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.
2006-09-26 01:30:32 +00:00
} else {
error_log ( '[ENROL_DB] Couldn\'t get rows from external db: ' . $enroldb -> ErrorMsg ());
2004-09-23 17:02:40 +00:00
}
2007-09-21 11:02:30 +00:00
}
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.
2006-09-26 01:30:32 +00:00
$this -> enrol_disconnect ( $enroldb );
2004-08-14 12:47:24 +00:00
}
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.
2006-09-26 01:30:32 +00:00
/**
* sync enrolments with database , create courses if required .
*
* @ param object The role to sync for . If no role is specified , defaults are
* used .
*/
function sync_enrolments ( $role = null ) {
2008-06-09 18:48:28 +00:00
global $CFG , $DB ;
2006-01-16 03:08:50 +00:00
error_reporting ( E_ALL );
// Connect to the external database
$enroldb = $this -> enrol_connect ();
2007-09-21 11:02:30 +00:00
if ( ! $enroldb ) {
2006-01-16 03:08:50 +00:00
notify ( " enrol/database cannot connect to server " );
return false ;
}
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.
2006-09-26 01:30:32 +00:00
if ( isset ( $role )) {
echo '=== Syncing enrolments for role: ' . $role -> shortname . " === \n " ;
} else {
echo " === Syncing enrolments for default role === \n " ;
}
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
// first, pack the sortorder...
fix_course_sortorder ();
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.
2006-09-26 01:30:32 +00:00
list ( $have_role , $remote_role_name , $remote_role_value ) = $this -> role_fields ( $enroldb , $role );
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
if ( ! $have_role ) {
if ( ! empty ( $CFG -> enrol_db_defaultcourseroleid )
2008-06-02 21:02:52 +00:00
and $role = $DB -> get_record ( 'role' , array ( 'id' => $CFG -> enrol_db_defaultcourseroleid ))) {
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.
2006-09-26 01:30:32 +00:00
echo " === Using enrol_db_defaultcourseroleid: { $role -> id } ( { $role -> shortname } ) === \n " ;
} elseif ( isset ( $role )) {
echo " !!! WARNING: Role specified by caller, but no (or invalid) role configuration !!! \n " ;
}
}
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
// get enrolments per-course
$sql = " SELECT DISTINCT { $CFG -> enrol_remotecoursefield } " .
" FROM { $CFG -> enrol_dbtable } " .
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.
2006-09-26 01:30:32 +00:00
" WHERE { $CFG -> enrol_remoteuserfield } IS NOT NULL " .
( isset ( $remote_role_name , $remote_role_value ) ? ' AND ' . $remote_role_name . ' = ' . $remote_role_value : '' );
2006-01-16 03:08:50 +00:00
$rs = $enroldb -> Execute ( $sql );
if ( ! $rs ) {
trigger_error ( $enroldb -> ErrorMsg () . ' STATEMENT: ' . $sql );
return false ;
}
2007-10-10 12:19:27 +00:00
if ( $rs -> EOF ) { // no courses! outta here...
2006-01-16 03:08:50 +00:00
return true ;
}
2008-06-02 21:02:52 +00:00
$DB -> begin_sql ();
2006-01-16 03:08:50 +00:00
$extcourses = array ();
2008-06-09 19:48:24 +00:00
while ( $extcourse_obj = ( object ) $rs -> FetchRow ()) { // there are more course records
2008-08-14 12:01:34 +00:00
$extcourse_obj = ( object ) array_change_key_case (( array ) $extcourse_obj , CASE_LOWER );
2008-08-27 07:27:13 +00:00
$extcourse = $extcourse_obj -> { strtolower ( $CFG -> enrol_remotecoursefield )};
2006-01-16 03:08:50 +00:00
array_push ( $extcourses , $extcourse );
2007-09-21 11:02:30 +00:00
// does the course exist in moodle already?
2006-01-16 03:08:50 +00:00
$course = false ;
2008-06-02 21:02:52 +00:00
$course = $DB -> get_record ( 'course' , array ( $CFG -> enrol_localcoursefield => $extcourse ));
2006-01-16 03:08:50 +00:00
if ( ! is_object ( $course )) {
2006-01-16 03:11:46 +00:00
if ( empty ( $CFG -> enrol_db_autocreate )) { // autocreation not allowed
2007-07-20 08:57:05 +00:00
if ( debugging ( '' , DEBUG_ALL )) {
error_log ( " Course $extcourse does not exist, skipping " );
}
2006-01-16 03:11:46 +00:00
continue ; // next foreach course
}
2006-01-16 03:08:50 +00:00
// ok, now then let's create it!
// prepare any course properties we actually have
$course = new StdClass ;
$course -> { $CFG -> enrol_localcoursefield } = $extcourse ;
$course -> fullname = $extcourse ;
$course -> shortname = $extcourse ;
2007-07-20 08:57:05 +00:00
if ( ! ( $newcourseid = $this -> create_course ( $course , true )
2008-06-02 21:02:52 +00:00
and $course = $DB -> get_record ( 'course' , array ( 'id' => $newcourseid )))) {
2007-07-20 08:57:05 +00:00
error_log ( " Creating course $extcourse failed " );
2006-01-16 03:08:50 +00:00
continue ; // nothing left to do...
}
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.
2006-09-26 01:30:32 +00:00
}
$context = get_context_instance ( CONTEXT_COURSE , $course -> id );
// If we don't have a proper role setup, then we default to the default
// role for the current course.
if ( ! $have_role ) {
$role = get_default_course_role ( $course );
2006-01-16 03:08:50 +00:00
}
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
// get a list of the student ids the are enrolled
// in the external db -- hopefully it'll fit in memory...
$extenrolments = array ();
$sql = " SELECT { $CFG -> enrol_remoteuserfield } " .
" FROM { $CFG -> enrol_dbtable } " .
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.
2006-09-26 01:30:32 +00:00
" WHERE { $CFG -> enrol_remotecoursefield } = " . $enroldb -> quote ( $extcourse ) .
( $have_role ? ' AND ' . $remote_role_name . ' = ' . $remote_role_value : '' );
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
$crs = $enroldb -> Execute ( $sql );
if ( ! $crs ) {
trigger_error ( $enroldb -> ErrorMsg () . ' STATEMENT: ' . $sql );
return false ;
}
2007-10-10 12:19:27 +00:00
if ( $crs -> EOF ) { // shouldn't happen, but cover all bases
2006-01-16 03:08:50 +00:00
continue ;
}
2008-08-14 12:01:34 +00:00
// slurp results into an array
2008-06-09 19:48:24 +00:00
while ( $crs_obj = ( object ) $crs -> FetchRow ()) {
2008-08-14 12:01:34 +00:00
$crs_obj = ( object ) array_change_key_case (( array ) $crs_obj , CASE_LOWER );
2008-08-27 07:27:13 +00:00
array_push ( $extenrolments , $crs_obj -> { strtolower ( $CFG -> enrol_remoteuserfield )});
2006-01-16 03:08:50 +00:00
}
2008-06-09 19:48:24 +00:00
$crs -> close (); // release the handle
2006-01-16 03:08:50 +00:00
//
2008-05-11 23:55:50 +00:00
// prune enrolments to users that are no longer in ext auth
2006-01-16 03:08:50 +00:00
// hopefully they'll fit in the max buffer size for the RDBMS
//
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.
2006-09-26 01:30:32 +00:00
// TODO: This doesn't work perfectly. If we are operating without
// roles in the external DB, then this doesn't handle changes of role
// within a course (because the user is still enrolled in the course,
// so NOT IN misses the course).
//
// When the user logs in though, their role list will be updated
// correctly.
//
2007-11-23 15:49:00 +00:00
if ( ! $CFG -> enrol_db_disableunenrol ) {
2008-06-02 21:02:52 +00:00
if ( $extenrolments ) {
list ( $extlist , $params ) = $DB -> get_in_or_equal ( $extenrolments , SQL_PARAMS_NAMED , 'e0' , false );
$extsql = " AND u. { $CFG -> enrol_localuserfield } $extlist " ;
} else {
$extsql = " " ;
$params = array ();
}
$params [ 'roleid' ] = $role -> id ;
$params [ 'contextid' ] = $context -> id ;
2008-08-14 12:01:34 +00:00
2008-06-02 21:02:52 +00:00
$to_prune = $DB -> get_records_sql ( "
SELECT ra .*
FROM { role_assignments } ra
JOIN { user } u ON ra . userid = u . id
WHERE ra . enrol = 'database'
AND ra . contextid = : contextid
AND ra . roleid = : roleid " , $params );
2007-11-23 15:49:00 +00:00
if ( $to_prune ) {
foreach ( $to_prune as $role_assignment ) {
if ( role_unassign ( $role -> id , $role_assignment -> userid , 0 , $role_assignment -> contextid )){
error_log ( " Unassigned { $role -> shortname } assignment # { $role_assignment -> id } for course { $course -> id } ( " . format_string ( $course -> shortname ) . " ); user { $role_assignment -> userid } " );
} else {
error_log ( " Failed to unassign { $role -> shortname } assignment # { $role_assignment -> id } for course { $course -> id } ( " . format_string ( $course -> shortname ) . " ); user { $role_assignment -> userid } " );
}
2006-01-16 03:08:50 +00:00
}
}
}
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
//
2007-09-21 11:02:30 +00:00
// insert current enrolments
2006-01-16 03:08:50 +00:00
// bad we can't do INSERT IGNORE with postgres...
//
foreach ( $extenrolments as $member ) {
// Get the user id and whether is enrolled in one fell swoop
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.
2006-09-26 01:30:32 +00:00
$sql = "
2008-06-02 21:02:52 +00:00
SELECT u . id , ra . id AS enrolmentid
FROM { user } u
LEFT JOIN { role_assignments } ra ON u . id = ra . userid
AND ra . roleid = ?
AND ra . contextid = ?
WHERE u . { $CFG -> enrol_localuserfield } = ?
AND ( u . deleted IS NULL OR u . deleted = 0 ) " ;
$eusers = $DB -> get_records ( $sql , array ( $role -> id , $context -> id , $member ));
if ( $eusers === false ) {
trigger_error ( 'error STATEMENT: ' . $sql );
2006-01-16 03:08:50 +00:00
return false ;
}
2008-06-02 21:02:52 +00:00
if ( ! $eusers ) { // if this returns empty, it means we don't have the student record.
2007-09-21 11:02:30 +00:00
// should not happen -- but skip it anyway
2006-01-16 03:12:55 +00:00
trigger_error ( 'weird! no user record entry?' );
2006-01-16 03:08:50 +00:00
continue ;
}
2008-06-02 21:02:52 +00:00
$userid = $user_obj -> id ;
2007-01-29 12:10:19 +00:00
$enrolmentid = $user_obj -> enrolmentid ;
2006-01-16 03:08:50 +00:00
if ( $enrolmentid ) { // already enrolled - skip
continue ;
}
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
if ( role_assign ( $role -> id , $userid , 0 , $context -> id , 0 , 0 , 0 , 'database' )){
2007-07-20 08:57:05 +00:00
error_log ( " Assigned role { $role -> shortname } to user { $userid } in course { $course -> id } ( " . format_string ( $course -> shortname ) . " ) " );
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.
2006-09-26 01:30:32 +00:00
} else {
2007-07-20 08:57:05 +00:00
error_log ( " Failed to assign role { $role -> shortname } to user { $userid } in course { $course -> id } ( " . format_string ( $course -> shortname ) . " ) " );
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.
2006-09-26 01:30:32 +00:00
}
2006-01-16 03:08:50 +00:00
} // end foreach member
} // end while course records
2008-06-09 19:48:24 +00:00
$rs -> close (); //Close the main course recordset
2006-01-16 03:08:50 +00:00
//
// prune enrolments to courses that are no longer in ext auth
//
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.
2006-09-26 01:30:32 +00:00
// TODO: This doesn't work perfectly. If we are operating without
// roles in the external DB, then this doesn't handle changes of role
// within a course (because the user is still enrolled in the course,
// so NOT IN misses the course).
//
// When the user logs in though, their role list will be updated
// correctly.
//
2007-11-23 15:49:00 +00:00
if ( ! $CFG -> enrol_db_disableunenrol ) {
2008-06-02 21:02:52 +00:00
if ( $extcourses ) {
list ( $extlist , $params ) = $DB -> get_in_or_equal ( $extcourses , SQL_PARAMS_QM , 'e0' , false );
$extsql = " AND u. { $CFG -> enrol_localcoursefield } $extlist " ;
} else {
$extsql = " " ;
$params = array ();
}
$params [ 'roleid' ] = $role -> id ;
$params [ 'contextid' ] = $context -> id ;
2007-11-23 15:49:00 +00:00
$sql = "
SELECT ra . roleid , ra . userid , ra . contextid
2008-06-02 21:02:52 +00:00
FROM { role_assignments } ra
JOIN { context } cn ON cn . id = ra . contextid
JOIN { course } c ON c . id = cn . instanceid
WHERE ra . enrol = 'database'
AND cn . contextlevel = " .CONTEXT_COURSE. " " .
( $have_role ? " AND ra.roleid = :roleid " : '' ) . "
$extsql " ;
if ( ! $ers = $DB -> get_recordset_sql ( $sql , $params )) {
trigger_error ( 'error STATEMENT: ' . $sql );
2007-11-23 15:49:00 +00:00
return false ;
}
2008-06-02 21:02:52 +00:00
foreach ( $ers as $user_obj ) {
$roleid = $user_obj -> roleid ;
$user = $user_obj -> userid ;
$contextid = $user_obj -> contextid ;
if ( role_unassign ( $roleid , $user , 0 , $contextid )){
error_log ( " Unassigned role { $roleid } from user $user in context $contextid " );
} else {
error_log ( " Failed unassign role { $roleid } from user $user in context $contextid " );
2008-08-14 12:01:34 +00:00
}
2006-01-16 03:08:50 +00:00
}
2008-06-02 21:02:52 +00:00
$ers -> close (); // release the handle
2006-01-16 03:08:50 +00:00
}
2007-11-23 15:49:00 +00:00
2008-06-02 21:02:52 +00:00
$DB -> commit_sql ();
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
// we are done now, a bit of housekeeping
fix_course_sortorder ();
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
$this -> enrol_disconnect ( $enroldb );
return true ;
}
2004-08-14 12:47:24 +00:00
/// Overide the get_access_icons() function
function get_access_icons ( $course ) {
}
2004-09-23 17:02:40 +00:00
/// Overide the base config_form() function
2004-08-21 17:15:07 +00:00
function config_form ( $frm ) {
global $CFG ;
2005-02-08 17:56:22 +00:00
2007-09-21 11:02:30 +00:00
$vars = array ( 'enrol_dbhost' , 'enrol_dbuser' , 'enrol_dbpass' ,
'enrol_dbname' , 'enrol_dbtable' ,
'enrol_localcoursefield' , 'enrol_localuserfield' ,
2005-02-08 17:56:22 +00:00
'enrol_remotecoursefield' , 'enrol_remoteuserfield' ,
2007-09-21 11:02:30 +00:00
'enrol_db_autocreate' , 'enrol_db_category' , 'enrol_db_template' ,
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.
2006-09-26 01:30:32 +00:00
'enrol_db_localrolefield' , 'enrol_db_remoterolefield' ,
2007-07-20 13:03:19 +00:00
'enrol_remotecoursefield' , 'enrol_remoteuserfield' ,
2007-11-21 11:06:46 +00:00
'enrol_db_ignorehiddencourse' , 'enrol_db_defaultcourseroleid' ,
'enrol_db_disableunenrol' );
2006-03-09 02:48:29 +00:00
2005-02-08 17:56:22 +00:00
foreach ( $vars as $var ) {
if ( ! isset ( $frm -> $var )) {
$frm -> $var = '' ;
2007-09-21 11:02:30 +00:00
}
2005-02-08 17:56:22 +00:00
}
2004-08-21 17:15:07 +00:00
include ( " $CFG->dirroot /enrol/database/config.html " );
}
/// Override the base process_config() function
function process_config ( $config ) {
if ( ! isset ( $config -> enrol_dbtype )) {
$config -> enrol_dbtype = 'mysql' ;
}
set_config ( 'enrol_dbtype' , $config -> enrol_dbtype );
if ( ! isset ( $config -> enrol_dbhost )) {
$config -> enrol_dbhost = '' ;
}
set_config ( 'enrol_dbhost' , $config -> enrol_dbhost );
if ( ! isset ( $config -> enrol_dbuser )) {
$config -> enrol_dbuser = '' ;
}
set_config ( 'enrol_dbuser' , $config -> enrol_dbuser );
2004-08-14 12:47:24 +00:00
2004-08-21 17:15:07 +00:00
if ( ! isset ( $config -> enrol_dbpass )) {
$config -> enrol_dbpass = '' ;
}
set_config ( 'enrol_dbpass' , $config -> enrol_dbpass );
2004-08-14 12:47:24 +00:00
2004-08-21 17:15:07 +00:00
if ( ! isset ( $config -> enrol_dbname )) {
$config -> enrol_dbname = '' ;
}
set_config ( 'enrol_dbname' , $config -> enrol_dbname );
if ( ! isset ( $config -> enrol_dbtable )) {
$config -> enrol_dbtable = '' ;
}
set_config ( 'enrol_dbtable' , $config -> enrol_dbtable );
if ( ! isset ( $config -> enrol_localcoursefield )) {
$config -> enrol_localcoursefield = '' ;
}
set_config ( 'enrol_localcoursefield' , $config -> enrol_localcoursefield );
if ( ! isset ( $config -> enrol_localuserfield )) {
$config -> enrol_localuserfield = '' ;
}
set_config ( 'enrol_localuserfield' , $config -> enrol_localuserfield );
if ( ! isset ( $config -> enrol_remotecoursefield )) {
$config -> enrol_remotecoursefield = '' ;
}
set_config ( 'enrol_remotecoursefield' , $config -> enrol_remotecoursefield );
if ( ! isset ( $config -> enrol_remoteuserfield )) {
$config -> enrol_remoteuserfield = '' ;
}
set_config ( 'enrol_remoteuserfield' , $config -> enrol_remoteuserfield );
2006-01-16 03:10:39 +00:00
if ( ! isset ( $config -> enrol_db_autocreate )) {
$config -> enrol_db_autocreate = '' ;
}
set_config ( 'enrol_db_autocreate' , $config -> enrol_db_autocreate );
2007-09-21 11:02:30 +00:00
2006-01-16 03:10:39 +00:00
if ( ! isset ( $config -> enrol_db_category )) {
$config -> enrol_db_category = '' ;
}
set_config ( 'enrol_db_category' , $config -> enrol_db_category );
if ( ! isset ( $config -> enrol_db_template )) {
$config -> enrol_db_template = '' ;
}
set_config ( 'enrol_db_template' , $config -> enrol_db_template );
2004-08-21 17:15:07 +00:00
2006-09-19 16:29:43 +00:00
if ( ! isset ( $config -> enrol_db_defaultcourseroleid )) {
$config -> enrol_db_defaultcourseroleid = '' ;
}
set_config ( 'enrol_db_defaultcourseroleid' , $config -> enrol_db_defaultcourseroleid );
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.
2006-09-26 01:30:32 +00:00
if ( ! isset ( $config -> enrol_db_localrolefield )) {
$config -> enrol_db_localrolefield = '' ;
}
set_config ( 'enrol_db_localrolefield' , $config -> enrol_db_localrolefield );
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
if ( ! isset ( $config -> enrol_db_remoterolefield )) {
$config -> enrol_db_remoterolefield = '' ;
}
set_config ( 'enrol_db_remoterolefield' , $config -> enrol_db_remoterolefield );
2007-07-20 13:03:19 +00:00
if ( ! isset ( $config -> enrol_db_ignorehiddencourse )) {
$config -> enrol_db_ignorehiddencourse = '' ;
}
set_config ( 'enrol_db_ignorehiddencourse' , $config -> enrol_db_ignorehiddencourse );
2007-11-21 11:06:46 +00:00
if ( ! isset ( $config -> enrol_db_disableunenrol )) {
$config -> enrol_db_disableunenrol = '' ;
}
set_config ( 'enrol_db_disableunenrol' , $config -> enrol_db_disableunenrol );
2006-09-19 16:29:43 +00:00
return true ;
2004-08-21 17:15:07 +00:00
}
2004-08-14 12:47:24 +00:00
2006-01-16 03:08:50 +00:00
// will create the moodle course from the template
// course_ext is an array as obtained from ldap -- flattened somewhat
2007-09-21 11:02:30 +00:00
// NOTE: if you pass true for $skip_fix_course_sortorder
2006-01-16 03:08:50 +00:00
// you will want to call fix_course_sortorder() after your are done
// with course creation
function create_course ( $course , $skip_fix_course_sortorder = 0 ){
2008-06-02 21:02:52 +00:00
global $CFG , $DB ;
2006-01-16 03:08:50 +00:00
// define a template
2008-06-16 14:25:53 +00:00
if ( ! empty ( $CFG -> enrol_db_template )){
2008-06-02 21:02:52 +00:00
$template = $DB -> get_record ( " course " , array ( 'shortname' => $CFG -> enrol_db_template ));
2006-01-16 03:08:50 +00:00
$template = ( array ) $template ;
} else {
$site = get_site ();
$template = array (
'startdate' => time () + 3600 * 24 ,
'summary' => get_string ( " defaultcoursesummary " ),
'format' => " weeks " ,
'password' => " " ,
'guest' => 0 ,
'numsections' => 10 ,
'idnumber' => '' ,
'cost' => '' ,
'newsitems' => 5 ,
'showgrades' => 1 ,
'groupmode' => 0 ,
'groupmodeforce' => 0 ,
);
}
// overlay template
foreach ( array_keys ( $template ) AS $key ) {
if ( empty ( $course -> $key )) {
$course -> $key = $template [ $key ];
}
2007-09-21 11:02:30 +00:00
}
2008-06-16 14:25:53 +00:00
$category = get_course_category ( $CFG -> enrol_db_category );
2006-01-16 03:08:50 +00:00
2008-06-16 14:25:53 +00:00
// put at the end of category
$course -> sortorder = $category -> sortorder + MAX_COURSES_IN_CATEGORY - 1 ;
2006-01-16 03:08:50 +00:00
// override with local data
$course -> startdate = time () + 3600 * 24 ;
$course -> timecreated = time ();
$course -> visible = 1 ;
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
// clear out id just in case
2007-09-21 11:02:30 +00:00
unset ( $course -> id );
2006-01-16 03:08:50 +00:00
// truncate a few key fields
$course -> idnumber = substr ( $course -> idnumber , 0 , 100 );
2007-08-08 19:39:56 +00:00
$course -> shortname = substr ( $course -> shortname , 0 , 100 );
2006-01-16 03:08:50 +00:00
// store it and log
2008-06-02 21:02:52 +00:00
if ( $newcourseid = $DB -> insert_record ( " course " , $course )) { // Set up new course
2008-06-16 14:25:53 +00:00
$section = new object ();
$section -> course = $newcourseid ; // Create a default section.
2006-01-16 03:08:50 +00:00
$section -> section = 0 ;
2008-06-02 21:02:52 +00:00
$section -> id = $DB -> insert_record ( " course_sections " , $section );
2009-05-08 08:22:59 +00:00
$course = $DB -> get_record ( 'course' , array ( 'id' => $newcourseid ));
blocks_add_default_course_blocks ( $course );
2006-01-16 03:08:50 +00:00
2008-06-16 14:25:53 +00:00
if ( ! $skip_fix_course_sortorder ){
2007-09-21 11:02:30 +00:00
fix_course_sortorder ();
2006-01-16 03:08:50 +00:00
}
add_to_log ( $newcourseid , " course " , " new " , " view.php?id= $newcourseid " , " enrol/database auto-creation " );
} else {
trigger_error ( " Could not create new course $extcourse from from database " );
notify ( " Serious Error! Could not create the new course! " );
return false ;
}
2007-09-21 11:02:30 +00:00
2006-01-16 03:08:50 +00:00
return $newcourseid ;
}
2006-01-16 03:03:21 +00:00
/// DB Connect
/// NOTE: You MUST remember to disconnect
/// when you stop using it -- as this call will
2008-06-05 20:35:28 +00:00
/// sometimes modify table prefix for the whole of Moodle!
2006-01-16 03:03:21 +00:00
function enrol_connect () {
global $CFG ;
2007-01-11 20:08:00 +00:00
// Try to connect to the external database (forcing new connection)
2006-01-16 03:03:21 +00:00
$enroldb = & ADONewConnection ( $CFG -> enrol_dbtype );
2007-01-11 20:08:00 +00:00
if ( $enroldb -> Connect ( $CFG -> enrol_dbhost , $CFG -> enrol_dbuser , $CFG -> enrol_dbpass , $CFG -> enrol_dbname , true )) {
2006-11-13 22:49:30 +00:00
$enroldb -> SetFetchMode ( ADODB_FETCH_ASSOC ); ///Set Assoc mode always after DB connection
2006-01-16 03:03:21 +00:00
return $enroldb ;
} else {
2006-01-16 03:03:59 +00:00
trigger_error ( " Error connecting to enrolment DB backend with: "
. " $CFG->enrol_dbhost , $CFG->enrol_dbuser , $CFG->enrol_dbpass , $CFG->enrol_dbname " );
2006-01-16 03:03:21 +00:00
return false ;
2007-09-21 11:02:30 +00:00
}
2006-01-16 03:03:21 +00:00
}
/// DB Disconnect
function enrol_disconnect ( $enroldb ) {
global $CFG ;
$enroldb -> Close ();
}
2004-08-14 12:47:24 +00:00
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.
2006-09-26 01:30:32 +00:00
/**
* This function returns the name and value of the role field to query the db
* for , or null if there isn ' t one .
*
* @ param object The ADOdb connection
* @ param object The role
* @ return array ( boolean , string , db quoted string )
*/
function role_fields ( $enroldb , $role ) {
global $CFG ;
2007-09-21 11:02:30 +00:00
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.
2006-09-26 01:30:32 +00:00
if ( $have_role = ! empty ( $role )
&& ! empty ( $CFG -> enrol_db_remoterolefield )
&& ! empty ( $CFG -> enrol_db_localrolefield )
&& ! empty ( $role -> { $CFG -> enrol_db_localrolefield })) {
$remote_role_name = $CFG -> enrol_db_remoterolefield ;
$remote_role_value = $enroldb -> quote ( $role -> { $CFG -> enrol_db_localrolefield });
} else {
$remote_role_name = $remote_role_value = null ;
}
return array ( $have_role , $remote_role_name , $remote_role_value );
}
2004-08-14 12:47:24 +00:00
} // end of class
?>
