version = 2016120500 release version
requires= 2016112900 current rc4 version

version = 2016052300 release version
requires= 2016051900 current rc1 version

version = planned 2015111600 release version
requires= current 2015111000 rc3 version

version = planned 2015051100 release version
requires= current 2015050500 rc1 version

Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.

This bumps all versions to planned 2.8 release
(2014111000) version and all the dependencies to
current 2.8rc1 (2014110400)

This bumps all versions to planned 2.7 release
(2014051200) version and all the dependencies to
current 2.7rc2 (2014050800)

Includes all the conditions that were in previous Moodle versions:

* Date
* Grade
* Completion (of another activity)
* User profile field

Also includes conditions that are used to reimplement
groupmembersonly:

* Grouping
* Group

For each condition, the component plus unit tests are included.

PLEASE NOTE: The code to actually check each condition is reused
from previous Moodle versions and has not been modified except to
pass codechecker. This is intentional, to reduce the risk of the
change and maximise the chance that behaviour is preserved. Some
of this code might not be very good and might need updating but
that can happen separately.

AMOS BEGIN
 CPY [contains,core_condition],[op_contains,availability_profile]
 CPY [doesnotcontain,core_condition],[op_doesnotcontain,availability_profile]
 CPY [endswith,core_condition],[op_endswith,availability_profile]
 CPY [isempty,core_condition],[op_isempty,availability_profile]
 CPY [isequalto,core_condition],[op_isequalto,availability_profile]
 CPY [isnotempty,core_condition],[op_isnotempty,availability_profile]
 CPY [startswith,core_condition],[op_startswith,availability_profile]
 CPY [completion_fail,core_condition],[option_fail,availability_completion]
 CPY [completion_pass,core_condition],[option_pass,availability_completion]
 CPY [completion_complete,core_condition],[option_complete,availability_completion]
 CPY [completion_incomplete,core_condition],[option_incomplete,availability_completion]
AMOS END

This commit defines the new /availability root folder, with
/availability/classes, /availability/tests, and
/availability/condition where the condition plugins will live.
Condition plugin prefix is availability_, e.g. availability_date.

Rationale for this organisation:

1. I was originally going to put this in /lib/availability but
   it has been pointed out that putting even more junk in lib
   is probably bad.
2. 'availability' and 'condition' are the two names used in code
   to refer to this system ($CFG->enableavailability).
3. The prefix has to be short enough to allow database tables
   (although in practice I assume that condition plugins will not
   normally contain database tables).

The new API includes a Boolean tree structure that controls the
availability of an item.

AMOS BEGIN
 CPY [availabilityconditions,core_condition],[restrictaccess,core_availability]
 CPY [enableavailability,core_condition],[enableavailability,core_availability]
 CPY [configenableavailability,core_condition],[enableavailability_desc,core_availability]
AMOS END

There was some functionality to generate data here, but it was not
maintained, dangerous and being monkeypatched over time.

(versions, requires and dependencies)

Do NOT add link into settings tree, this is extremely dangerous and buggy. It is now usable only in DEBUG_DEVELOPER mode!

AMOS BEGIN
 MOV [calls,report_profiling],[calls,tool_profiling]
 MOV [cannotfindanyrunforurl,report_profiling],[cannotfindanyrunforurl,tool_profiling]
 MOV [cannotfindanyrunforrunid,report_profiling],[cannotfindanyrunforrunid,tool_profiling]
 MOV [comment,report_profiling],[comment,tool_profiling]
 MOV [differencesbetween2runsof,report_profiling],[differencesbetween2runsof,tool_profiling]
 MOV [executiontime,report_profiling],[executiontime,tool_profiling]
 MOV [cputime,report_profiling],[cputime,tool_profiling]
 MOV [lastrunof,report_profiling],[lastrunof,tool_profiling]
 MOV [markreferencerun,report_profiling],[markreferencerun,tool_profiling]
 MOV [memory,report_profiling],[memory,tool_profiling]
 MOV [pluginname,report_profiling],[pluginname,tool_profiling]
 MOV [profilingfocusscript,report_profiling],[profilingfocusscript,tool_profiling]
 MOV [profilingruns,report_profiling],[profilingruns,tool_profiling]
 MOV [profilingrunsfor,report_profiling],[profilingrunsfor,tool_profiling]
 MOV [referencerun,report_profiling],[referencerun,tool_profiling]
 MOV [runid,report_profiling],[runid,tool_profiling]
 MOV [summaryof,report_profiling],[summaryof,tool_profiling]
 MOV [viewdetails,report_profiling],[viewdetails,tool_profiling]
 MOV [viewdiff,report_profiling],[viewdiff,tool_profiling]
 MOV [viewdiffdetails,report_profiling],[viewdiffdetails,tool_profiling]
AMOS END

AMOS BEGIN
 MOV [capabilitylabel,report_capability],[capabilitylabel,tool_capability]
 MOV [capabilityreport,report_capability],[capabilityreport,tool_capability]
 MOV [forroles,report_capability],[forroles,tool_capability]
 MOV [getreport,report_capability],[getreport,tool_capability]
 MOV [changeoverrides,report_capability],[changeoverrides,tool_capability]
 MOV [changeroles,report_capability],[changeroles,tool_capability]
 MOV [intro,report_capability],[intro,tool_capability]
 MOV [pluginname,report_capability],[pluginname,tool_capability]
 MOV [reportforcapability,report_capability],[reportforcapability,tool_capability]
 MOV [reportsettings,report_capability],[reportsettings,tool_capability]
 MOV [roleslabel,report_capability],[roleslabel,tool_capability]
AMOS END

For any courses where at least one remote student was enrolled via 1.x
enrol_mnet plugin, the record in the table enrol was created
automatically by core during the upgrade to the new enrolment framework.
We just need to set the custom field to explicitly indicate that the
course is open for all remote hosts.

mnet MDL-21098  fixed quite a few issues in the mnet installer and testclient.  Rebumped all plugin versions that use mnet to get the services reinstalled

and add upgrades for all mnet enabled plugins

mnet MDL-21261  bumping version numbers of plugins that contain mnet definitions to get them installed properly

- The way that mnet rpc functions are registered.  Plugins must now
  create db/mnet.php which is an array, similar to services.php.  This
  *replaces* the old mnet_publishes() functions.  version.php must be
  bumped to trigger this.

- More information about each rpc-available function is stored in the
  database, including the class it belongs to, the file it is found in,
  and whether or not it is static.  Methods that are not static must be
  in a class with a constructor that takes no arguments (this can easily
  be achieved with a small wrapper if necessary)

- The xmlrpc dispatcher has been rewritten to remove all the
  dependencies on hardcoded information about auth,mnet,portfolio and
  repository, and just use the information in the database.

- The old hardcoded hidden mnet/testclient.php has been moved to the
  Admin menu under "Development" and rewritten.

- The xmlrpc introspection method profiling is now using php and zend
  reflection - which is a lot nicer than the old way, which was using a
  php-based php parser.  This fixes some inconsistent handling of
  methods without arguments that were advertising their return value as
  the only method parameter.  While this is a *fix*, it breaks BC
  slightly - the old 1.9 broken mnet/testclient.php will now not work
  properly with 2.0

- Dangerous mode is still supported, but old mod/*/rpclib.php is
  now unsupported, due to the fact that any plugin can export mnet
  functions with db/mnet.php.  This is a slight BC break.

Still TODO:

- TEST TEST TEST
- Document the two small BC breaks in release notes
- Document the contract for db/mnet.php