Note:

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

Linked activities: Difference between revisions

From MoodleDocs
Line 14: Line 14:


=== Level 0: Save as another ===
=== Level 0: Save as another ===
We could add button "Save as another <modulename>" on module editing screen, allowing quickly create an instance of the module with similar settings. That doesn't help much after creating an instance.
We could add button "Save as another <modulename>" on module editing screen, allowing quickly create an instance of the module with similar settings. That doesn't help much after creating an instance. MDL-18093 is an improvment request for this.
 
This is far better than backup/restore because:
# It takes much less clicks/page loads, and this is quite a matter when you whant 7-10 activities with similar settings
# It copies settings, not content. That is useful when you have a set of similar activities (quizzes, assignments etc) for each topic (or almost each) in the course. Which is quite often.


=== Level 1: Bulk activities editing ===
=== Level 1: Bulk activities editing ===

Revision as of 17:46, 3 February 2009

In large courses we often find a sets of similar activities (quizzes, assignments and so on), which share many settings (i.e. module settings) - but not all, of course. Maintaining of such sets is quite a pain: imagine youself adding a new IP range on 6-10 quizzes. So we need an usable and robust way to handle such sets - linked activities.

This page is to discuss and find a better way to do so.

Let's call the setting some parameter of course module instance. Setting isn't necessary one control on the form (it may be a group of related controls, check boxes for example). Setting may be a field in db, or not - needs thinking.

A set is a group of course module instances, that share common settings.

Issues

  • linked activities may need to response on editing one of them (and deleting), so they need an events on these occasion. Anyone interested please vote for MDL-16203.
  • modules now handle settings (from form to db and from db to form) in a bulk, there is no way to say the module "please save in db (or show on the form) this setting and not leave others be". It's possible to do this without module help, but if module can map individual settings to db/form(controls) it would help.

Interface

Level 0: Save as another

We could add button "Save as another <modulename>" on module editing screen, allowing quickly create an instance of the module with similar settings. That doesn't help much after creating an instance. MDL-18093 is an improvment request for this.

This is far better than backup/restore because:

  1. It takes much less clicks/page loads, and this is quite a matter when you whant 7-10 activities with similar settings
  2. It copies settings, not content. That is useful when you have a set of similar activities (quizzes, assignments etc) for each topic (or almost each) in the course. Which is quite often.

Level 1: Bulk activities editing

This doesn't require DB change, and hopefully can be done in 1.9 too.

Step 1: Select a group of similar activities to edit

This can be done adding a column of check boxes to the index.php page of the module (and placing button to bulk editing below) - the way quiz attempt management working now.

By the way it would be good to centralize index.php handling, placing code identical for most modules (i.e. header, footer, number of rows, first column and new checkboxes) in one place, leaving module to define custom columns only. This'll help reduce code duplication and make it easy to add new capabilities to all modules.

Questions:

  1. Assignment and resource modules have subtypes. Should we allow bulk editing on subtypes only, or if several subtypes are selected editing should be restricted to common fields?

Step 2: Select settings and fill module form

This'll require to change base moodleform_mod class to allow new functionality: it must recognise is it used to normal or bulk editing. On bulk editing some fields (name at least) will be replaced by a fields to control which settings to apply (we don't need to change all settings in bulk mode) and activate relevant controls on the screen.

Module code must also be changed to tell us what settings are, and update_instance should be ready to update not all, but different settings.

Questions:

  1. Should we use multi-select menu or a set of checkboxes to determine which settings we are editing?
  2. Should name and description fields be subject to a bulk editing? Sometimes teachers create activities with identical names (relying on the section name), but this isn't a good practice.

Level 2: Sets of activities

On this level system would be able to store sets of related instances and provide a one-click link to edit them. This'll require new db tables, so it probably 2.0 only.

There must be a block which displays a sets as a links to edit them, and new controls on index.php page to create (manage?) sets.

If events on update instance would be fired, than it is possible to have sets which are automatically update some settings whenever one of the activities in set are updated.

Architecture