Course Publishing block (publishflow): Difference between revisions

From MoodleDocs
Line 44: Line 44:
* ''Making a transportable archive:'' The course needs to be backup WITHOUT ANYTHING RELATIVE TO USERS to be tranportable. The bloc provides a control to make such an archive in "two clicks" process.
* ''Making a transportable archive:'' The course needs to be backup WITHOUT ANYTHING RELATIVE TO USERS to be tranportable. The bloc provides a control to make such an archive in "two clicks" process.
* ''Publish:'' Publishing a course to a remote Course Catalog chossing the target Moodle within the list of available targets.
* ''Publish:'' Publishing a course to a remote Course Catalog chossing the target Moodle within the list of available targets.
* ''Deploy for test:'' As widely required by our peer teachers, the possibility to deploy directly from a Factory to a Training Center an unpublished, yet to validate, course content is possible.


===Within a Course Catalog Moodle===
===Within a Course Catalog Moodle===

Revision as of 17:09, 28 September 2012


The Publishflow block implements a complete course tranport and publishing architecture over the Moodle Network. The block provides a mean to publish, deploy or retrofit course archives from inside the course space itself. Publishing, deploying or retrofitting a course to a working platform use the same course transport infrastructure that operates through the network or via the local filesystem.

course life cycle.jpg

Moodle site types (regarding publishing concerns)

The course publishing architecture conceptually introduces three typical assignation to a Moodle application :

  • The Course Factory concept: A Course Factory is a Moodle instance where courses are designed and tested, but where non real training is performed. Courses can be set visible so promoting a cooperative work of the whole pedagogic operators. Courses can be exposed even if not complete or still in work, without depreciating the global e-Learing system apparent value.
  • The Course Catalog concept: A Course Catalog is a Moodle instance that stores and exposes full features course volumes, as the result of a production process. A Course Catalog should not be the place where to perform real training, although nothing forbids really real use of courses there.
  • The Training Instance concept: More commonly assignable to a "standard Moodle" concept, but being able to be fed with course volumes got from a Course Catalog. The Training Instances are targets for course deployment.

Each of this general Moodle site role in the publishing network can be quickly setup by a site level preference of the Publishflow bloc. (See Global Settings)

Assembling these three concepts may allow to constitute complex Moodle based architectures answering a publishing metaphoric model.

Read more about topologic discussion and possibilities

Publication use cases

  • Course publishing: Publishing a course is making the course volume available for use by the Traning Centers.
  • Course deployment: Deploying a course is copying an instance of a course to get a workable course session with students.
  • Course retrofitting: Retrofitting a course brings back a copy of an updated course volume to a factory for starting a new design and publishing process.

Course transportation principles

Course archives are being transported from a Moodle to another Moodle using the bublishflow simple publishing use cases. There are three transporting modes that a publishflow can operate:

Using the local file system

This is the fastest one. The course archive is picked up from one Moodle within the moodledata container of the source Moodle. This allows quite big size transportation in a very fast way, but of course needs the filesystem to be the same (or network mounted) between both Moodle instances. This is fully operable on a Virtualized Moodle installation.

Using MNET back call

Using MNET back call will transport the material through a Moodle MNET XMLRPC operation. This allows transporting Moodle archives between distinct physical servers an filesystems, but has a size limitation of about 40Mo due to XMLRPC encoding library breakdown.

Using simple HTTP back call

If the course archive does not need to be so protected during transport, the publishflow bloc envisages using a simple HTTP call to get the archive.

this is still to be implemented.

Bloc Features

Within a Course Factory Moodle

  • Indexing: The course needs to be indexed (ie : having a non empty IDNumber to track published copies).
  • Making a transportable archive: The course needs to be backup WITHOUT ANYTHING RELATIVE TO USERS to be tranportable. The bloc provides a control to make such an archive in "two clicks" process.
  • Publish: Publishing a course to a remote Course Catalog chossing the target Moodle within the list of available targets.
  • Deploy for test: As widely required by our peer teachers, the possibility to deploy directly from a Factory to a Training Center an unpublished, yet to validate, course content is possible.

Within a Course Catalog Moodle

  • Deploy: The course can be deployed to any Training Center known in the MoodleNetwork neighborhood by people having capabilities to do it.
  • Deploy with key: The course can be deployed to any Training Center known in the MoodleNetwork neighborhood by people having capabilities to do it AND having a preset deployment key.

Deploying will make a remote copy of the course, landing in :

  • a category choosen when setting up the deployement
  • a predefined category for incoming courses, setup in the remote Moodle.

Within a Training Center Moodle

  • Open/Reopen: The course is set available for use, or reopen if it is in a closed state.
  • Close: The course is closed.
  • Retrofit: The course can be retrofit to any Factory in the network neighbourhood.

When a course is coming from deployment, it is set to a non visible state and can be attached to a predefined category.

Opening course options

When opening a course, the course may be moved to a predefined category (See Global Settings) and is set to a visible state (enroll mode unchanged).

  • Opening with notification: All user that have role assigned within the course will be notified of opening.
  • Opening without notification: No one will be notified. The course opens silently.

Closing course options

When closing a course, the course might be moved to a predefined category (See Global Settings). Closing a course might result in three distinct final states:

  • Private closing: the course is set to not visible state and no one else than teachers can go in.
  • Protected closing: the course does'nt changes its enroll settigns and student users are shifted to a Disabled Student additional custom role. Enrolled Students may thus continue to access to the course content and production whithout any interaction being possible any more.
  • Public closing: the course is allowed to guest entry and open to guests. All users are shifted to a Disabled Student additional custom role so they get disabled.

Block Operations and implementation documentation

Implementation Documentation

Screens

Operations

Making a course publishable

A course is publishable if :

  • MNET is activated.
  • MNET Services for publishing architecture (Publishflow services) is enabled :
  • The network has been scanned for publishing structure recognition (the current node knows what kind of Moodle peers he has in the environment and a suitable peer for the operation is available).
  • A publishflow block is added to the course
  • The course has been indexed (has an IDNumber) (using the publishflow block in a Factory node)
  • The course has got a transportable backup stored in the publishflow filearea.
  • The current user has block/publishflow:publish capability enabled on this course.

Credits

This module is developped and maintained by valery.fremaux@gmail.com