The Enrollment Process

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

Batter's Up!

The process is kicked off by Moodle cron. UES creates an enrollment provider plugin from a list of installed plugins, and uses this plugin as its knowledge to the enrollment information storage. The storage could be a file, database, web service, etc.

Provisioning

With the created enrollment provider, UES starts provisioning while conforming to a concrete workflow:

Workflow

• Semesters are provisioned
• Courses and Sections are provisioned
• Teachers are provisioned to sections
• Students are provisioned to sections
• Courses are created and users are enrolled
• Current enrollment is compared, and un-provisioned users are unenrolled
• Teacher enrollment is compared, and fires ues_section_primary_change to be handled
• Un-provisioned sections are hidden

Manifestation

UES calls converting provisioned data into Moodle data (courses, role assignments, etc), Manifestation.

The system couples provisioning and manifestation by default, but there are ways to control creation and enrollment by handling events through extensions by changing a section, teacher, or student status.

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 item's status is changed to processed. The event corresponding to the item is fired. The handler of this event can check that requirements are met, and simply change 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 delegated to a 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.