-
Notifications
You must be signed in to change notification settings - Fork 1
Public API
The enrollment module gives the developer working on outside plugins a way to interact directly with the enrollment process through the public API, synonymously, the ues
object.
If you would rather look at the source, all of the public functions are conveniently located in publiclib.php
- Include UES library code
- Generate string generator function
- Reprocessing Enrollment
- by Moodle course
- by individual sections
- by department
- Manipulating Enrollment
- Handle errors
- Drop semesters
This is especially useful for developers working on plugins or extensions of their own.
-
require_daos
: includes UES dao's and base classes -
require_extensions
: include UES provider and processor base classes -
require_libs
: includes UES dao's and provider base classes
Even calls to get_string
can become verbose quickly. UES provides the ability to make things simpler.
-
str_gen
: creates aget_string
partially applied function to the plugin in question
$_s = ues::str_gen("my_block");
$_s("pluginname");
// equivalent to get_string("pluginname", "my_block");
The enrollment module is scheduled to run daily somewhere in the hour of your choosing in cron. By this time, new enrollment information may be available. To reprocess a course on demand (fetches new enrollment from the provider and performs enrollment):
$errors = ues::reprocess_course($course); // Done
The following reprocess functions are available:
-
reprocess_course
takes in a Moodle course -
reprocess_department
takes in aues_course
and aues_semester
-
reprocess_sections
takes in a collection ofues_section
s -
reprocess_for
takes in aues_teacher
, and reprocesses all section for him / her
Note: reprocess_for
will only work if the provider supports_reverse_lookups
.
-
enroll_users
: Creates Moodle role assignments that match the UES tables -
unenroll_users
: Drops Moodle role assignments that match the UES tables -
inject_manifest
: Unenrolls and then enrolls specific sections using a certain manifest
Outside systems may add or modify how Moodle data is representing the enrollment data (the enrollment process is actually very simple).
$sections = ues_section::from_course($course);
// Going to unenroll everyone
ues::unenroll_users($sections);
// Going to re-enroll everyone
ues::enroll_users($sections);
A common idiom is: unenroll users, do some work, enroll users / create courses. The inject_manifest
function takes care of this for you.
ues::inject_manifest($sections, function($section) use ($newid) {
$section->idnumber = $newid;
});
Why call it inject_manifest? When called in such a way, that is exactly what the public API is doing for you.
The ues
objects provides a way to reprocess selected errors.
$errors = ues_error::get_all(array("name" => "custom"));
$receive_report = true;
ues::reprocess_errors($errors, $receive_report);
$dead_semester = ues_semester::get(...);
ues::drop_semester($dead_semester);
This will not only remove the UES semester and data associated with but call the appropriate events for extensions tied to this data.