View source for Upgrade notification

{{Moodle 2.0}}
* '''PROJECT STATE:''' Proposal
* '''MAIN TRACKER ISSUE''': MDL-20438
* '''DISCUSSION AND COMMENTS''': n/a
* '''AUTHOR''': [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] + feedback and ideas from other developers
* '''TIME NEEDED FOR IMPLEMENTATION''': 5 days

==Notice==

This topic is particularly addressed by the [[Available update notifications]] project for Moodle 2.3.

=Overview=

The mandatory security measure is to always keep Moodle software up to date. This page describes new mechanism that notifies each admin about available Moodle upgrades.  At present upgrade information is available from moodle.org site, we are also sending new version notices via email to registered administrators. Unfortunately many sites are not upgraded regularly :-(

The general idea is that each Moodle instance contacts regularly (every 7 days) moodle.org and fetches the latest version information. Admin is notified by own server when any new version available. The notification would be also printed on the security overview report, the site notification and the front page (only when admin logged in). Admins would be also notified when branch not maintained any more.

The side effect would be that we could get much better version statistics, of course we need to provide an opt-out option ;-)

=moodle.org side=

==Official release info==

Simple PHP script which accepts one optional parameter ''release'' (ex.:1.9.5+(Build:20091005)) and returns XML file which includes following info describing all branches:

<code xml>
<?xml version="1.0" encoding="UTF-8" ?>
 <UPTODATE_INFO component="core">
  <BRANCH version="1.9">
   <VERSION>2007101560</VERSION>
   <RELEASE>1.9.6</RELEASE>
   <MAINTENANCE_END />
   <URL>http://moodle.org</URL>
   <AUTHOR>Martin Dougiamas</AUTHOR>
  </BRANCH>
 </UPTODATE_INFO>
</xml>
</code>

This example contains values that would be served after the release of Moodle 1.9.6.

==Contrib details==

<code xml>
<?xml version="1.0" encoding="UTF-8" ?>
 <UPTODATE_INFO component="mod_book">
  <BRANCH version="1.9">
   <VERSION>2008081402</VERSION>
   <RELEASE>1.5beta</RELEASE>
   <REQUIRES>2007101512</REQUIRES>
   <MAINTENANCE_END />
   <AUTHOR>Petr Skoda</AUTHOR>
   <URL>http://moodle.org/mod/data/view.php?d=13&amp;rid=319&amp;filter=1</URL>
  </BRANCH>
 </UPTODATE_INFO>
</xml>
</code>

=Implementation=

==Official releases==
All code is stored in admin report /admin/report/uptodate/*. New Function report_uptodate_fetch_info() - uses standard download_file_content() to fetch XML info from http://moodle.org/uptodate_info.php?release=1.9.5+(Build:20091005)

The XML info is parsed and results stored in the config_plugins table:
* report_uptodate|enabled
* report_uptodate|status (0 - ok, 1 - needs update, 3 branch not maintained)
* report_uptodate|recommended_version
* report_uptodate|recommended_release
* report_uptodate|maintenance_end
* report_uptodate|last_fetched (date when fetched from moodle.org)

The update function is triggered:
* every 7 days from cron.php
* after each upgrade
* when running security overview report

User interface consists of:
# notification for admins - one time or nagging after each login
# admin setting - disable fetching of info from moodle.org
# security overview report integration - critical warning when report plugin not installed, disabled or not up-to-date

==Contrib modules==

Contrib modules could use different moodle.org URL for fetching of supported modules, it might also contain extra compatibility info with Moodle versions.

All code is stored in admin report /admin/report/uptodate/*. New Function report_uptodate_fetch_info_contrib($component) - uses standard download_file_content() to fetch XML info from http://moodle.org/uptodate_info_contrib.php?component=mod_book&release=1.5beta

==Needed core changes==
* improve messaging subsystem
* add plugin hook that is called after user login - needed for admin notification
* add full cron plugin support - needed for update
* add pre and post upgrade notification hooks for all plugins - needed for update after/before upgrade
* DONE <strike>rewrite/improve plugin review page during upgrades/install</strike>

=Potential problems=
# How to deal with weekly builds? - Should we include build date? What upgrade to recommend?
# How to deal with development snapshots? Show big warning in alpha versions (==before branching)?
#