Plugin API

UES enrollment plugin providers provide enrollment information to the enrollment process. A plugin is split into a collection of modules:

• Multiple processors
• A single provider (processor factory)

The Processor

A processor has a single purpose: to fetch specific enrollment information from an external source. There are seven types of processor interfaces that each massage the pulled information:

• semester_processor: returns a collection of semesters given a certain time.
• course_processor: returns a collection of courses and sections given a certain semester
• teacher_processor: returns a collection of teacher enrollment given a certain section
• student_processor: return a collection of student enrollment given a certain section
• teacher_by_department: returns a collection of teacher enrollment given a certain department and semester
• student_by_department: returns a collection of student enrollment given a certain department and semester
• teacher_info_processor: returns section information for a given teacher and semester

The interfaces can be found at the ues/classes/processors.php

A UES enrollment provider must provide a valid implementation for teacher_source and student_source or teacher_department_source and student_department_source. A Moodle admin can choose which method to use in the cron settings.

Note: A teacher_info_processor is not required by the enrollment process. The public API takes advantage of providers who can return this processor for the reprocess_for reprocess method.

The Provider

A provider acts as a processor factory, with a _source method for each processor. In this manner, a developer could potentially aggregate sources or mix and match processor components.

UES can call on providers to pull one of two ways:

1. By department
2. By section

Providers must implement one of the two ways. If a provider returns false to either supports_department_lookups or supports_section_lookups, then the UES will error upon creating the provider.

A custom provider must inherit from an enrollment_provider. A great example implementation is the lsu provider. For a more bare bones implementation, have a look at the example plugin.

For more deeper look, check out the enrollment_provider source.

Preprocess and Postprocess

A provider can implement two hooks that further massage or aggregate data that goes beyond the scope of UES. These hooks are called before and after the enrollment process, preprocess and postprocess, respectively.

Note: These hooks must return a boolean, false on failure and true on success. It is recommended to push any errors as a custom, ues_error for automatic error handling. Be nice to the users.

Injecting Admin Settings

Often times, the developer may want to delegate certain configuration settings to the Moodle admin, such as a web service url or credentials.

The provider can create admin configuration elements from two methods settings and adv_settings. A provider can override both.

1. The settings method returns an associative array containing the setting key and a default value. It is important to note that UES will generate textbox configs from these settings.

2. The adv_settings method returns a collection of Moodle admin config UI elements. These include headings, textboxes, checkboxes, dropdowns, etc.