The Enrollment Process

The UES enrollment process is tied directly to the provisioning process.

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

Controlling Creation

The system couples provisioning, creation, and enrollment by default, but there are ways to control creation and enrollment by handling events and 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. The CPS extension uses this for unwanted sections / courses, or course creation and enrollment.

The processed status means action will be taken (course created and enrolled). Users that remain pending when action is taken means they will be unenrolled. A successful action 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.