Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Conditional activities

From MoodleDocs

This is a developer's page for Moodle Version 2.0, describing an evolving specification. UNDER CONSTRUCTION!

Conditional activities allow the course editor to hide certain activities until conditions on other activities have been met.

For example, a student will not see Assignment B until they have scored 80% or higher on Quiz A.

Objectives

  1. We want to know when activities are finished (for each user independently)
  2. We want to have this calculated automatically, but also manually if required.
  3. We want other some activities to be hidden until other activities are done.
  4. We want to "chain" these things into learning paths.
  5. We want the course page to remain fast.
  6. We want conditional activities to be optional.

Overview

There are two main approaches to this. For the discussion below let's use A to mean a source activity, and B and C to mean two activities that are only available when A is done.

Approach 1: The one used by activity locking is to place the UI to choose the conditions in B, so that it specifies the passing grades etc that are needed for A so that B is unlocked. This has advantages in that B can specify a different passing grade that C (both on the same A).

Approach 2: This places the logic in A, so that it defines when it is "done" any way it likes and B can just say "I'm available when A is done". The advantages here are that A can define "done" in any way it likes, and the configuration can be more subtle if the module wants it.

The approach described below actually combines BOTH these approaches so it should please everyone and allow the maximum flexibility.

Interfaces

Site settings

Admins can turn Conditional Activities on/off for the whole site.

Course settings

Teachers can choose between three states for a course:

  1. Conditional Activities off
  2. Conditional Activities Manual
  3. Conditional Activities Auto

Course page

For teachers

  • Each activity will have an icon indicating the status, and clicking on it takes you to the activity settings (see below). These are also available as a tab from the main activity pages.

For students

  • Colour icons (checkboxes) in red/orange/green down the side of the course format indicate the status of each activity
  • In manual mode, these can be clicked on to toggle the status as required (so that students can manually keep track of what they've done).
  • In auto mode, these icons are fixed

Activity settings

When the teacher is editing the activity settings for each activity, they see two parts to the page:

This activity will be available when ...

The UI here is standard for all modules. (Settings are stored in the course_modules_avail table.) It shows all the other activities in the course, and beside each of them are menus to choose from:

  • Grade >= X (<, <=, >= and >)
  • Viewed
  • Completed (as defined by that activity)

Sam marshall Should also include date as a condition. This may complicate the design slightly as obviously date is not a per-other-activity option

This activity will be completed when ...

This UI shows optional settings for this activity to define when it thinks it is finished. (Settings are stored in course_modules_done table):

  • Grade >= X (<, <=, >= and >)
  • Viewed
  • Something else (interface defined by module)

Sam marshall Just wondering, how are you going to track 'viewed'? Modules don't store this in a sensible way, only in the log table.

Tables

course_modules_completion

This table records the status of each user completing each activity module. It represents current state and is used to make the display of course pages very fast. It is updated whenever grades or modules change etc.

  • id
  • courseid - just here for speed
  • cmid - FK to course_modules
  • userid
  • status - hide / not done / in progress / done fail / done pass
  • timemodified


course_completion

This table records when whole courses are completed.

  • id
  • userid
  • courseid
  • status

course_modules_avail

Records settings for availability

  • id
  • cmid - the activity that is defining the condition
  • cmsourceid - the activity we are checking
  • gradesign - <, >, <=, => etc
  • gradecutoff
  • views - boolean
  • modulespecific - boolean

course_modules_done

Records settings for whether something is done

  • id
  • cmid
  • gradesign - <, >, <=, => etc
  • gradecutoff
  • views - boolean

Process

Coming soon


Issues to think about

  • How do we cope with circular references?
  • We should remove conditions when activities are deleted - how does that affect things downstream?


See also

  • Tracker reference(s) for conditional development _____________