PRGF5100 - Maintain Progression Rule

Purpose

To create and maintain Progression Rules for use within the institution

SubSystem

Progression

Normally Run By Administration Specialist
Anticipated Frequency As required
Structure  Block Progression Rule
Buttons Edit Rule (RULF2000)
Progression Calendars (overlay)
Progression Outcomes (PRGF5214)
Rule Summary (overlay)

 

Progression Rules may be general application Progression Rules that are used in many Progression Periods and at one or more levels of the institution (e.g. for more than one Organisational Unit). This form is used to create and maintain this pool of general application Progression Rules - defining and constructing the rule and assigning both Progression Calendars and outcomes to it.

Each rule is defined by a Rule Category, Rule Code, Description and the Rule Text. When constructing the Rule Text (in RULF2000 accessed via the button), the available rule options are determined by the Rule Category selected when defining the rule. For example if a rule is assigned an institution-defined Rule Category mapped to the System Rule Call Code PRG-GPA, this means that the rule options available are those that measure progress using a student's Grade Point Average.

A Progression Rule (even when it has associated Calendars & Outcomes) does not initiate Progression checking until it is assigned to a Progression application system element (Course Type; Organisational Unit; Course Version, Student Course Attempt) in form PRGF5200.

The second type of Progression Rules is the 'application-specific' rules. These are defined only in the context of the System element to which the rule is to apply (and not available to be linked to any other System element). Rules of this type are created at the rule application level using form PRGF5200.

The concepts underlying these two types of Progression Rules are explained in the Progression Rules Overview.

 

The Progression Rule block contains:

  • Rule Category
  • Rule Code
  • Description
  • Closed check box
  • Rule Text
  • Message

    Buttons

    • Edit Rule (RULF2000)
    • Progression Calendar (overlay)
      • Calendar Type
      • Start Period
      • End Period
      • Student Start Period
      • Applications
      • Back button
    • Progression Outcomes (PRGF5214)
    • Rule Summary (overlay)
      • Progression Rule Summary block
        • Rule Category
        • Rule Code
        • Rule Text
        • Message
      • Progression Rule Calendar Type block
        • Calendar Type
        • Student Start Period
        • Applications
      • Progression Rule Outcome block
        • Failures
        • Outcome Type
        • Duration
        • Back button

Rules/Notes:

The Edit Rule button links to RULF2000 (Maintain Rule).

The Progress Outcomes button links to PRGF5214 (Maintain Progression Rule Outcome).

Select / enter the required Rule Category. Institution-defined rule categories are maintained in PRGF1600.

Enter the Rule Code and Description. Each rule must have a unique Rule Code / Rule Category combination.

Navigate to RULF2000, to create or modify the rule. On return to this form, the Rule Text box displays the resulting rule. Text cannot be altered in this box.

A Lamp is displayed to indicate that a rule is linked to a rule application. Modifying a rule that is linked to a rule application should be done with caution.

The Message field can be used to fully describe the context Rule - where it is intended to apply; the Progression Periods and outcomes linked to it.

Rules/Notes:

The Rule Category and Rule Code of an existing rule cannot be altered.

Closed Rule Categories cannot be used when creating a Progression Rule.

A rule that has been linked to an application or used in measuring progression cannot be deleted. Close obsolete rules to prevent their future use.

Assigning a Progression Calendar / Outcomes to A Rule:

Progression Calendars and/or outcomes can be assigned to a Progression Rule. This means that in the application of this Progression Rule, the assigned Progression Periods / dates (identified through the selected calendar/s) and outcomes are used by default, unless overridden at the application level.

The Rule Category used in defining this rule, may have existing calendar / outcome defaults. Use the Rule Summary overlay to view any existing defaults assigned to the category.

For more detailed explanation about the levels of application, refer to Progression Rules Overview.

Rules/Notes:

Default Calendars or Outcomes set here override settings at the Progression Rule Category level (in PRGF1600).

Calendars and Outcomes assigned at this level (to a rule), can be overridden at a rule application level (in PRGF5200).

To assign a calendar to the context rule:

Select or enter a Progression Calendar Type, in the Progression Rule Calendar overlay.

The following limits on the application of the rule, within that calendar, can be applied:

  • Start Period - can be nominated where this rule is to start at a point in the future. Without this limit, the application of a rule begins when the rule is linked to an application element.
    The List of Values displays the available Start Periods as a concatenation of the year of the Calendar Instance and the Alternate Code for the Progression Calendar Type e.g. 2003/P1.
  • End Period - can be nominated (at any time after the defining of the rule) to End-Date this rule, within the given Calendar Type. The rule may still be active under other rule applications that override this end dating at the rule level.
    The List of Values displays End Periods in the same way as Start Periods, e.g. 2004/P1
  • Student Start Period - enter a number, representing the Progression Period at which, for a given student, this rule application can begin
  • Applications - nominated to restrict the number of times this rule can be applied to a particular student - e.g. if 2 is entered, this rule can be applied to a student for 2 Progression Periods only.

Rules/Notes:

A Calendar Type can be assigned to a rule, with no limiting values entered.

Calendars inherited from the Rule Category may have had limit set that are not required for this rule. Re-assign the Calendar to the rule, without those limits (enter new limits if required).

A Calendar Type assigned to a Rule cannot be deleted after rule testing for this rule and Calendar Type has begun.

Where Calendar Instances are entered in the Start / End Period fields, they must be ACTIVE instances.

Any entry in the Student Start Period or Applications field must be a number >=1.

The Start Period value cannot be modified after rule testing for this rule and Calendar Type has begun.

To assign an outcome to the context rule:

Navigate to the Maintain Progression Rule Outcome form (PRGF5214), using the Progression Outcomes button.

 

 

To view a summary of the assigned calendars & outcomes for this Rule:

The Rule Summary overlay can be opened using the button. This displays summary information for all Calendar Types and outcomes currently assigned to this rule.

A lamp displays in each block on this pop-up screen to indicate the origin of the link between the Rule, Calendars and Outcomes. The CATEGORY lamp notifies inheritance from the Rule Category. The RULE lamp notifies the link was made between Calendar/Outcome at this level.

Calendar Type, Student Start Period and Applications are displayed for each assigned Calendar Type.

For each assigned outcome, the following details are displayed.
Failures - displays the number of rule failures and the Repeat Failure Type to which the outcome is to apply e.g. 1/REPEAT.
Outcome Type.
Duration - where applicable (not all outcomes have duration values) displays both the number and type of duration periods for which the outcome is to apply e.g. 2/NORMAL.

Rules/Notes:

The assigned Calendars and Outcomes cannot be altered in this overlay.
Modify the assigned Calendars using the
Progression Rule Calendar overlay.
Modify the assigned Outcomes using the
Maintain Progression Rule Outcome form.

WARNING! After initial implementation, modifications to the configuration of the Progression Subsystem should be made with care and after thorough examination of the implications of the planned change.

 

 

 

Last Modified on 11 March, 2004