The Enrollment Process

The UES enrollment process is explained to varying degree of detail in this article.

Batter Up!

The process is executed as a Moodle Scheduled Task. The task can be managed by going to Site administration -> Server -> Scheduled tasks (frequency, active status). UES creates an enrollment provider plugin from a list of installed plugins, and uses this plugin as its interface to the enrollment database. The database could be a file, RDBMS, web service, etc.

Provisioning

With the enrollment provider created, UES starts provisioning enrollment.
Here, Provisioning means filling the UES DB tables with data from the provider.
This process conforms to a concrete workflow:

Workflow

• Provision Semesters
• Provision Courses and Sections
• Provision Teachers to sections
• Provision Students to sections
• Create courses and enroll users
• Compare current enrollment with incoming enrollment data, un-enroll students NOT IN the new dataset
• Compare current teacher enrollment with incoming enrollment data, and when differences exist, update enrollment and fire ues_section_primary_change event.
• Un-provisioned sections are hidden

Manifestation

Manifestation is the process by which UES converts Provisioned data into Moodle data (courses, role assignments, etc).

During each run, stored sections, teachers, and student statuses are marked as pending for each provisioned semester. Once the item is provisioned (section, student, teacher), the its status is changed to processed, and the ues_<item-type>_processed is fired.

The system couples provisioning and manifestation, by default.
By handling UES events, UES extensions, like CPS, can control creation and enrollment by changing section, teacher, or student status. Event handlers can check that requirements are met, and if not, simply reset the status back to pending. For example: the CPS extension uses this for unwanted sections / courses, or course creation and enrollment.

The processed status means that manifestation will occur. Users that remain pending when manifestation occurs will be unenrolled. A successful manifestation will result in the corresponding status:

• sections become manifested or skipped
• teachers become enrolled or unenrolled
• students become enrolled or unenrolled

####Recap status changes:

• sections are marked pending before provisioning, marked processed upon provisioning, marked manifested upon Moodle creation or skipped if a section remains pending after processing.
• students and teachers are marked pending before provisioning, marked processed upon provisioning, marked enrolled upon Moodle enrollment or unenrolled if a teacher remains pending after processing.

What does this mean?

There are some major benefits by abstracting specific enrollment behaviors from the main enrollment process:

• The actual enrollment process is very simple.
• Debugging strange enrollment issues can now be focused on the UES extension block or module with the custom code.
• The enrollment module is not coupled to system or user creation / enrollment settings.

Some cons:

• The enrollment process could become very complicated, if multiple blocks or modules handled the events in conflicting ways.
• Overwriting behaviors must become a program.