MoodleDocs - User contributions [en]

Competency API

2016-04-21T03:23:58Z

FMCorz: /* Public API */

{{Moodle 3.1}}
The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public API is defined by the [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] which contains all the methods publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Competency API

2016-04-21T03:17:15Z

FMCorz:

{{Moodle 3.1}}
The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Competency API

2016-04-19T08:43:58Z

FMCorz: /* URL resolver */

The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Competency API

2016-04-19T08:34:53Z

FMCorz:

The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require to know the URL to a resource, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Competency API

2016-04-19T08:31:10Z

FMCorz:

The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require to know the URL to a resource, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Competency API

2016-04-19T08:24:05Z

FMCorz: git commit -m 'Initial commit'

The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Public API==

The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

==External API==

[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Frontend==

The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

===URL resolver===

As some of the core APIs require to know the URL to a resource, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

====Defining new URLs====

Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>.

<code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code>

==Internal API==

===Persistents, or Models===

The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

There is never any access control performed within the persistent! However, the competency API is oriented towards model-based ACL, therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

Here is a non-exaustive list of the persistents:

{| class="nicetable"
|-
| competency
| A single competency
|-
| competency_framework
| A framework of competencies
|-
| course_competency
| A relationship table (many-to-many) linking courses and competencies
|-
| course_competency_settings
| The settings related to competencies in a course
|-
| course_module_competency
| A relationship table (many-to-many) linking course modules and competencies
|-
| evidence
| A piece of evidence relating the proficiency of a user towards a competency
|-
| plan
| A group of competencies for a user to achieve, often referred to as ''learning plans''
|-
| plan_competency
| A relationship table (many-to-many) linking plans and competencies
|-
| related_competency
| A relationship table (many-to-many) linking competencies to other competencies (within the same framework)
|-
| template
| A template for a plan
|-
| template_competency
| A relationship table (many-to-many) linking templates and competencies
|-
| template_cohort
| The cohorts attached to a template, from which we will create plans.
|-
| user_competency
| The record of the proficiency and rating of a user towards a competency
|-
| user_competency_course
| The record of the rating of a user towards a competency but limited to the scope of a course
|-
| user_competency_plan
| The record of the proficiency and rating of a user within a plan that was archived/completed, understand frozen.
|-
| user_evidence
| A piece of evidence of prior learning
|-
| user_evidence_competency
| Many-to-many relationship between evidence of prior learning and competencies
|}

===Exporters===

When writing external functions and templates we often needed to explicitly specify all the properties of the persistents. For instance, when returning a competency from an external function, when creating a competency from an external function, when preparing the context of a template, when getting the context for a template from an external function, etc... As persistents already define their properties we decided to create ''exporters'' (they are sometimes referred to as ''serialisers''), and ''persistent-based exporters''.

Exporters are classes which convert objects to stdClasses. They may add more properties to the objects as they export them (E.g. generating a ''timeago'' property from the ''date'' property of the object). Therefore exporters are aware of and define all the properties that can be read from an object, and all the properties that are saved in an object.

They mainly serve two purposes:

# They export an object consistently wherever they are used, i.e. all properties will always be present
# They generate the external function ''parameters'' and ''returns'' structure automatically
#* The ''parameters'' will be the ''update'' structure, which contains the ''real'' fields
#* The ''returns'' structure will be the ''read'' structure, which contains everything.

Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

Exporters have come very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

Web service API functions

2016-04-19T06:43:06Z

FMCorz: Add core competency web services

{{Moodle_2.0}}

{| class = "wikitable"
|+Color meaning
|-
| style="background:#D4FFDF;" | Implemented
|-
| style="background:#ffdead;" | Must be implemented
|-
| style="background:#ffdfcd;" | Suggested
|}

==Web service protocols==

{| class="wikitable sortable"
! Name !! Moodle Ver. !! class="unsortable" |Description !! class="unsortable" |CORS !! |Issue
|-
| style="background:#D4FFDF;" | AMF || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Adobe protocol to communicate with Flash/Flex apps || Not supported ||
|-
| style="background:#D4FFDF;" | REST (returning XML) || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | XML data accessed through a REST API (not restful) || Supported (3.0 and onwards) ||
|-
| style="background:#D4FFDF;" | REST (returning JSON) || style="background:#D4FFDF;" | 2.2 || style="background:#D4FFDF;" | JSON data accessed through a REST API (not restful) || Supported (3.0 and onwards)|| MDL-29242
|-
| style="background:#ffdfcd;" | REST (returning JSONP) || style="background:#ffdfcd;" | 2.X || style="background:#ffdfcd;" | Would be very useful for client-side JavaScript || Not supported || MDL-29913
|-
| style="background:#ffdfcd;" | JSON || style="background:#ffdfcd;" | 2.X || style="background:#ffdfcd;" | JSON server receives a JSON encoded params and return JSON encoded values. || Not supported || MDL-21341
|-
| style="background:#ffdead;" | SOAP|| style="background:#ffdead;" | 2.0 || style="background:#ffdead;" | Very important for interoperating with Java and .Net applications. There was a partial implementation JAVA/.Net in Moodle 2.0, but it does not work for anything but the most trivial functions. It is fully working with PHP clients.|| Not supported || MDL-20804, MDL-28988, MDL-28989
|-
| style="background:#D4FFDF;" | XMLRPC|| style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | XML remote-procedure call. || Not supported ||
|}

==Web service functions==

=== Naming convention ===

We updated (regularised) the naming convention in Moodle 2.2. See MDL-29106 for those details.

All functions should be named as follows:

* wsfunction = fullcomponent_methodname
* fullcomponent = [https://docs.moodle.org/dev/Frankenstyle frankenstyle] (eg core_xxxx or mod_xxx etc)
* methodname = verb_noun(s)
* verb = get|create|delete|update
* noun = moodle objects, usually plural (eg posts, discussions, users, courses etc)

=== Core web service functions ===
{| class="wikitable sortable"
!Area!! Moodle 2.2 name !! Moodle 2.0/2.1 name !! Introduced in !! class="unsortable" |Description !! class="unsortable" | Issue
|-
|user
| style="background:#D4FFDF;" | core_user_create_users() || style="background:#D4FFDF;" | moodle_user_create_users() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Create users - admin function ||
|-
|user
| style="background:#D4FFDF;" | core_user_delete_users() || style="background:#D4FFDF;" | moodle_user_delete_users() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Delete users - admin function ||
|-
|user
| style="background:#D4FFDF;" | core_user_update_users() || style="background:#D4FFDF;" | moodle_user_update_users() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Update users ||
|-
|user
| style="background:#D4FFDF;" | core_user_get_users_by_id() || style="background:#D4FFDF;" | moodle_user_get_users_by_id() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Get users by id ||
|-
|user
| style="background:#D4FFDF;" | core_user_get_course_user_profiles() || style="background:#D4FFDF;" | moodle_user_get_course_participants_by_id() || style="background:#D4FFDF;" | 2.1 || style="background:#D4FFDF;" | Get course user profiles by id ||
|-

|cohort
| style="background:#D4FFDF;" | core_cohort_create_cohorts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Create cohorts || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_update_cohorts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Update cohorts || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_delete_cohorts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Delete cohorts || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_get_cohorts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Get cohorts || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_add_cohort_members() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Add members to cohort || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_delete_cohort_members() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Delete members from cohort || MDL-29472
|-
|cohort
| style="background:#D4FFDF;" | core_cohort_get_cohort_members() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" |Get cohort members || MDL-29472
|-
| competency
| style="background:#D4FFDF;" | core_competency_create_competency_framework || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Create a competency framework || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_read_competency_framework || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Fetch a competency framework || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_duplicate_competency_framework || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Duplicate a competency framework || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_competency_framework || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete a competency framework || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_update_competency_framework || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Update a competency framework || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_competency_frameworks || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List the competency frameworks || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_competency_frameworks || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count the competency frameworks || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_competency_framework_viewed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Notify a competency framework as being viewed || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_create_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Create a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_read_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Fetch a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_competency_viewed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report a competency as being viewed || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_update_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Update a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_competencies_in_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List the competencies of a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count the competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_competencies_in_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count the competencies in a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_search_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Search for competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_set_parent_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Relocate a competency to another parent || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_move_up_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Move a competency up in its branch || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_move_down_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Move a competency down in its branch || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_course_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List the competencies in a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_competencies_in_course || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count competencies in a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_courses_using_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count courses using a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_add_competency_to_course || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Add competency to a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_add_competency_to_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Add competency to a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_remove_competency_from_course || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Remove competency from a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_set_course_competency_ruleoutcome || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Set the rule of course competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_remove_competency_from_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Remove competency from template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_reorder_course_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Reorder competencies in a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_reorder_template_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Reorder competencies in a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_create_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Create a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_duplicate_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Duplicate a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_read_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Fetch a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_update_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Update a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_templates || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List templates || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_templates_using_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List templates using a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_templates || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count templates || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_count_templates_using_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Count templates using a competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_create_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Create a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_update_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Update a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_complete_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Complete a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_reopen_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Reopen a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_read_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Fetch a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_user_plans || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List a user's learning plans || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_list_plan_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | List a learning plan's competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_add_competency_to_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Add a competency to a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_remove_competency_from_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Remove a competency from a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_reorder_plan_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Reopen a competency in a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_plan_request_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Request the review of a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_plan_start_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Start the review of a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_plan_stop_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Stop the review of a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_plan_cancel_review_request || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Cancel the review request of a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_approve_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Approve a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_unapprove_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Unapprove a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_template_has_related_data || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Check whether a template has related data || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_get_scale_values || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get the values for a scale || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_add_related_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Create a relationship between competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_remove_related_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Remove a relationship between competencies || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_read_user_evidence || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Fetch an evidence of prior learning || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_user_evidence || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete an evidence of prior learning || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_create_user_evidence_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Link an evidence of prior learning with a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_user_evidence_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Remove a link between an evidence of prior learning and a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_cancel_review_request || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Cancel the review request of a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_request_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Request the review of a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_start_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Start the review of a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_stop_review || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Stop the review of a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_viewed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report a user's competency as being viewed || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_viewed_in_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report a user's competency as being viewed from a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_viewed_in_course || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report a user's competency as being viewed from a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_user_competency_plan_viewed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report the archive of user's competency as being viewed || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_grade_competency || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Rate a user's competency || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_grade_competency_in_plan || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Rate a user's competency in a learning plan || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_grade_competency_in_course || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Rate a user's competency in a course || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_unlink_plan_from_template || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Unlink a learning plan from a template || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_template_viewed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Report a template as being viewed || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_request_review_of_user_evidence_linked_competencies || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Request the review of the user's competencies linked to an evidence of prior learning || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_update_course_competency_settings || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Update the course competency settings || MDL-49458
|-
| competency
| style="background:#D4FFDF;" | core_competency_delete_evidence || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Delete an evidence || MDL-49458
|-
|course
| style="background:#D4FFDF;" | core_course_get_courses() || style="background:#D4FFDF;" | moodle_course_get_courses() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Return course details ||
|-
|course
| style="background:#D4FFDF;" | core_course_create_courses() || style="background:#D4FFDF;" | moodle_course_create_courses() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Create new courses ||
|-
|course
| style="background:#D4FFDF;" | core_course_search_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Search courses by (name, module, block, tag). || MDL-49942
|-
|course
| style="background:#D4FFDF;" | core_course_get_course_module || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Return information about a course module. || MDL-51371
|-
|course
| style="background:#D4FFDF;" | core_course_get_course_module_by_instance || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Return information about a given module name and instance id. || MDL-51579
|-
|group
| style="background:#D4FFDF;" | core_group_create_groups() || style="background:#D4FFDF;" | moodle_group_create_groups() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Creates new groups ||
|-
|group
| style="background:#D4FFDF;" | core_group_get_groups() || style="background:#D4FFDF;" | moodle_group_get_groups() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Returns group details. ||
|-
|group
| style="background:#D4FFDF;" | core_group_get_course_groups() || style="background:#D4FFDF;" | moodle_group_get_course_groups() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Returns all groups in specified course ||
|-
|group
| style="background:#D4FFDF;" | core_group_delete_groups() || style="background:#D4FFDF;" | moodle_group_delete_groups() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Deletes all specified groups ||
|-
|group
| style="background:#D4FFDF;" | core_group_get_group_members() || style="background:#D4FFDF;" | moodle_group_get_groupmembers() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Returns group members ||
|-
|group
| style="background:#D4FFDF;" | core_group_add_group_members() || style="background:#D4FFDF;" | moodle_group_add_groupmembers() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Adds group members ||
|-
|group
| style="background:#D4FFDF;" | core_group_delete_group_members() || style="background:#D4FFDF;" | moodle_group_delete_groupmembers() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Deletes group members ||
|-
|group
| style="background:#D4FFDF;" | core_group_get_activity_allowed_groups || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Gets a list of groups that the user is allowed to access within the specified activity. || MDL-50966
|-
|group
| style="background:#D4FFDF;" | core_group_get_activity_groupmode || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns effective groupmode used in a given activity. || MDL-50964
|-
|role
| style="background:#D4FFDF;" | core_role_assign_roles() || style="background:#D4FFDF;" | moodle_role_assign() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Manual role assignments ||
|-
|role
| style="background:#D4FFDF;" | core_role_unassign_roles() || style="background:#D4FFDF;" | moodle_role_unassign() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Manual role unassignments ||
|-
|enrol
| style="background:#D4FFDF;" | NONE || style="background:#D4FFDF;" | moodle_enrol_get_enrolled_users() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | get some minimal information about the users enrolled in a course (DEPRECATED) ||
|-
|enrol
| style="background:#D4FFDF;" | core_enrol_get_enrolled_users() || style="background:#D4FFDF;" | moodle_user_get_users_by_courseid() || style="background:#D4FFDF;" | 2.1 || style="background:#D4FFDF;" | Get enrolled users by course id ||
|-
|enrol
| style="background:#D4FFDF;" | core_enrol_get_users_courses() || style="background:#D4FFDF;" | moodle_enrol_get_users_courses() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | get list of course ids that a user is enrolled in (if you are allowed to see that) ||
|-
|enrol_manual
| style="background:#D4FFDF;" | enrol_manual_enrol_users() || style="background:#D4FFDF;" | moodle_enrol_manual_enrol_users() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | Manual enrol users ||
|-
|enrol_self
| style="background:#D4FFDF;" | enrol_self_enrol_user || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Self enrol the current user in the given course. || MDL-51568
|-
|webservice
| style="background:#D4FFDF;" | core_webservice_get_site_info() || style="background:#D4FFDF;" | moodle_webservice_get_siteinfo() || style="background:#D4FFDF;" | 2.1 || style="background:#D4FFDF;" | Return some site info / user info / list web service functions ||
|-
|message
| style="background:#D4FFDF;" | core_message_send_instant_messages() || style="background:#D4FFDF;" | moodle_message_send_instantmessages() || style="background:#D4FFDF;" | 2.1 || style="background:#D4FFDF;" | Send instant messages ||
|-
|notes
| style="background:#D4FFDF;" | core_notes_create_notes() || style="background:#D4FFDF;" | moodle_notes_create_notes() || style="background:#D4FFDF;" | 2.1 || style="background:#D4FFDF;" | Create notes ||
|-
|notes
| style="background:#D4FFDF;" | core_notes_delete_notes() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Delete Notes || MDL-30072
|-
|notes
| style="background:#D4FFDF;" | core_notes_get_notes() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Retrieve Notes || MDL-30072
|-
|notes
| style="background:#D4FFDF;" | core_notes_update_notes() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Update Notes || MDL-30072
|-
|files
| style="background:#D4FFDF;" | core_files_get_files() || style="background:#D4FFDF;" | moodle_file_get_files() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | browse moodle files ||
|-
|files
| style="background:#D4FFDF;" | core_files_upload() || style="background:#D4FFDF;" | moodle_file_upload() || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | upload a file to moodle (DEPRECATED) ||
|-
|course
| style="background:#D4FFDF;" | core_course_get_contents() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.2 || style="background:#D4FFDF;" | get course content (modules + web service file urls) || MDL-28646
|-
|course
| style="background:#D4FFDF;" | core_course_delete_courses() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | delete courses || MDL-13130
|-
|course
| style="background:#D4FFDF;" | core_course_duplicate_course() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | duplicate a course || MDL-32233
|-
|course
| style="background:#D4FFDF;" | core_course_get_categories() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | get categories || MDL-32941
|-
|course
| style="background:#D4FFDF;" | core_course_update_categories() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | update categories || MDL-32941
|-
|course
| style="background:#D4FFDF;" | core_course_create_categories() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | create categories || MDL-32941
|-
|course
| style="background:#D4FFDF;" | core_course_delete_categories() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | delete categories || MDL-32941
|-
|group
| style="background:#D4FFDF;" | core_group_create_groupings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | create groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_update_groupings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | update groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_get_groupings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | get groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_delete_groupings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | delete groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_assign_grouping() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | assign groups from groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_unassign_grouping() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | unassign groups from groupings || MDL-32662
|-
|group
| style="background:#D4FFDF;" | core_group_get_course_groupings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.3 || style="background:#D4FFDF;" | get all groupings in specified course || MDL-32662
|-
|user
| style="background:#D4FFDF;" | core_user_get_users_by_field() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Retrieve users information for a specified unique field - If you want to do a user search, use core_user_get_users() || MDL-35543
|-
|enrol
| style="background:#D4FFDF;" | core_enrol_get_enrolled_users_with_capability() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | For each course and capability specified, return a list of the users that are enrolled in the course and have that capability || MDL-31859
|-
|course
| style="background:#D4FFDF;" | core_course_import_course() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Import course data from a course into another course. Does not include any user data. || MDL-32919
|-
|message
| style="background:#D4FFDF;" | core_message_create_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Add contacts to the contact list || MDL-30070
|-
|message
| style="background:#D4FFDF;" | core_message_delete_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Remove contacts from the contact list || MDL-30070
|-
|message
| style="background:#D4FFDF;" | core_message_block_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Block contacts || MDL-30070
|-
|message
| style="background:#D4FFDF;" | core_message_unblock_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Unblock contacts || MDL-30070
|-
|message
| style="background:#D4FFDF;" | core_message_get_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Retrieve the contact list || MDL-30070
|-
|message
| style="background:#D4FFDF;" | core_message_search_contacts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Search for contacts || MDL-30070
|-
|external
| style="background:#D4FFDF;" | core_get_string() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Return a translated string - similar to core get_string() call || MDL-35997
|-
|external
| style="background:#D4FFDF;" | core_get_component_strings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Return all raw strings (with {$a->xxx}) for a specific component - similar to core get_component_strings() call || MDL-35997
|-
|external
| style="background:#D4FFDF;" | core_get_strings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Return some translated strings - like several core get_string() calls || MDL-35997
|-
|calendar
| style="background:#D4FFDF;" | core_calendar_delete_calendar_events() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Delete calendar events || MDL-37077
|-
|calendar
| style="background:#D4FFDF;" | core_calendar_get_calendar_events() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Get calendar events || MDL-37100
|-
|calendar
| style="background:#D4FFDF;" | core_calendar_create_calendar_events() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Create calendar events || MDL-37101
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_get_grades() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Returns grades from the assignment || MDL-31873
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_get_assignments() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.4 || style="background:#D4FFDF;" | Returns the courses and assignments for the users capability || MDL-31873
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_get_submissions || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Returns the submissions for assignments || MDL-31682
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_get_user_flags || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Returns the user_flags for assignments || MDL-40548
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_set_user_flags || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Sets the specified user_flags for an assignment || MDL-41738
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_get_user_mappings || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Returns the user_mappings for assignments || MDL-40548
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_revert_submissions_to_draft || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Reverts the list of submissions to draft status || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_lock_submissions || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Prevent students from making changes to a list of submissions || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_unlock_submissions || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Allow students to make changes to a list of submissions || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_save_submission || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Update the current students submission || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_submit_for_grading || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Submit the current students assignment for grading || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_save_grade || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Save a grade update for a single student. || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_save_grades || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.7 || style="background:#D4FFDF;" | Save grade updates for one or more students. || MDL-42425
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_save_user_extensions || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Save a list of assignment extensions || MDL-37148
|-
|mod_assign
| style="background:#D4FFDF;" | mod_assign_reveal_identities || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Reveal the identities for a blind marking assignment || MDL-37148
|-
|mod_book
| style="background:#D4FFDF;" | mod_book_view_book || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-50013
|-
|mod_book
| style="background:#D4FFDF;" | mod_book_get_books_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of book instances in a provided set of courses. || MDL-50536
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_get_chats_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of chat instances in a provided set of courses. || MDL-50537
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_view_chat || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-50853
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_login_user || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Log a user into a chat room in the given chat. || MDL-50853
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_get_chat_users || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Get the list of users in the given chat session. || MDL-50853
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_send_chat_message || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Send a message on the given chat session. || MDL-50853
|-
|mod_chat
| style="background:#D4FFDF;" | mod_chat_get_chat_latest_messages || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Get the latest messages from the given chat sessio. || MDL-50853
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_get_choices_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of choice instances in a provided set of courses. || MDL-50132
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_get_choice_results || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Retrieve users results for a given choice. || MDL-50944
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_get_choice_options || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Retrieve options for a specific choice. || MDL-50944
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_submit_choice_response || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Submit responses to a specific choice item. || MDL-50944
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_view_choice || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status.. || MDL-50944
|-
|mod_choice
| style="background:#D4FFDF;" | mod_choice_delete_choice_responses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Delete the given submitted responses in a choice. || MDL-50944
|-
|mod_data
| style="background:#D4FFDF;" | mod_data_get_databases_by_courses() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Returns a list of database instances in a provided set of courses, if no courses are provided then all the database instances the user has access to will be returned. || MDL-49337
|-
|mod_folder
| style="background:#D4FFDF;" | mod_folder_view_folder || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-50008
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_get_forums_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Returns a list of forum instances in a provided set of courses, if no courses are provided then all the forum instances the user has access to will be returned. || MDL-37247
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_get_forum_discussion_posts() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.7 || style="background:#D4FFDF;" |Returns a list of forum posts for a discussion. || MDL-30106
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_get_forum_discussions_paginated() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.8 || style="background:#D4FFDF;" |Returns a list of forum discussions optionally sorted and paginated. || MDL-46458
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_view_forum() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Trigger the course_module_viewed event when a user view a forum (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || MDL-49502
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_view_forum_discussion() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Trigger the discussion_viewed event when a user view a forum discussion (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || MDL-49503
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_get_forum_discussions || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Returns a list of forum discussions in a provided set of forums. (DEPRECATED use mod_forum_get_forum_discussions_paginated instead) || MDL-30102
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_add_discussion || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Add a new discussion into an existing forum. || MDL-50994
|-
|mod_forum
| style="background:#D4FFDF;" | mod_forum_add_discussion_post || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Create new posts into an existing discussion. || MDL-50995
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_glossaries_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get the glossaries in courses || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_view_glossary || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Notify that a glossary was viewed || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_view_entry || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Notify that a glossary entry was viewed || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_letter || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using letter filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_date || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using date filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_categories || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get a glossary's categories || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_category || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using category filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_authors || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get the authors in a glossary || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_author || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using author filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_author_id || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using author ID filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_search || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries matching a search query || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_by_term || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries using term filtering || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entries_to_approve || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get entries to be approved || MDL-50540
|-
|mod_glossary
| style="background:#D4FFDF;" | mod_glossary_get_entry_by_id || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.1 || style="background:#D4FFDF;" | Get an entry by ID || MDL-50540
|-
|mod_imscp
| style="background:#D4FFDF;" | mod_imscp_view_imscp || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-50015
|-
|mod_imscp
| style="background:#D4FFDF;" | mod_imscp_get_imscps_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of imscp instances in a provided set of courses. || MDL-50541
|-
|mod_lti
| style="background:#D4FFDF;" | mod_lti_get_ltis_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of lti instances in a provided set of courses. || MDL-50543
|-
|mod_lti
| style="background:#D4FFDF;" | mod_lti_view_lti || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-51624
|-
|mod_lti
| style="background:#D4FFDF;" | mod_lti_get_tool_launch_data || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Return the launch data for a given external tool. || MDL-51615
|-
|mod_page
| style="background:#D4FFDF;" | mod_page_view_page || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-49791
|-
|mod_resource
| style="background:#D4FFDF;" | mod_resource_view_resource || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-49792
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_get_scorms_by_courses || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list of scorm instances in a provided set of courses. || MDL-50349
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_view_scorm || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status.. || MDL-50427
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_get_scorm_attempt_count || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Return the number of attempts done by a user in the given SCORM. || MDL-51017
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_get_scorm_sco_tracks || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Retrieves SCO tracking data for the given user id and attempt number. || MDL-50557
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_insert_scorm_tracks || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Saves a scorm tracking record. || MDL-50353
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_get_scorm_user_data || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Retrieves user tracking and SCO data and default SCORM values. || MDL-50352
|-
|mod_scorm
| style="background:#D4FFDF;" | mod_scorm_get_scorm_scoes || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Returns a list containing all the scoes data related to the given scorm id. || MDL-50351
|-
|mod_url
| style="background:#D4FFDF;" | mod_url_view_url || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Trigger the course module viewed event and update the module completion status. || MDL-49793
|-
|course
| style="background:#D4FFDF;" | core_course_update_courses() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Update courses. || MDL-30062
|-
|user
| style="background:#D4FFDF;" | core_user_get_users() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Search users. - If you want to get multiple users for one specific field, use core_user_get_users_by_field(), it's designed for this purpose and it should be faster. || MDL-29938
|-
|grade
| style="background:#D4FFDF;" | core_grade_get_definitions() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" | Returns grading definitions for the course module ids and areaname provided as parameters. An optionall activeonly parameter can be provided so that only the active grading method is returned. Will be deprecated and replaced by core_grading_get_definitions in 2.6|| MDL-31681
|-
|grade
| style="background:#D4FFDF;" | core_grade_get_grades() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.7 || style="background:#D4FFDF;" | Returns student course total grade and grades for activities. This function does not return category or manual items. This function is suitable for managers or teachers not students.|| MDL-30085
|-
|grade
| style="background:#D4FFDF;" | core_grade_update_grades() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.7 || style="background:#D4FFDF;" | Update a grade item and associated student grades.|| MDL-30085
|-
|grading
| style="background:#D4FFDF;" | core_grading_get_definitions() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Returns grading definitions for the course module ids and areaname provided as parameters. An optionall activeonly parameter can be provided so that only the active grading method is returned.|| MDL-31890
|-
|grading
| style="background:#D4FFDF;" | core_grading_get_gradingform_instances() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" | Returns the instances and fillings for the requested definition id. An optional since parameter allows the number of records returned to be reduced so that only those with a timemodified value >= since are returned|| MDL-31890
|-
|grading
| style="background:#D4FFDF;" | core_grading_save_definitions() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.8 || style="background:#D4FFDF;" |Accepts an array of areas as a parameter. The areas contain grading definitions with criteria for inserting and updating|| MDL-31861
|-
|comment
| style="background:#D4FFDF;" | core_comment_get_comments() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Return all the comments for an specific component, context. || MDL-49203
|-
|completion
| style="background:#D4FFDF;" | core_completion_get_activities_completion_status() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Return the activities completion status for a user in a course. || MDL-49314
|-
|completion
| style="background:#D4FFDF;" | core_completion_get_course_completion_status() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Returns course completion status. || MDL-49313
|-
|completion
| style="background:#D4FFDF;" | core_completion_update_activity_completion_status_manually() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Update completion status for the current user in an activity, only for activities with manual tracking. || MDL-49444
|-
|completion
| style="background:#D4FFDF;" | core_completion_mark_course_self_completed || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 3.0 || style="background:#D4FFDF;" | Update the course completion status for the current user (if course self-completion is enabled). || MDL-50930
|-
|course
| style="background:#D4FFDF;" | core_course_view_course() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Log that the course was viewed || MDL-49453
|-
|group
| style="background:#D4FFDF;" | core_group_get_course_user_groups() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Returns all groups in specified course for the specified user. || MDL-48730
|-
|message
| style="background:#D4FFDF;" | core_message_get_messages() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.8 || style="background:#D4FFDF;" |Retrieve a list of messages sent and received by a user (conversations, notifications or both) || MDL-45374
|-
|message
| style="background:#D4FFDF;" | core_message_mark_message_read() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Mark a single message as read, trigger message_viewed event. || MDL-49501
|-
|notes
| style="background:#D4FFDF;" | core_notes_view_notes() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Simulates the web interface view of notes/index.php: trigger events. || MDL-49504
|-
|rating
| style="background:#D4FFDF;" | core_rating_get_item_ratings() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Retrieve all the ratings for an item. || MDL-49347
|-
|user
| style="background:#D4FFDF;" | core_user_add_user_device() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.6 || style="background:#D4FFDF;" |Store mobile user devices information for PUSH Notifications. || MDL-41914
|-
|user
| style="background:#D4FFDF;" | core_user_remove_user_device() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Remove a user device from the Moodle database. || MDL-48716
|-
|user
| style="background:#D4FFDF;" | core_user_view_user_list() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Simulates the web-interface view of user/index.php (triggering events). || MDL-49498
|-
|user
| style="background:#D4FFDF;" | core_user_view_user_profile() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Simulates the web-interface view of user/view.php and user/profile.php (triggering events). || MDL-49499
|-
|grade_report
| style="background:#D4FFDF;" | gradereport_user_get_grades_table() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Get the user/s report grades table for a course || MDL-49036
|-
|grade_report
| style="background:#D4FFDF;" | gradereport_user_view_grade_report() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Trigger the grade_report_viewed event when a user view his grade report (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || MDL-49500
|-
|message
| style="background:#D4FFDF;" | core_message_get_blocked_users() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Retrieve a list of users blocked || MDL-48719
|-
|course
| style="background:#D4FFDF;" | core_course_delete_modules() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.5 || style="background:#D4FFDF;" |Deletes all specified module instances || MDL-30098
|-
|notes
| style="background:#D4FFDF;" | core_notes_get_course_notes() || style="background:#D4FFDF;" | || style="background:#D4FFDF;" | 2.9 || style="background:#D4FFDF;" |Returns all notes in specified course (or site) for the specified user. || MDL-49330
|-
|}
This is the list of the integrated core functions. To see the roadmap, see to the tracker issue in the section bellow.

=== API Roadmap===
Tracker issue: MDL-29934

= See also =
* [[Web services API Changes]]
* [[How to contribute a web service function to core]]
* [[Web services|Web services developer documentation]]
* [[:en:Web services|Web services user documentation]]

[[Category:Web Services]]
[[Category:API]]

Web service API functions

2016-04-19T05:41:16Z

FMCorz: Adding mod_glossary new external functions

Moodle 3.0 release notes

2015-11-03T06:56:45Z

FMCorz: /* For developers */

{{Work in progress}}

[[Releases]] > {{FULLPAGENAME}}

Release date: Monday, 16th November 2015

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%223.0%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 3.0].

See our [https://docs.moodle.org/30/en/New_features New Features page] for a more user-friendly introduction to Moodle 3.0 with screenshots.

If you are upgrading from previous version, make sure to read the [https://docs.moodle.org/30/en/Upgrading Upgrading] documentation.

==Server requirements==

These are just the minimum supported versions. We recommend keeping all of your software up-to-date.

* Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)
* PHP version: minimum PHP 5.4.4 (always use latest PHP 5.4.x or 5.5.x on Windows - http://windows.php.net/download/), PHP 7 is NOT supported
* Ghostscript should be installed for pdf annotation.

=== Database requirements ===

Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.

{| class="nicetable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 9.1
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.5.31
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 5.5.31
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2008
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 10.2
| Latest
|}

==Client requirements==

=== Browser support ===

{| class="nicetable"
|-
! Browser
! Minimum version
! Recommended version
! Notes
|-
| [https://www.google.com/intl/en_au/chrome/browser/ Google Chrome]
| 30.0
| Latest
|
|-
| [http://www.mozilla.org/en-US/ Mozilla Firefox]
| 25.0
| Latest
|
|-
| [http://www.apple.com/safari/ Apple Safari]
| 6
| Latest
|
|-
| [http://windows.microsoft.com/en-AU/internet-explorer/download-ie Microsoft Internet Explorer]
| 9
| Latest
| Version 10 is required for drag-and-drop upload of content from outside the browser into Moodle
|}

==Major features==

===Highlights===

* MDL-29801 - Allow users to delete personal messages
* MDL-27177 - Allow students to see each other's contact details in full profile without global permission if they are able to see each other's course profile
* MDL-46455 - Re-introduce backup/restore functionality with new logging system
* MDL-46878 - Reset Dashboard for all users after changing the default dashboard

===Quiz===

* MDL-47494 - New question types from the OU - [https://docs.moodle.org/30/en/Select_missing_words_question_type Select missing words], [https://docs.moodle.org/30/en/Drag_and_drop_into_text_question_type Drag and drop into text], [https://docs.moodle.org/30/en/Drag_and_drop_onto_image_question_type Drag and drop onto image] and [https://docs.moodle.org/30/en/Drag_and_drop_markers_question_type Drag and drop markers]
* MDL-38214 - Add MCS, MCVS, MCHS Cloze subquestion types
* MDL-50127 - By default the list of question types should be sorted with common ones at the top
* MDL-29771 - Interactive behaviour should show number of tries left in the Try again state

===Forum===

* MDL-49682 - Make forum email template editable
* MDL-46321 - Uninformative error when moving forum without first selecting destination
* MDL-50993 - Timed discussions are now displayed to students in a logical order
* MDL-50430 - Add number of subscribers to forum subscriber list

===Assignment===

* MDL-49176 - Assigment marking guide 'flattens' instructions for markers and students
* MDL-49515 - Upgrade FPDI library in assignfeedback_editpdf to 1.5.4 to fix problems with PDF annotator on some files
* MDL-50283 - Improve Rubric interface to include the ability to duplicate rows

===Other activity modules===

* MDL-49028 - Wiki: Option to delete pages during course reset
* MDL-40836 - File resource: New [https://docs.moodle.org/30/en/File_resource_settings file resource setting] option to display upload/modified date
* MDL-26501 - Glossary: Do not allow to browse by author if author is never displayed
* MDL-50673 - Workshop: display all participants on "Submisstion phase" page in a table
* MDL-50664 - Database: add setting to disallow managing of own entries after approval
* MDL-50658 - LTI: Add support for LTI Memberships service
* MDL-49581 - Lesson: Remove high scores list feature
* MDL-49882 - Lesson: Essay questions are not imported into the lesson Module
* MDL-50720 - Database: Highlight database entries that are not yet approved.

===User interface and usability improvements===

* MDL-51051 - Rename 'Categories and items' to 'Gradebook setup' and add link
* MDL-51250 - Show default section name when editing section details with default checkbox being checked
* MDL-49984 - Add visual blocks outlines to My profile page to help separate information
* MDL-48947 - Collect all course section editing buttons under one "Edit" dropdown
* MDL-51087 - Use client-side validation in the signup form
* MDL-50113 - Improve display of long user and course names in Messaging
* MDL-50919 - Simplify the Manage tags page, allow to quickly change name, flag and official status of the tags
* MDL-51013 - Navbar button should appear for smaller screens only when the custom menu or language menu is not empty
* MDL-51260 - Use the new autocomplete form field for tags
* MDL-51296 - Add title to page when adding blog post
* MDL-38763 - Permission override UI should use JS confirmation
* MDL-29763 - Add description to Portfolio settings page

===Atto editor===

* MDL-45515 - New table editing features in Atto editor
* MDL-49732 - Keyboard interaction for hyperlink in Atto (Ctrl+K)
* MDL-50936 - More Atto Math Equation buttons (sum, sqrt, int, etc.)
* MDL-50142 - Text editor preferences help pop-up

===Enrolments===

* MDL-30674 - Set guest access key from enrolment methods page
* MDL-30157 - Allow users to start manual enrolments right now
* MDL-49746 - Allow to sort enrolled users page by last course access
* MDL-48074 - Group filter in enrolments list should have option "not in any group"

===Administration===

* MDL-49329 - Multiple improvements in the plugins installation/update system including ability to install several plugins at the same time
* MDL-49280 - New configuration setting to allow duplicate email addresses
* MDL-51330 - Show scheduled tasks component in the cron log
* MDL-51261 - Upgrade key - mechanism to protect anonymous web access to upgrade screens
* MDL-50602 - New settings in [https://docs.moodle.org/30/en/Automated_course_backup Automated backup setup] for deleting older backups and keeping a minimum number of backups
* MDL-48438 - Add real name to email about login failures
* MDL-30960 - New option in email settings to specify SSL or TLS (SMTPSecure property of PHPMailer)
* MDL-46623, MDL-51824 - CAS and LDAP: Replace CLI script to synchronise users with a scheduled tasks
* MDL-39319 - Allow administrator to uninstall several languages in one single action
* MDL-50155 - Move and rename "Common activities settings" link to be under "Manage activities" for consistency
* MDL-50631 - Display Moodle ASCII logo in CLI installer
* MDL-46167 - New option for CLI installation: skip database
* MDL-50572 - Disable Youtube repository by default since it requires setting up
* MDL-51739 - Lock theme selector UI when $CFG->theme is hardcoded in config.php
* MDL-51478 - Enable Mobile services by default
* MDL-19748 - Do not allow to edit tags in the default authenticated user role
* MDL-46398 - Make HTML5 video the default player for capable videos

===Other improvements===

* MDL-51132 - Introduce course tagging as a replacement for user-course-tagging in the "Tags" block. See [https://docs.moodle.org/30/en/Tags_block#Course_tagging_changes_in_Moodle_3.0 upgrade documentation]
* MDL-41042 - Course contacts shown in course listings no longer lag by an hour
* MDL-44273 - Back-off strategy for RSS feeds
* MDL-45981 - CAS Auth Config needs way to specify that curl should use SSLv3.
* MDL-49891 - Add description meta to frontpage
* MDL-25451 - Go straight to "Permissions" from block context menu instead of "Assign roles" if theya are not available
* MDL-50647 - Add 'not in group' section to group overview page
* MDL-50956 - Allow main menu block to be displayed "throughout the entire site"
* MDL-28954 - Allow images and embedded files in the cohort descriptions
* MDL-50371 - Use $CFG->gradepointdefault for new manual gradeitems and grade categories

==Security issues==

A number of security related issues were resolved. Details of these issues will be released after a period of approximately one week to allow system administrators to safely update to the latest version.

==For developers==

* MDL-46455 - Events must define fields mappings in order to be correctly restored ([https://docs.moodle.org/dev/Event_2#Backup.2Frestore documentation])
* MDL-50125 - Allow all plugins to inject links in the preferences page ([https://docs.moodle.org/dev/Navigation_API#Course_settings documentation])
* MDL-51247 - Revive / refresh / rebuild the autocomplete mform element.
* MDL-50839 - Allow themes to set User menu avatar size ([https://docs.moodle.org/dev/Customising_the_theme_user_menu documentation])
* MDL-48494 - Make $plugin->component required for all plugins
* MDL-43896 - Drop support for $module in version.php files for Moodle 3.0
* MDL-50645 - Cache the list of available callbacks per plugin
* MDL-33564 - rss_error() should return a proper HTTP response code
* MDL-37864 - New method to add help icons to the sortable table headers ([https://docs.moodle.org/dev/lib/tablelib.php documentation])
* MDL-51737 - Add ability to detect MS Edge in our browser sniffing code
* MDL-51213 - external_format_text should be safe to call from web or webservice ([https://docs.moodle.org/dev/How_to_contribute_a_web_service_function_to_core documentation])
* MDL-51413 - Add an additional return field in get_forums_by_courses in order to specify if the current user can create discussions
* MDL-51217 - Using recaptcha is not possible outside auth_email plugin.
* MDL-51107 - Add a callback to inject nodes in the category settings navigation ([https://docs.moodle.org/dev/Navigation_API#Category_settings documentation])
* MDL-50891 - is_web_crawler should be moved to useragent class
* MDL-50453 - Replace reserved word usage from \core\progress\null (PHP7)
* MDL-50009 - Prevent scheduled tasks from leaving unfinished db transactions
* MDL-49821 - Some Web Services miss checks for guest and deleted users
* MDL-50926 - Upgrade to phpunit 4.x
* MDL-50491 - New format_text option to exclude particular filters
* MDL-50783 - Allow some ajax external functions to be called without a session
* MDL-50150 - Add "Blocks" feature to JS and PHP mustache engines ([https://docs.moodle.org/dev/Templates#Blocks_.28Moodle_3.0_onwards.29 documentation])

[[Category:Release notes]]
[[Category:Moodle 3.0]]

[[fr:Notes de mise à jour de Moodle 3.0]]
[[es:Notas de Moodle 3.0]]

Moodle 3.0 release notes

2015-11-03T06:56:26Z

FMCorz: /* For developers */

{{Work in progress}}

[[Releases]] > {{FULLPAGENAME}}

Release date: Monday, 16th November 2015

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%223.0%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 3.0].

See our [https://docs.moodle.org/30/en/New_features New Features page] for a more user-friendly introduction to Moodle 3.0 with screenshots.

If you are upgrading from previous version, make sure to read the [https://docs.moodle.org/30/en/Upgrading Upgrading] documentation.

==Server requirements==

These are just the minimum supported versions. We recommend keeping all of your software up-to-date.

* Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)
* PHP version: minimum PHP 5.4.4 (always use latest PHP 5.4.x or 5.5.x on Windows - http://windows.php.net/download/), PHP 7 is NOT supported
* Ghostscript should be installed for pdf annotation.

=== Database requirements ===

Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.

{| class="nicetable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 9.1
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.5.31
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 5.5.31
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2008
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 10.2
| Latest
|}

==Client requirements==

=== Browser support ===

{| class="nicetable"
|-
! Browser
! Minimum version
! Recommended version
! Notes
|-
| [https://www.google.com/intl/en_au/chrome/browser/ Google Chrome]
| 30.0
| Latest
|
|-
| [http://www.mozilla.org/en-US/ Mozilla Firefox]
| 25.0
| Latest
|
|-
| [http://www.apple.com/safari/ Apple Safari]
| 6
| Latest
|
|-
| [http://windows.microsoft.com/en-AU/internet-explorer/download-ie Microsoft Internet Explorer]
| 9
| Latest
| Version 10 is required for drag-and-drop upload of content from outside the browser into Moodle
|}

==Major features==

===Highlights===

* MDL-29801 - Allow users to delete personal messages
* MDL-27177 - Allow students to see each other's contact details in full profile without global permission if they are able to see each other's course profile
* MDL-46455 - Re-introduce backup/restore functionality with new logging system
* MDL-46878 - Reset Dashboard for all users after changing the default dashboard

===Quiz===

* MDL-47494 - New question types from the OU - [https://docs.moodle.org/30/en/Select_missing_words_question_type Select missing words], [https://docs.moodle.org/30/en/Drag_and_drop_into_text_question_type Drag and drop into text], [https://docs.moodle.org/30/en/Drag_and_drop_onto_image_question_type Drag and drop onto image] and [https://docs.moodle.org/30/en/Drag_and_drop_markers_question_type Drag and drop markers]
* MDL-38214 - Add MCS, MCVS, MCHS Cloze subquestion types
* MDL-50127 - By default the list of question types should be sorted with common ones at the top
* MDL-29771 - Interactive behaviour should show number of tries left in the Try again state

===Forum===

* MDL-49682 - Make forum email template editable
* MDL-46321 - Uninformative error when moving forum without first selecting destination
* MDL-50993 - Timed discussions are now displayed to students in a logical order
* MDL-50430 - Add number of subscribers to forum subscriber list

===Assignment===

* MDL-49176 - Assigment marking guide 'flattens' instructions for markers and students
* MDL-49515 - Upgrade FPDI library in assignfeedback_editpdf to 1.5.4 to fix problems with PDF annotator on some files
* MDL-50283 - Improve Rubric interface to include the ability to duplicate rows

===Other activity modules===

* MDL-49028 - Wiki: Option to delete pages during course reset
* MDL-40836 - File resource: New [https://docs.moodle.org/30/en/File_resource_settings file resource setting] option to display upload/modified date
* MDL-26501 - Glossary: Do not allow to browse by author if author is never displayed
* MDL-50673 - Workshop: display all participants on "Submisstion phase" page in a table
* MDL-50664 - Database: add setting to disallow managing of own entries after approval
* MDL-50658 - LTI: Add support for LTI Memberships service
* MDL-49581 - Lesson: Remove high scores list feature
* MDL-49882 - Lesson: Essay questions are not imported into the lesson Module
* MDL-50720 - Database: Highlight database entries that are not yet approved.

===User interface and usability improvements===

* MDL-51051 - Rename 'Categories and items' to 'Gradebook setup' and add link
* MDL-51250 - Show default section name when editing section details with default checkbox being checked
* MDL-49984 - Add visual blocks outlines to My profile page to help separate information
* MDL-48947 - Collect all course section editing buttons under one "Edit" dropdown
* MDL-51087 - Use client-side validation in the signup form
* MDL-50113 - Improve display of long user and course names in Messaging
* MDL-50919 - Simplify the Manage tags page, allow to quickly change name, flag and official status of the tags
* MDL-51013 - Navbar button should appear for smaller screens only when the custom menu or language menu is not empty
* MDL-51260 - Use the new autocomplete form field for tags
* MDL-51296 - Add title to page when adding blog post
* MDL-38763 - Permission override UI should use JS confirmation
* MDL-29763 - Add description to Portfolio settings page

===Atto editor===

* MDL-45515 - New table editing features in Atto editor
* MDL-49732 - Keyboard interaction for hyperlink in Atto (Ctrl+K)
* MDL-50936 - More Atto Math Equation buttons (sum, sqrt, int, etc.)
* MDL-50142 - Text editor preferences help pop-up

===Enrolments===

* MDL-30674 - Set guest access key from enrolment methods page
* MDL-30157 - Allow users to start manual enrolments right now
* MDL-49746 - Allow to sort enrolled users page by last course access
* MDL-48074 - Group filter in enrolments list should have option "not in any group"

===Administration===

* MDL-49329 - Multiple improvements in the plugins installation/update system including ability to install several plugins at the same time
* MDL-49280 - New configuration setting to allow duplicate email addresses
* MDL-51330 - Show scheduled tasks component in the cron log
* MDL-51261 - Upgrade key - mechanism to protect anonymous web access to upgrade screens
* MDL-50602 - New settings in [https://docs.moodle.org/30/en/Automated_course_backup Automated backup setup] for deleting older backups and keeping a minimum number of backups
* MDL-48438 - Add real name to email about login failures
* MDL-30960 - New option in email settings to specify SSL or TLS (SMTPSecure property of PHPMailer)
* MDL-46623, MDL-51824 - CAS and LDAP: Replace CLI script to synchronise users with a scheduled tasks
* MDL-39319 - Allow administrator to uninstall several languages in one single action
* MDL-50155 - Move and rename "Common activities settings" link to be under "Manage activities" for consistency
* MDL-50631 - Display Moodle ASCII logo in CLI installer
* MDL-46167 - New option for CLI installation: skip database
* MDL-50572 - Disable Youtube repository by default since it requires setting up
* MDL-51739 - Lock theme selector UI when $CFG->theme is hardcoded in config.php
* MDL-51478 - Enable Mobile services by default
* MDL-19748 - Do not allow to edit tags in the default authenticated user role
* MDL-46398 - Make HTML5 video the default player for capable videos

===Other improvements===

* MDL-51132 - Introduce course tagging as a replacement for user-course-tagging in the "Tags" block. See [https://docs.moodle.org/30/en/Tags_block#Course_tagging_changes_in_Moodle_3.0 upgrade documentation]
* MDL-41042 - Course contacts shown in course listings no longer lag by an hour
* MDL-44273 - Back-off strategy for RSS feeds
* MDL-45981 - CAS Auth Config needs way to specify that curl should use SSLv3.
* MDL-49891 - Add description meta to frontpage
* MDL-25451 - Go straight to "Permissions" from block context menu instead of "Assign roles" if theya are not available
* MDL-50647 - Add 'not in group' section to group overview page
* MDL-50956 - Allow main menu block to be displayed "throughout the entire site"
* MDL-28954 - Allow images and embedded files in the cohort descriptions
* MDL-50371 - Use $CFG->gradepointdefault for new manual gradeitems and grade categories

==Security issues==

A number of security related issues were resolved. Details of these issues will be released after a period of approximately one week to allow system administrators to safely update to the latest version.

==For developers==

* MDL-46455 - Events must define fields mappings in order to be correctly restored ([https://docs.moodle.org/dev/Event_2#Backup.2Frestore documentation])
* MDL-50125 - Allow all plugins to inject links in the preferences page ([https://docs.moodle.org/dev/Navigation_API#Course_settings documention])
* MDL-51247 - Revive / refresh / rebuild the autocomplete mform element.
* MDL-50839 - Allow themes to set User menu avatar size ([https://docs.moodle.org/dev/Customising_the_theme_user_menu documentation])
* MDL-48494 - Make $plugin->component required for all plugins
* MDL-43896 - Drop support for $module in version.php files for Moodle 3.0
* MDL-50645 - Cache the list of available callbacks per plugin
* MDL-33564 - rss_error() should return a proper HTTP response code
* MDL-37864 - New method to add help icons to the sortable table headers ([https://docs.moodle.org/dev/lib/tablelib.php documentation])
* MDL-51737 - Add ability to detect MS Edge in our browser sniffing code
* MDL-51213 - external_format_text should be safe to call from web or webservice ([https://docs.moodle.org/dev/How_to_contribute_a_web_service_function_to_core documentation])
* MDL-51413 - Add an additional return field in get_forums_by_courses in order to specify if the current user can create discussions
* MDL-51217 - Using recaptcha is not possible outside auth_email plugin.
* MDL-51107 - Add a callback to inject nodes in the category settings navigation ([https://docs.moodle.org/dev/Navigation_API#Category_settings documention])
* MDL-50891 - is_web_crawler should be moved to useragent class
* MDL-50453 - Replace reserved word usage from \core\progress\null (PHP7)
* MDL-50009 - Prevent scheduled tasks from leaving unfinished db transactions
* MDL-49821 - Some Web Services miss checks for guest and deleted users
* MDL-50926 - Upgrade to phpunit 4.x
* MDL-50491 - New format_text option to exclude particular filters
* MDL-50783 - Allow some ajax external functions to be called without a session
* MDL-50150 - Add "Blocks" feature to JS and PHP mustache engines ([https://docs.moodle.org/dev/Templates#Blocks_.28Moodle_3.0_onwards.29 documentation])

[[Category:Release notes]]
[[Category:Moodle 3.0]]

[[fr:Notes de mise à jour de Moodle 3.0]]
[[es:Notas de Moodle 3.0]]

Navigation API

2015-11-03T06:52:12Z

FMCorz: Adding settings navigation callback (user, category, course and frontpage)

==Overview==
The Navigation API allows for the manipulation of the navigation system used in Moodle.

==What the navigation is==
It's very important to understand what the navigation is exactly within Moodle. One of the goals for Moodle 2.0 was to standardise navigation throughout Moodle and try to bring order to the structure of a Moodle site. Navigation is available through the page object '''$PAGE''', against which you set the heading for the page, the title, any JavaScript requirements, etc. The navigation structure uses the information $PAGE contains to generate a navigation structure for the site. The navigation or settings [[blocks]] are interpretations of the navigation structure Moodle creates.

This navigation structure is available through three variables:

; $PAGE->navigation : This is the main navigation structure, it will contain items that will allow the user to browse to the other available pages.
; $PAGE->settingsnav : This is the settings navigation structure contains items that will allow the user to edit settings.
; $PAGE->navbar : The navbar is a special structure for page breadcrumbs.

==What the navigation is not==
The navigation is '''NOT''' the navigation block or the settings block! These two blocks were created to display the navigation structure. The navigation block looks at ''$PAGE->navigation'', and the settings block looks at ''$PAGE->settingsnav''. Both blocks interpret their data into an HTML structure and render it.

# The navigation is a back-end structure that is built behind the scenes and has no immediate method of display.
# The navigation and settings blocks display the back-end navigation structure but add nothing to it at all.
::In the [[model-view-controller pattern]], $PAGE->navigation, $PAGE->settingsnav, and $PAGE->navbar are the models, and the blocks are views.

The navbar is just the path to the active navigation or settings item. The navbar is not displayed by a block; instead it is added into the theme's layout files and displayed by the core renderer.

==How the navigation works==

The main navigation structure can be accessed through '''$PAGE->navigation'''. The navigation and settings are contextual in that they will relate to the page that the user is viewing. This is determined by other $PAGE object properties:
* '''$PAGE->context''' is a Moodle context that immediately outlines the nature of the page the user is viewing.
* '''$PAGE->course''' is the course the user is viewing. This is essential if the context is CONTEXT_COURSE or greater. However, it is also useful in other contexts such as CONTEXT_USER.
* '''$PAGE->cm''' is the course module instance. This is essential if the context is CONTEXT_MODULE or greater.
* '''$PAGE->url''' is used to match the active navigation item.

Nearly every page sets $PAGE->url through a call to '''$PAGE->set_url''' however not many explicitly set the context, course, or cm. When you call '''require_login''' with a course or cm it automatically calls the following:
<code php>
if ($cm) {
$PAGE->set_cm($cm, $course); // sets up global $COURSE
} else {
$PAGE->set_course($course);// sets up global $COURSE
</code>

A page will only be required to explicitly set a context, course, or cm under one of these conditions:
# '''require_login''' is NOT being called correctly
# The page is using CONTEXT_SYSTEM, CONTEXT_COURSECAT, or CONTEXT_USER (call '''$PAGE->set_context''' ).
# The page is using a course or cm but it is also using one of the above contexts (call '''$PAGE->set_course''' or '''$PAGE->set_cm''' ).

The navigation structure cannot be generated before the $PAGE object is configured. It is only generated when it is first used, either when something tries to access the structure or when code tries to add to it. The navigation is initialised in a specific order:
# Main navigation structure
# Settings navigation
# Navbar (does not need to be generated because of its simple contents and rendering)

==Extending the navigation==

===Code extension===
This method of extending is when the code arbitrarily extends the navigation during its execution. Extending the navigation through this means allows you to extend the navigation anywhere easily, however it will only be shown on pages where your extending code gets called (you should probably put it in a function within lib.php).

These examples are taken from the [http://moodle.org/mod/forum/discuss.php?d=152391 General Developer Forum: Moodle 2 - how to set up breadcrumbs for a module page]. It has further information that is well worth reading.
====Navigation====
This is extending the main navigation structure.
<code php>
$previewnode = $PAGE->navigation->add(get_string('preview'), new moodle_url('/a/link/if/you/want/one.php'), navigation_node::TYPE_CONTAINER);
$thingnode = $previewnode->add(get_string('name of thing'), new moodle_url('/a/link/if/you/want/one.php'));
$thingnode->make_active();
</code>
The above lines of code adds a preview node to the bottom of the navigation and then adds a thingnode to the previewnode (adding a leaf to our tree).
The final line of code makes the thingnode active so that the navbar finds it however if the URL you give it is the same as the url you set for the page it will automatically be marked active and you won't need this call.

Next extending the navigation for the course.
For this you will need to know the course id and have called require_login($courseorid); so that the navigation is loaded for the course.
<code php>
$coursenode = $PAGE->navigation->find($courseid, navigation_node::TYPE_COURSE);
$thingnode = $coursenode->add(get_string('Name of thing'), new moodle_url('/a/link/if/you/want/one.php'));
$thingnode->make_active();
</code>
The new bit of code here really is the first line which simply finds the course node, to do this we give it the course id and the node type in this case TYPE_COURSE.
What we are doing here is relying on the navigation to generate the navigation up to the course and then just adding to the course.

Note that Moodle loads plugins in alphabetical order. Therefore plugin_b can find a node added by plugin_a but not the other way around.
====Settings navigation====
Adding to the settings navigation is very similar to navigation
<code php>
$settingnode = $PAGE->settingsnav->add(get_string('setting'), new moodle_url('/a/link/if/you/want/one.php'), navigation_node::TYPE_CONTAINER);
$thingnode = $settingnode->add(get_string('Name of thing'), new moodle_url('/a/link/if/you/want/one.php'));
$thingnode->make_active();
</code>

====Add Settings folder to navigation====

An example of a settings folder in a module can be see by navigating to Site administration / Plugins / Activity modules / Assignment.

[[File:assignmentmenu.png]]

An example of adding a navigation folder to a settings.php for a block with a link to the settings page and a external page is bellow.

<code php>
<?php

defined('MOODLE_INTERNAL') || die;

// Create folder / submenu in block menu, modsettings for activity modules, localplugins for Local plugins.
// The default folders are defined in admin/settings/plugins.php.
$ADMIN->add('blocksettings', new admin_category('blocksamplefolder',
get_string('pluginname', 'mod_sample')));

// Create settings block.
$settings = new admin_settingpage($section, get_string('settings', 'block_sample'));
if ($ADMIN->fulltree) {
$settings->add(new admin_setting_configcheckbox('block_sample_checkbox', get_string('checkbox', 'block_sample'),
get_string('checkboxdescription', 'block_kronoshtml'), 0));
}

// This adds the settings link to the folder/submenu.
$ADMIN->add('blocksamplefolder', $settings);
// This adds a link to an external page.
$ADMIN->add('blocksamplefolder', new admin_externalpage('block_sample_page', get_string('externalpage', 'block_sample'),
$CFG->wwwroot.'/blocks/sample/sample.php'));
// Prevent Moodle from adding settings block in standard location.
$settings = null;
</code>

====Navbar====
This is extending the settings navigation.
<code php>
$PAGE->navbar->ignore_active();
$PAGE->navbar->add(get_string('preview'), new moodle_url('/a/link/if/you/want/one.php'));
$PAGE->navbar->add(get_string('name of thing'), new moodle_url('/a/link/if/you/want/one.php'));
</code>
The above code tells the navbar to ignore what ever the active page was and just use what you add, at which point we add two items as shown.
===Plugin Callbacks===
These are specific functions that the navigation looks for and calls if they exist for the plugin, presently only three plugin types can extend the navigation through these call-backs.

Ideally all entries in "Administration / Site administration" tree should be done via settings.php files but sometimes it may be easier to directly modify the navigation structure created from the admin settings tree (such as when adding links to external pages).

====Module====
Modules have two call-back methods, first to extend the navigation, and second to extend the settings. These call-backs get called when ever the user is viewing a page within the module and should only extend the navigation for the module.
<code php>
function {modulename}_extend_navigation(${modulename}node, $course, $module, $cm)
function {modulename}_extend_settings_navigation($settings, ${modulename}node)
</code>

====Course Formats====
Course formats are able to completely redefine the way in which navigation is generated for a course, as well as this they also have several methods to ensure the navigation is generated correctly.

====Course Reports====
By default reports don't add themselves or anything else to the navigation however there is a call-back that can be implemented to allow them to do so.

====Local Plugins====
{{Moodle 2.9}}Local plugins have two call-back methods, first to extend the navigation, and second to extend the settings.
<code php>
function local_{pluginname}_extend_navigation(global_navigation $nav)
function local_{pluginname}_extend_settings_navigation(settings_navigation $nav, context $context)
</code>

In versions before Moodle 2.9, the supported callbacks have <tt>_extends_</tt> (not imperative mood) in their names. This was a consistency bug fixed in MDL-49643.

<code php>
function local_{pluginname}_extends_navigation(global_navigation $nav)
function local_{pluginname}_extends_settings_navigation(settings_navigation $nav, context $context)
</code>

====Course settings====
{{Moodle 3.0}}
Any plugin implementing the following callback in lib.php can extend the course settings navigation. Prior to 3.0 only ''reports'' and ''admin tools'' could extend the course settings navigation.

<code php>
function <component>_extend_navigation_course(navigation_node $parentnode, stdClass $course, context_course $context);
</code>

====User settings====
{{Moodle 3.0}}
Any plugin implementing the following callback in lib.php can extend the user settings navigation. Prior to 3.0 only ''admin tools'' could extend the user settings navigation.

<code php>
function <component>_extend_navigation_user_settings(navigation_node $parentnode, stdClass $user, context_user $context, stdClass $course, context_course $coursecontext);
</code>

====Category settings====
{{Moodle 3.0}}
Any plugin implementing the following callback in lib.php can extend the category settings navigation.

<code php>
function <component>_extend_navigation_category_settings(navigation_node $parentnode, context_coursecat $context);
</code>

====Frontpage settings====
{{Moodle 3.0}}
Any plugin implementing the following callback in lib.php can extend the frontpage settings navigation. Prior to 3.0 only ''admin tools'' could extend the frontpage settings navigation.

<code php>
function <component>_extend_navigation_frontpage(navigation_node $parentnode, stdClass $course, context_course $context);
</code>

==FAQ's and troubleshooting==
'''Q.''' My page is on the navigation but it doesn't find it?

The first thing to do here is check the URL you are setting for the page. It should match the URL your page has within the navigation. If it doesn't you have two options, first change your '''$PAGE->set_url''' call, or second override the URL the navigation is using to find the active node as shown below:
<code php>
navigation_node::override_active_url(new moodle_url('/your/url/here.php', array('param'=>'value')));
</code>

==See also==

* [[Core APIs]]
* [https://moodle.org/mod/forum/discuss.php?d=170325&parent=753095 Forum discussion - adding navigation to local plugins]

[[Category:API]]

Template:Moodle 3.0

2015-11-03T06:51:50Z

FMCorz: Creating the template for 3.0

<span class="small-info-right">Moodle <span class="text-big new">3.0</span></span>
<includeonly>[[Category:Moodle 3.0]]</includeonly>
<noinclude>This template will categorize articles that include it into [[:Category:Moodle 3.0]].</noinclude>

Competency Based Education

2015-10-28T02:40:13Z

FMCorz: /* Students */

{{Infobox Project
|name = Framework for competency-based education (CBE) in Moodle
|state = In Progress
|tracker = MDL-49458
|discussion = https://moodle.org/mod/forum/discuss.php?d=316151
|assignee = [[User:Damyon Wiese]]
}}

{{Work in progress}}

=Framework for competency-based education (CBE) in Moodle=

==Summary==

This specification describes our plan to improve support for outcomes-based education in Moodle core. There have been many other attempts to add such systems to Moodle but they all use different data structures and processes and are incompatible. Our aim here is to build basic central structures and APIs to store and manipulate this data, allowing the Moodle community to build innovative custom interfaces on top of it.

This design is based on input from many existing implementations of outcomes/competencies and learning plans including:

* “Outcomes 2” in Joule
* Totara
* Referentiel Activity Module (Skills Repository)
* ELIS

The goal is to implement a system that supports competency based education in a flexible way so that it can be used effectively by the many different target audiences.

The two main concepts are:

'''Competencies''' - a unit of learning, such as "Can make exceptional beer". Competencies can be assigned as goals of courses “This course will teach you to make exceptional beer”, and also to users: “Billy can make exceptional beer”.
Competencies can also be hierarchical, so that the competency above might be marked proficient when some combination of sub-competencies has been marked proficient.
For example : Can make exceptional beer ( Can choose good malt / Can choose good yeasts / Can brew beer in the good temperature / etc..)

'''Learning plans''' - a set of competencies that can be assigned to a student (or cohorts of students). Initially, they will all be marked "incomplete". As students achieve each competency it is marked complete, thereby showing their progress towards finishing all of them. Students achieve competencies either automatically (by successfully completing a course with that competency) or manually (by proving to someone that they are competent via portfolio items etc).

== Competencies ==

A competency is a unit of learning. All competencies belong to a competency framework, and it is likely that a competency framework will be defined by an external body such as an academic standards board.

To create a competency, you first define the framework and then add the competency to it.

Competency frameworks are defined by “Framework Administrators” at the site level, or at a category level. To create and edit competency frameworks, go to “Site administration” -> “Competency Frameworks”, or "Category administration -> Competency frameworks".

[[Image:cbe_spec21_v2.jpg|frame|center|Manage competency frameworks]]<div style="clear: both"></div>

[[Image:cbe_spec19_v3.jpg|frame|center|Add new competency framework]]<div style="clear: both"></div>

Choose “Add new competency framework” and create a new competency framework.

The scale defines how a competency is marked as complete. Each competency framework can define which of the standard Moodle scales should be used when marking a competency. In addition, the “default” value from the scale (the one automatically set when a course is completed) can be configured, and the items from the scale that are deemed to be “proficient” can be defined. A "default" value and at least one "proficient" value must be defined.

A competency framework may be available to the entire site - or limited to a course category.

The taxonomy refers to the naming for each level in the framework. Up to 4 levels are supported, and the name for each level can be set from the following list:
Domain, Competency, Behaviour, Indicator, Outcome, Level, Concept, Value, Practice, Skill, Proficiency

[[Image:cbe_spec02.jpg|frame|center|Configure scale]]<div style="clear: both"></div>

Now we need to add competencies to the framework. We can import these from a file, or create them from scratch, or import them from Moodle outcomes. When importing competencies, any existing competencies with a matching idnumber will be updated.

[[Image:cbe_spec15.jpg|frame|center|Import competencies]]<div style="clear: both"></div>

Competencies can be imported from the following formats:

(TBD - start with import from CSV).

To see the competencies for a framework, click on the competency framework name.

[[Image:cbe_spec06_v2.jpg|frame|center|Manage competencies]]<div style="clear: both"></div>

This is where we can add and edit competencies in a framework. To edit an existing competency, select it in the competencies tree browser and choose “Edit” from the action menu in the selected competency panel.

To add a new competency, first select the competency that should be the “parent” of this competency from the tree of competencies, and then click “Add Indicator” (the name comes from the taxonomy) from the selected competency panel. Competencies can have a maximum of 3 descendants (4 levels). Tags can be used to categorise competencies for easy searching, e.g. year level, subject. Tags used for competencies are kept in a separate “tagcloud” (see https://tracker.moodle.org/browse/MDL-50851).

A competency framework can be duplicated, and there is an admin tool for migrating courses from one framework to another (as long as the idnumbers between the competencies in the frameworks can be matched).

If a competency has sub-competencies, you can configure the completion rule for the competency. The default completion rule is “Completed when all sub-competencies are complete”. For more complex rules - you can use a points based system to say when to complete or recommend a competency.

[[Image:cbe_spec23.jpg|frame|center|Add a competency]]<div style="clear: both"></div>

Competencies can be “related” to other competencies within the same framework. The only effect of this is that the related competencies are listed in the summary of each competency, whenever it is displayed in Moodle. To add a “related” competency to an existing competency, select it from the competency framework and choose “Add related competency” from the action menu.

[[Image:cbe_spec03_v2.jpg|frame|center|Relating competencies to each other]]<div style="clear: both"></div>

== Learning plan templates ==

It would be cumbersome to individually add competencies to a large group of students, and it would be awkward if you made a mistake and had to change the competencies for all the students at a later date. To make this manageable, you can create a “Learning plan template” and assign it to many students. An example of a learning plan template could be: “Computer science, Undergraduate” which lists all the required competencies for a first year computer science student, or it could be more fine grained.

Templates are created by a ”Learning Plan Administrator”. Templates can be imported and exported via CSV. Learning plan templates can be created at a course category, or a site level.

[[Image:cbe_spec22_v2.jpg|frame|center|Manage Learning Plan Templates]]<div style="clear: both"></div>

Once you have created a template, you can add competencies to it.

[[Image:cbe_spec18.jpg|frame|center|List competencies in a template]]<div style="clear: both"></div>

[[Image:cbe_spec00.jpg|frame|center|Add competency to a template]]<div style="clear: both"></div>

Adding competencies to a template will update all the learning plans based on that template.

== User learning plans ==

A user learning plan is a collection of all the competencies they should achieve, optionally before a certain date.

Any user can create their own learning plan, if they have the capability on their own context.

A “Learning Plan Administrator” can create learning plans for other users. They can create the plans individually though another users profile page, or they can create learning plans in bulk from a learning plan template.

Users learning plans can be in one of 3 states, Draft, Active or Completed. Only someone with the capability tool/lp:planmanage (or tool/lp:planmanageown if it’s their own plan) capability can approve learning plans.

A plan can be manually set to completed, by someone with the capabilities listed above, or it will be set to completed when the due date for the plan expires.

[[Image:cbe_spec07.jpg|frame|center|Single users learning plans page]]<div style="clear: both"></div>

[[Image:cbe_spec16.jpg|frame|center|Bulk create user learning plans]]<div style="clear: both"></div>

Note that sites using enrolment plugins can create a cohort based on the enrolments of a set of courses using the admin tool “Course cohorts”. More detail required here.

Competencies can be added to a users learning plan, or to the template the plan was created from and they will automatically appear in the users learning plan. Competencies that exist in the template cannot be removed from the users learning plan. If a single student requires e.g. exemptions from certain competencies - their learning plan can be "unlinked" from the template. This plan will no longer show up in reports generated from the learning plan template - but can now be freely edited.

[[Image:cbe_spec12.jpg|frame|center|User learning plan competencies]]<div style="clear: both"></div>

Note, there can be multiple types of evidence for the same competency. E.g. 2 courses may provide evidence for the same competency and both courses were completed. In this case - both would show as evidence. There can also be multiple examples of "Evidence of prior learning" attached to each competency.<br /><br />Each competency in the table is colour coded to indicate one of the following:

* brown - competency not met, and no evidence or enrolled courses cover this competency
* orange - the competency is not met, but there is evidence, or “in-progress” courses that cover this competency
* green - the competency has been met

If you have the capability tool/lp:planaddevidence you can upload files and urls against a competency in your plan as evidence of prior learning. You can also request that a someone with the capability tool/lp:planmanage reviews the evidence and either rejects or accepts the evidence and changes the status for the competency in the plan.

[[Image:cbe_spec25.jpg|frame|center|Provide evidence]]<div style="clear: both"></div>

[[Image:cbe_spec08.jpg|frame|center|Link evidence]]<div style="clear: both"></div>

To view all the current requests for review, a new “Learning plans” block can be added to an “approvers” dashboard.

[[Image:cbe_spec10.jpg|frame|center|Dashboard Block]]<div style="clear: both"></div>

A User with the capability “tool/lp:competencygrade” (at the context of another users plan) can review and approve competency approval requests. A competency approval request is a request for someone to review the evidence that a user has provided against a specific competency and make a decision whether the user has either met or not met the competency. The valid statuses for a review are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

There can only be one “review” per competency for each user (if a review is rejected, and then a new request is made, the previous review will be changed from “Rejected” to “Waiting for review”).

Following the link in the Learning Plans dashboard block, the approver goes to a page that lists all the requests waiting to be approved, and from here they can approve or reject each request. They can also leave comments that will be visible to the student, or to any other reviewers.

To allow multiple authorisers to work together, when looking at a review an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a review, or a review is accepted or rejected, the student will receive a message about the change.

When a completion rule triggers a “recommendation” - the evidence will be added to the competency, and the system will request a “review” of this competency.

TODO Define a new page for assigning roles relative to a user. In totara, there is a “positions” page which does this. This will also be useful for “Mentees”.

[[Image:cbe_spec11.jpg|frame|center|Review competency requests]]<div style="clear: both"></div>

If users have the capability to create their own draft learning plans, but not approve them themselves, someone will need to review all the draft learning plan requests and decide whether or not to make them active. This user can be anyone with “tool/lp:planmanage” capability (at the context of each user with a plan to approve) and they can view all the “Learning plans to approve” link in the Learning Plans dashboard block.

A learning plan approval request made by a user with a draft learning plan from their “Manage learning plans page”. Once a request has been made, the valid statuses for a learning plan approval request are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

To allow multiple authorisers to work together, when looking at a learning plans approval request an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a learning plan approval request, or a learning plan approval request is accepted or rejected, the student will receive a message about the change.

[[Image:cbe_spec04.jpg|frame|center|Review Learning Plan Approval Requests]]<div style="clear: both"></div>

== Course Competencies ==

Competencies can also be linked to a course. This means that when a student completes a course (see course completion) - all of the linked competencies will be marked as “complete” or “recommended” in any of the students active learning plans and the course will be added as evidence against that competency. If the competency is already “met”, the course will still be added as evidence for that competency. If the competency is only set to “recommend” the course will be added as evidence and a review request will be created.

The competency will be given the default value from the competency scale. You can select multiple competencies and add them all at once.

[[Image:cbe_spec17.jpg|frame|center|Course Competencies]]<div style="clear: both"></div>

A teacher in a course, can manually mark the students against the course competencies. For each competency, the teacher will see all of the evidence linked to that competency for the student. They then can assign a value from the competency scale for the student, and optionally make a comment. A record of the teacher marking this competency will be added to the evidence of completion for this competency and the status of the competency will be updated in all active learning plans for the student.

TODO - see how the information from the coverage report can be shown when linking course competencies.

[[Image:cbe_spec14.jpg|frame|center|Grading competencies within a course]]<div style="clear: both"></div>

When manually marking a competency, it is recorded as evidence ie: "Teacher X manually specified this value in this course" - so if the same competency is linked to multiple course it can be marked in each, and this will show up as 2 pieces of evidence.

Reports

Students

For an active Learning Plan, students can see a report of the competencies that are covered/not covered by their current list of enrolled courses. For each competency, they should also be able to see which courses they could enrol in to meet that competency.

[[Image:cbe_spec24.jpg|frame|center|Student Learning Plan Competencies page shows progress, and course discovery]]<div style="clear: both"></div>

Students can see a list of their active learning plans on their dashboard, with a visual indication of progress (a progress bar). Each learning plan is a link to the learning plan report shown above.

Teachers

For teachers and course designers building a set of courses against a competency framework, they should be able to identify competencies that are over/underrepresented by a set of courses. To do this they access a learning plan template, and view the coverage report for that template. This competency coverage report initially shows the coverage from all courses that link to one of the competencies in the template, but the teacher can remove some courses from the selection and regenerate the report.

[[Image:cbe_spec09.jpg|frame|center|Coverage report]]<div style="clear: both"></div>

Teachers and course designers can also see some statistics about a learning plan template. From the learning plan template page, they choose “Statistics” from the action menu to see the number of active/completed learning plans using this template, and the average completion % for the learning plans.

[[Image:cbe_spec13.jpg|frame|center|Statistics for Learning Plan Template]]<div style="clear: both"></div>

Teachers can also see a report in a course that shows for each course competency, which users have completed or not completed it.

[[Image:cbe_spec05.jpg|frame|center|Breakdown report]]<div style="clear: both"></div>

== User roles and capabilities ==

In this system, the actions a user can perform are governed by various capabilities, and are checked at one of several different context levels.

As a reference, the relevant context levels in Moodle are organised in a tree like structure and an example is shown below:

* Site
** User A
** User B
** Category A
*** Course A
*** Course B
** Category B
*** Category C
**** Course C
**** Course D

=== Framework Administrators ===

Competency framework administrators are the central people responsible for creating and maintaining the system wide competency frameworks.

The actions a competency framework administrator can take are:

'''Create/Edit/Delete a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Create/Edit/Delete a competency within a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Mark a competency as related to another competency'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

=== Learning Plan Administrators ===

Learning plan administrators are responsible for creating and maintaining learning plan templates relating to e.g. a specific faculty, set of courses, degree or certification.

The actions a learning plan administrator can take are:

'''Create/Edit/Delete a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Add and remove competencies from a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Assign a user a learning plan from a learning plan template'''

Requires “tool/lp:planmanage“ capability defined on the “User” context level.

'''View coverage report for a learning plan template'''

Requires “report/lpcoverage:view“ capability defined on the “Site” or "Course Category" context level.

'''View statistics report for a learning plan template'''

Requires “report/lpstatistics:view“ capability defined on the “Site” or "Course Category" context level.

'''View breakdown report for a learning plan template'''

Requires “report/lpbreakdown:view“ capability defined on the “Course” context level.

'''Approve draft learning plans'''

Requires “tool/lp:planapprove“ capability defined on the “User” context level.

'''Approve competency review requests'''

Requires “tool/lp:competencygrade“ capability defined on the “User” context level.

=== Teachers ===

Teachers create and teach courses, that provide evidence of competencies.

The actions a teacher can take are:

'''Assign competencies to a course'''

Requires “tool/lp:coursecompetencymanage” capability defined at the “Course” context level.

'''Manually grade competencies linked to a course'''

Requires “tool/lp:coursecompetencygrade” capability defined at the “Course” context level.

=== Students ===

Students are users that can have learning plans.

The actions a student can take are:

'''View their own learning plans'''

Requires “tool/lp:planviewown” capability defined at the “User” context level.

'''Create their own draft learning plan'''

Requires “tool/lp:plancreateown” capability defined at the “User” context level.

'''Request approval for their draft learning plan'''

Requires “tool/lp:plancreateown" capability defined at the “User” context level.

'''Provide evidence of prior learning for a competency'''

Requires “tool/lp:planaddevidence” capability defined at the “User” context level.

'''Request for someone to grade them for a specific competency'''

Requires “tool/lp:plancompetencyrequestreview” capability defined at the “User” context level.

== Further work (out of scope for first release) ==

Add a rule to award badges when certain competencies are met

This is a simple addition to the existing rules that can be configured to award a badge.

[[Image:cbe_spec20.jpg|frame|center|Custom badge condition]]<div style="clear: both"></div>

=== Linking activities as evidence of competencies ===

[[Image:cbe_spec01.jpg|frame|center|Linking an activity to some course competencies]]<div style="clear: both"></div>

Teachers can also quickly find resources and activities that have not been mapped to any competencies. This is done on the competency mapping report which shows all resources and activities for the course, as well as the linked competencies for each. This report will also list any course competencies that are not linked to any activities or resources.

=== Alternative ways to “automatically complete” competencies ===

* Trigger based on activity completion. Configured when linking competencies to a course.

=== Additional reports ===

E.g. https://moodle.org/mod/forum/discuss.php?d=316151#p1266980

== Interaction with the existing Moodle “Outcomes” ==

Description of existing “Outcomes”

Outcomes define a set of system wide scales that can be used to grade activities. The value chosen from the scale is pushed to the gradebook for each activity and a custom report will show the average of outcomes across a course, or the entire site. Not all activities and resources support outcomes, only scorm, quiz, lti, lesson, glossary, data, chat, assign and forum.

Any activity that has an outcome attached receives a new column in the gradebook where that outcome is assessed for that activity.

Outcomes has some features that would need to be “removed” in order to make sense with competency frameworks (mainly pushing of grades to the gradebook) - this means we cannot build on outcomes, and maintain backwards compatibility. It is therefore recommended to provide:

* A site wide setting to allow competencies - allow either/or but the default will be competencies with no outcomes.
* A simple way to create a competency framework from an existing set of outcomes.
* (optional - requires activity level competencies) A way to import existing outcomes grades as evidence for competencies.

== Open questions for further feedback ==

* Would you expect a teacher to be able to create their own competencies (limited to their own course)? Would competencies that are visible only to a single course (and potentially conflicting with competencies from another course) be really useful?
* Do we need to allow competencies to be linked to individual questions?
* Do we need to allow competencies to be linked to individual items on a rubric/marking guide?
* How should self-evaluation of competencies work?

== Outstanding work for this spec ==

* The examples should use consistent names for user types, competencies and courses. It would be easier to use a real example of competencies from a real framework
* The terminology for child/parent relationships should consistently be:
** Parent
** Sub-competency
* Technical spec (this doc is the requirements).

Comment API

2015-10-16T06:26:14Z

FMCorz: Adding component to example.

{{Moodle 2.0}}==Objectives==

The goals of Comment API:

* Manage comments centrally
* Use a consistent approach for all comments throughout Moodle
* Easily integrate Comment API with existing modules
* Works no matter Javascript is enabled or not

==Overview==

Comment API provides following functionalities:
# Add comments
# Manage comments
# Delete comments

And provides a fancy ajax interface to add/delete comments without reloading page.

==Comment API database table==

{| class="nicetable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this comment.
|-
| userid
| int(10)
|
| who wrote this comment
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the comment.
|-
| itemid
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission)
|-
| commentarea
| int(10)
|
| for example, in user profile, you can comment user's description or interests, but they share the same itemid(==userid), we need comment_area to separate them
|-
| timecreated
| int(10)
|
|
|-
| timemodified
| int(10)
|
|
|-
| content
| text
|
| content of comment
|}

==Use Comment API==

===Add an option to format_text function===

Using this format_text function will add a comment icon automatically at the end of the text:

For example, using the following code in the forum module will add a comment icon to every post:

<code php>
$cmt = new stdclass;
$cmt->contextid = $modcontext->id;
$cmt->area = 'format_post';
$cmt->itemid = $post->id;
$options->comments = $cmt;
echo format_text($post->message, $post->messageformat, $options, $course->id)."<hr />";
</code>

===Use comment class===
To use Comment API elsewhere, using following code:
<code php>
$options->area = 'database_entry';
$options->context = $context;
$options->itemid = $record->id;
$options->component = 'mod_data';
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>

==Comment API overview==

Generally speaking, only two functions you need to know to get comment API worked:
# Use comment::init to initialize Comment API
# Use $comment->output to display comments

The comment class has been implemented in comment/lib.php.
===class comment()===
====__construct($contextid, $comment_area, $itemid))====
Initialize class members

====init()====
It is a static function used to initialize comments, setting up languages, which must be called before html head printed

====output($return = false)====
Will print the html snippet for commenting interface, if set $return as true, it will return html string instead of printing out.

====print_comments($params = array())====
Used by non-javascript comment interface, will print a list of comments.

====add($content)====
Public instance funciton, add a comment to database, used in comment/comment_ajax.php

====count()====
Counting the number of comments

====delete($id)====
Delete a comment from database, used in comment/comment_ajax.php

====delete_comments====
Delete all comments in a specific contexts (like all comments belonging to a forum post)

==Javascript API==
Comment API implemented a YUI3 module M.core_comment to deal with the communication between browsers and moodle.
It can be found in comment/comment.js

Call M.core_comment.init will create an instance of CommentHelper class. You don't need to make any calls to this instance, it simply works out of box.

== Moodle modules callback ==
Comment API allows modules/blocks/blog to decide how comments display.

=== Data validation ===
This callback method is required, it must be implemented. Otherwise, new comment will be rejected by default.
Plugins must implement pluginname_comment_validate callback to validate comments parameters, it must return true to pass validation.

===Permission control===
Modules must implement function '''pluginname_comment_permissions''' to return post and view permission.

Blocks need to overwrite '''blockname_comment_permissions''' function of block_base.

Blog need to implement '''blog_comment_permissions''' function.

This function will return an array: array('post'=>true, 'view'=>true)

=== Check new added comment ===
The callback function allows you to change the comment content before inserting into database or reject this comment.

It takes two arguments, the comment object which contains comment details, and $params which contains context and course information.

Modules can implement a function named '''modname_comment_add'''.

Blocks need to overwrite '''blockname_comment_add''' function.

Blog need to implement '''blog_comment_add''' function.

This function should return a boolean value.

=== Filter/format comments ===
This callback allows modules check/format comments when user request to display comments.

It takes the same arguments as pluginname_comment_add

Modules can implement a function named '''pluginname_comment_display'''.

Blocks need to overwrite '''blockname_comment_display''' function.

Blog need to implement '''blog_comment_display''' function.

It will return the comment object.

=== Define a comment template ===
Modules can implement a function named '''pluginname_comment_template''', which allow modules define a comment template.
The template must have 4 embedding variables, ___id___, ___content___, ___time___, ___name___, they will be replaced with html id, comments content, comment time and commenter name

== Backup and Restore ==
Comments will automatically be included in the activity/course backups and restored provided the itemids can be updated during the restore process. To do this either:

* do not use item ids and rely just on the context
* make the commentarea the same as one of the mappings in the restore (set_mapping); or
* override the function "get_comment_mapping_itemname" in the restore activity class

If you do not do one of these the comments will be silently ignored on restore.

==See also==
* [[Core APIs]]
* MDL-19118 - Comment API issue

[[Category:API]]

Developer meeting October 2015

2015-10-13T12:06:21Z

FMCorz: /* Agenda draft */

[[Developer meetings]] > October 2015 meeting notes

{| class="nicetable"
|-
| Time
| [http://www.timeanddate.com/worldclock/fixedtime.html?year=2015&month=10&day=21&hour=07&min=0&sec=0 07:00 UTC on Wednesday, 21 October 2015] [http://www.google.com/calendar/event?action=TEMPLATE&text=Moodle+General+developer+meeting&dates=20151021T070000Z/20151021T090000Z&details=https://docs.moodle.org/dev/Developer_meeting_October_2015&location= <span class="btn btn-info">Add to my calendar</span>]
|-
| Meeting room
| Live stream at YouTube (TODO link)
|-
| Forum discussion
| Thread in GDF at moodle.org (TODO link)
|-
| Chat
| Moodle Jabber dev chat (TODO link)
|-
| Twitter
| [https://twitter.com/search?q=%23moodledev #moodledev]
|-
| Social event page
| Google+ page (TODO link)
|-
| Meeting notes
| [https://devpad.moodle.org/p/gdm151021 devpad]
|}

== Agenda draft ==

* Upcoming changes in Moodle 3.0 from Moodle contributor's perspective (both core and plugins development) - Damyon / Marina / David Mu
* MDL-50565, MDL-51011, MDL-51155 Moving towards PHP7 - to be confirmed.
* MDL-50645 Caching the list of callbacks and ability to use them much more often without worrying about performance - David Mo, to be confirmed.
* MDL-51213 Safely callable external_format_text() - Damyon, to be confirmed.
* MDL-51107 Ability to inject nodes in the category settings navigation - Fred
* Plugins versioning schemes - David Mu, to be confirmed.
* ...

----
Please feel encouraged to raise topics you would like to present / discuss during these meetings. Contact [https://moodle.org/user/profile.php?id=1601 David Mudrák] for details.

Competency Based Education

2015-10-02T02:46:46Z

FMCorz: /* User learning plans */

{{Infobox Project
|name = Framework for competency-based education (CBE) in Moodle
|state = In Progress
|tracker = MDL-49458
|discussion = https://moodle.org/mod/forum/discuss.php?d=316151
|assignee = [[User:Damyon Wiese]]
}}

{{Work in progress}}

=Framework for competency-based education (CBE) in Moodle=

==Summary==

This specification describes our plan to improve support for outcomes-based education in Moodle core. There have been many other attempts to add such systems to Moodle but they all use different data structures and processes and are incompatible. Our aim here is to build basic central structures and APIs to store and manipulate this data, allowing the Moodle community to build innovative custom interfaces on top of it.

This design is based on input from many existing implementations of outcomes/competencies and learning plans including:

* “Outcomes 2” in Joule
* Totara
* Referentiel Activity Module (Skills Repository)
* ELIS

The goal is to implement a system that supports competency based education in a flexible way so that it can be used effectively by the many different target audiences.

The two main concepts are:

'''Competencies''' - a unit of learning, such as "Can make exceptional beer". Competencies can be assigned as goals of courses “This course will teach you to make exceptional beer”, and also to users: “Billy can make exceptional beer”.
Competencies can also be hierarchical, so that the competency above might be marked proficient when some combination of sub-competencies has been marked proficient.
For example : Can make exceptional beer ( Can choose good malt / Can choose good yeasts / Can brew beer in the good temperature / etc..)

'''Learning plans''' - a set of competencies that can be assigned to a student (or cohorts of students). Initially, they will all be marked "incomplete". As students achieve each competency it is marked complete, thereby showing their progress towards finishing all of them. Students achieve competencies either automatically (by successfully completing a course with that competency) or manually (by proving to someone that they are competent via portfolio items etc).

== Competencies ==

A competency is a unit of learning. All competencies belong to a competency framework, and it is likely that a competency framework will be defined by an external body such as an academic standards board.

To create a competency, you first define the framework and then add the competency to it.

Competency frameworks are defined by “Framework Administrators” at the site level, or at a category level. To create and edit competency frameworks, go to “Site administration” -> “Competency Frameworks”, or "Category administration -> Competency frameworks".

[[Image:cbe_spec21_v2.jpg|frame|center|Manage competency frameworks]]<div style="clear: both"></div>

[[Image:cbe_spec19_v3.jpg|frame|center|Add new competency framework]]<div style="clear: both"></div>

Choose “Add new competency framework” and create a new competency framework.

The scale defines how a competency is marked as complete. Each competency framework can define which of the standard Moodle scales should be used when marking a competency. In addition, the “default” value from the scale (the one automatically set when a course is completed) can be configured, and the items from the scale that are deemed to be “proficient” can be defined. A "default" value and at least one "proficient" value must be defined.

A competency framework may be available to the entire site - or limited to a course category.

The taxonomy refers to the naming for each level in the framework. Up to 4 levels are supported, and the name for each level can be set from the following list:
Domain, Competency, Behaviour, Indicator, Outcome, Level, Concept, Value, Practice, Skill, Proficiency

[[Image:cbe_spec02.jpg|frame|center|Configure scale]]<div style="clear: both"></div>

Now we need to add competencies to the framework. We can import these from a file, or create them from scratch, or import them from Moodle outcomes. When importing competencies, any existing competencies with a matching idnumber will be updated.

[[Image:cbe_spec15.jpg|frame|center|Import competencies]]<div style="clear: both"></div>

Competencies can be imported from the following formats:

(TBD - start with import from CSV).

To see the competencies for a framework, click on the competency framework name.

[[Image:cbe_spec06_v2.jpg|frame|center|Manage competencies]]<div style="clear: both"></div>

This is where we can add and edit competencies in a framework. To edit an existing competency, select it in the competencies tree browser and choose “Edit” from the action menu in the selected competency panel.

To add a new competency, first select the competency that should be the “parent” of this competency from the tree of competencies, and then click “Add Indicator” (the name comes from the taxonomy) from the selected competency panel. Competencies can have a maximum of 3 descendants (4 levels). Tags can be used to categorise competencies for easy searching, e.g. year level, subject. Tags used for competencies are kept in a separate “tagcloud” (see https://tracker.moodle.org/browse/MDL-50851).

A competency framework can be duplicated, and there is an admin tool for migrating courses from one framework to another (as long as the idnumbers between the competencies in the frameworks can be matched).

If a competency has sub-competencies, you can configure the completion rule for the competency. The default completion rule is “Completed when all sub-competencies are complete”. For more complex rules - you can use a points based system to say when to complete or recommend a competency.

[[Image:cbe_spec23.jpg|frame|center|Add a competency]]<div style="clear: both"></div>

Competencies can be “related” to other competencies within the same framework. The only effect of this is that the related competencies are listed in the summary of each competency, whenever it is displayed in Moodle. To add a “related” competency to an existing competency, select it from the competency framework and choose “Add related competency” from the action menu.

[[Image:cbe_spec03_v2.jpg|frame|center|Relating competencies to each other]]<div style="clear: both"></div>

== Learning plan templates ==

It would be cumbersome to individually add competencies to a large group of students, and it would be awkward if you made a mistake and had to change the competencies for all the students at a later date. To make this manageable, you can create a “Learning plan template” and assign it to many students. An example of a learning plan template could be: “Computer science, Undergraduate” which lists all the required competencies for a first year computer science student, or it could be more fine grained.

Templates are created by a ”Learning Plan Administrator”. Templates can be imported and exported via CSV. Learning plan templates can be created at a course category, or a site level.

[[Image:cbe_spec22_v2.jpg|frame|center|Manage Learning Plan Templates]]<div style="clear: both"></div>

Once you have created a template, you can add competencies to it.

[[Image:cbe_spec18.jpg|frame|center|List competencies in a template]]<div style="clear: both"></div>

[[Image:cbe_spec00.jpg|frame|center|Add competency to a template]]<div style="clear: both"></div>

Adding competencies to a template will update all the learning plans based on that template.

== User learning plans ==

A user learning plan is a collection of all the competencies they should achieve, optionally before a certain date.

Any user can create their own learning plan, if they have the capability on their own context.

A “Learning Plan Administrator” can create learning plans for other users. They can create the plans individually though another users profile page, or they can create learning plans in bulk from a learning plan template.

Users learning plans can be in one of 3 states, Draft, Active or Completed. Only someone with the capability tool/lp:planmanage (or tool/lp:planmanageown if it’s their own plan) capability can approve learning plans.

A plan can be manually set to completed, by someone with the capabilities listed above, or it will be set to completed when the due date for the plan expires.

[[Image:cbe_spec07.jpg|frame|center|Single users learning plans page]]<div style="clear: both"></div>

[[Image:cbe_spec16.jpg|frame|center|Bulk create user learning plans]]<div style="clear: both"></div>

Note that sites using enrolment plugins can create a cohort based on the enrolments of a set of courses using the admin tool “Course cohorts”. More detail required here.

Competencies can be added to a users learning plan, or to the template the plan was created from and they will automatically appear in the users learning plan. Competencies that exist in the template cannot be removed from the users learning plan. If a single student requires e.g. exemptions from certain competencies - their learning plan can be "unlinked" from the template. This plan will no longer show up in reports generated from the learning plan template - but can now be freely edited.

[[Image:cbe_spec12.jpg|frame|center|User learning plan competencies]]<div style="clear: both"></div>

Note, there can be multiple types of evidence for the same competency. E.g. 2 courses may provide evidence for the same competency and both courses were completed. In this case - both would show as evidence. There can also be multiple examples of "Evidence of prior learning" attached to each competency.<br /><br />Each competency in the table is colour coded to indicate one of the following:

* brown - competency not met, and no evidence or enrolled courses cover this competency
* orange - the competency is not met, but there is evidence, or “in-progress” courses that cover this competency
* green - the competency has been met

If you have the capability tool/lp:planaddevidence you can upload files and urls against a competency in your plan as evidence of prior learning. You can also request that a someone with the capability tool/lp:planmanage reviews the evidence and either rejects or accepts the evidence and changes the status for the competency in the plan.

[[Image:cbe_spec25.jpg|frame|center|Provide evidence]]<div style="clear: both"></div>

[[Image:cbe_spec08.jpg|frame|center|Link evidence]]<div style="clear: both"></div>

To view all the current requests for review, a new “Learning plans” block can be added to an “approvers” dashboard.

[[Image:cbe_spec10.jpg|frame|center|Dashboard Block]]<div style="clear: both"></div>

A User with the capability “tool/lp:competencygrade” (at the context of another users plan) can review and approve competency approval requests. A competency approval request is a request for someone to review the evidence that a user has provided against a specific competency and make a decision whether the user has either met or not met the competency. The valid statuses for a review are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

There can only be one “review” per competency for each user (if a review is rejected, and then a new request is made, the previous review will be changed from “Rejected” to “Waiting for review”).

Following the link in the Learning Plans dashboard block, the approver goes to a page that lists all the requests waiting to be approved, and from here they can approve or reject each request. They can also leave comments that will be visible to the student, or to any other reviewers.

To allow multiple authorisers to work together, when looking at a review an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a review, or a review is accepted or rejected, the student will receive a message about the change.

When a completion rule triggers a “recommendation” - the evidence will be added to the competency, and the system will request a “review” of this competency.

TODO Define a new page for assigning roles relative to a user. In totara, there is a “positions” page which does this. This will also be useful for “Mentees”.

[[Image:cbe_spec11.jpg|frame|center|Review competency requests]]<div style="clear: both"></div>

If users have the capability to create their own draft learning plans, but not approve them themselves, someone will need to review all the draft learning plan requests and decide whether or not to make them active. This user can be anyone with “tool/lp:planmanage” capability (at the context of each user with a plan to approve) and they can view all the “Learning plans to approve” link in the Learning Plans dashboard block.

A learning plan approval request made by a user with a draft learning plan from their “Manage learning plans page”. Once a request has been made, the valid statuses for a learning plan approval request are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

To allow multiple authorisers to work together, when looking at a learning plans approval request an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a learning plan approval request, or a learning plan approval request is accepted or rejected, the student will receive a message about the change.

[[Image:cbe_spec04.jpg|frame|center|Review Learning Plan Approval Requests]]<div style="clear: both"></div>

== Course Competencies ==

Competencies can also be linked to a course. This means that when a student completes a course (see course completion) - all of the linked competencies will be marked as “complete” or “recommended” in any of the students active learning plans and the course will be added as evidence against that competency. If the competency is already “met”, the course will still be added as evidence for that competency. If the competency is only set to “recommend” the course will be added as evidence and a review request will be created.

The competency will be given the default value from the competency scale. You can select multiple competencies and add them all at once.

[[Image:cbe_spec17.jpg|frame|center|Course Competencies]]<div style="clear: both"></div>

A teacher in a course, can manually mark the students against the course competencies. For each competency, the teacher will see all of the evidence linked to that competency for the student. They then can assign a value from the competency scale for the student, and optionally make a comment. A record of the teacher marking this competency will be added to the evidence of completion for this competency and the status of the competency will be updated in all active learning plans for the student.

TODO - see how the information from the coverage report can be shown when linking course competencies.

[[Image:cbe_spec14.jpg|frame|center|Grading competencies within a course]]<div style="clear: both"></div>

When manually marking a competency, it is recorded as evidence ie: "Teacher X manually specified this value in this course" - so if the same competency is linked to multiple course it can be marked in each, and this will show up as 2 pieces of evidence.

Reports

Students

For an active Learning Plan, students can see a report of the competencies that are covered/not covered by their current list of enrolled courses. For each competency, they should also be able to see which courses they could enrol in to meet that competency.

[[Image:cbe_spec24.jpg|frame|center|Student Learning Plan Competencies page shows progress, and course discovery]]<div style="clear: both"></div>

Students can see a list of their active learning plans on their dashboard, with a visual indication of progress (a progress bar). Each learning plan is a link to the learning plan report shown above.

Teachers

For teachers and course designers building a set of courses against a competency framework, they should be able to identify competencies that are over/underrepresented by a set of courses. To do this they access a learning plan template, and view the coverage report for that template. This competency coverage report initially shows the coverage from all courses that link to one of the competencies in the template, but the teacher can remove some courses from the selection and regenerate the report.

[[Image:cbe_spec09.jpg|frame|center|Coverage report]]<div style="clear: both"></div>

Teachers and course designers can also see some statistics about a learning plan template. From the learning plan template page, they choose “Statistics” from the action menu to see the number of active/completed learning plans using this template, and the average completion % for the learning plans.

[[Image:cbe_spec13.jpg|frame|center|Statistics for Learning Plan Template]]<div style="clear: both"></div>

Teachers can also see a report in a course that shows for each course competency, which users have completed or not completed it.

[[Image:cbe_spec05.jpg|frame|center|Breakdown report]]<div style="clear: both"></div>

== User roles and capabilities ==

In this system, the actions a user can perform are governed by various capabilities, and are checked at one of several different context levels.

As a reference, the relevant context levels in Moodle are organised in a tree like structure and an example is shown below:

* Site
** User A
** User B
** Category A
*** Course A
*** Course B
** Category B
*** Category C
**** Course C
**** Course D

=== Framework Administrators ===

Competency framework administrators are the central people responsible for creating and maintaining the system wide competency frameworks.

The actions a competency framework administrator can take are:

'''Create/Edit/Delete a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Create/Edit/Delete a competency within a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Mark a competency as related to another competency'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

=== Learning Plan Administrators ===

Learning plan administrators are responsible for creating and maintaining learning plan templates relating to e.g. a specific faculty, set of courses, degree or certification.

The actions a learning plan administrator can take are:

'''Create/Edit/Delete a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Add and remove competencies from a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Assign a user a learning plan from a learning plan template'''

Requires “tool/lp:planmanage“ capability defined on the “User” context level.

'''View coverage report for a learning plan template'''

Requires “report/lpcoverage:view“ capability defined on the “Site” or "Course Category" context level.

'''View statistics report for a learning plan template'''

Requires “report/lpstatistics:view“ capability defined on the “Site” or "Course Category" context level.

'''View breakdown report for a learning plan template'''

Requires “report/lpbreakdown:view“ capability defined on the “Course” context level.

'''Approve draft learning plans'''

Requires “tool/lp:planapprove“ capability defined on the “User” context level.

'''Approve competency review requests'''

Requires “tool/lp:competencygrade“ capability defined on the “User” context level.

=== Teachers ===

Teachers create and teach courses, that provide evidence of competencies.

The actions a teacher can take are:

'''Assign competencies to a course'''

Requires “tool/lp:coursecompetencymanage” capability defined at the “Course” context level.

'''Manually grade competencies linked to a course'''

Requires “tool/lp:coursecompetencygrade” capability defined at the “Course” context level.

=== Students ===

Students are users that can have learning plans.

The actions a student can take are:

'''View their own learning plans'''

Requires “tool/lp:planviewown” capability defined at the “User” context level.

'''Create their own draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Request approval for their draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Provide evidence of prior learning for a competency'''

Requires “tool/lp:planaddevidence” capability defined at the “User” context level.

'''Request for someone to grade them for a specific competency'''

Requires “tool/lp:plancompetencyrequestreview” capability defined at the “User” context level.

== Further work (out of scope for first release) ==

Add a rule to award badges when certain competencies are met

This is a simple addition to the existing rules that can be configured to award a badge.

[[Image:cbe_spec20.jpg|frame|center|Custom badge condition]]<div style="clear: both"></div>

=== Linking activities as evidence of competencies ===

[[Image:cbe_spec01.jpg|frame|center|Linking an activity to some course competencies]]<div style="clear: both"></div>

Teachers can also quickly find resources and activities that have not been mapped to any competencies. This is done on the competency mapping report which shows all resources and activities for the course, as well as the linked competencies for each. This report will also list any course competencies that are not linked to any activities or resources.

=== Alternative ways to “automatically complete” competencies ===

* Trigger based on activity completion. Configured when linking competencies to a course.

=== Additional reports ===

E.g. https://moodle.org/mod/forum/discuss.php?d=316151#p1266980

== Interaction with the existing Moodle “Outcomes” ==

Description of existing “Outcomes”

Outcomes define a set of system wide scales that can be used to grade activities. The value chosen from the scale is pushed to the gradebook for each activity and a custom report will show the average of outcomes across a course, or the entire site. Not all activities and resources support outcomes, only scorm, quiz, lti, lesson, glossary, data, chat, assign and forum.

Any activity that has an outcome attached receives a new column in the gradebook where that outcome is assessed for that activity.

Outcomes has some features that would need to be “removed” in order to make sense with competency frameworks (mainly pushing of grades to the gradebook) - this means we cannot build on outcomes, and maintain backwards compatibility. It is therefore recommended to provide:

* A site wide setting to allow competencies - allow either/or but the default will be competencies with no outcomes.
* A simple way to create a competency framework from an existing set of outcomes.
* (optional - requires activity level competencies) A way to import existing outcomes grades as evidence for competencies.

== Open questions for further feedback ==

* Would you expect a teacher to be able to create their own competencies (limited to their own course)? Would competencies that are visible only to a single course (and potentially conflicting with competencies from another course) be really useful?
* Do we need to allow competencies to be linked to individual questions?
* Do we need to allow competencies to be linked to individual items on a rubric/marking guide?
* How should self-evaluation of competencies work?

== Outstanding work for this spec ==

* The examples should use consistent names for user types, competencies and courses. It would be easier to use a real example of competencies from a real framework
* The terminology for child/parent relationships should consistently be:
** Parent
** Sub-competency
* Technical spec (this doc is the requirements).

Competency Based Education

2015-10-01T13:08:38Z

FMCorz: Related competencies and parent limit

{{Infobox Project
|name = Framework for competency-based education (CBE) in Moodle
|state = In Progress
|tracker = MDL-49458
|discussion = https://moodle.org/mod/forum/discuss.php?d=316151
|assignee = [[User:Damyon Wiese]]
}}

{{Work in progress}}

=Framework for competency-based education (CBE) in Moodle=

==Summary==

This specification describes our plan to improve support for outcomes-based education in Moodle core. There have been many other attempts to add such systems to Moodle but they all use different data structures and processes and are incompatible. Our aim here is to build basic central structures and APIs to store and manipulate this data, allowing the Moodle community to build innovative custom interfaces on top of it.

This design is based on input from many existing implementations of outcomes/competencies and learning plans including:

* “Outcomes 2” in Joule
* Totara
* Referentiel Activity Module (Skills Repository)
* ELIS

The goal is to implement a system that supports competency based education in a flexible way so that it can be used effectively by the many different target audiences.

The two main concepts are:

'''Competencies''' - a unit of learning, such as "Can make exceptional beer". Competencies can be assigned as goals of courses “This course will teach you to make exceptional beer”, and also to users: “Billy can make exceptional beer”.
Competencies can also be hierarchical, so that the competency above might be marked proficient when some combination of sub-competencies has been marked proficient.
For example : Can make exceptional beer ( Can choose good malt / Can choose good yeasts / Can brew beer in the good temperature / etc..)

'''Learning plans''' - a set of competencies that can be assigned to a student (or cohorts of students). Initially, they will all be marked "incomplete". As students achieve each competency it is marked complete, thereby showing their progress towards finishing all of them. Students achieve competencies either automatically (by successfully completing a course with that competency) or manually (by proving to someone that they are competent via portfolio items etc).

== Competencies ==

A competency is a unit of learning. All competencies belong to a competency framework, and it is likely that a competency framework will be defined by an external body such as an academic standards board.

To create a competency, you first define the framework and then add the competency to it.

Competency frameworks are defined by “Framework Administrators” at the site level, or at a category level. To create and edit competency frameworks, go to “Site administration” -> “Competency Frameworks”, or "Category administration -> Competency frameworks".

[[Image:cbe_spec21_v2.jpg|frame|center|Manage competency frameworks]]<div style="clear: both"></div>

[[Image:cbe_spec19_v3.jpg|frame|center|Add new competency framework]]<div style="clear: both"></div>

Choose “Add new competency framework” and create a new competency framework.

The scale defines how a competency is marked as complete. Each competency framework can define which of the standard Moodle scales should be used when marking a competency. In addition, the “default” value from the scale (the one automatically set when a course is completed) can be configured, and the items from the scale that are deemed to be “proficient” can be defined. A "default" value and at least one "proficient" value must be defined.

A competency framework may be available to the entire site - or limited to a course category.

The taxonomy refers to the naming for each level in the framework. Up to 4 levels are supported, and the name for each level can be set from the following list:
Domain, Competency, Behaviour, Indicator, Outcome, Level, Concept, Value, Practice, Skill, Proficiency

[[Image:cbe_spec02.jpg|frame|center|Configure scale]]<div style="clear: both"></div>

Now we need to add competencies to the framework. We can import these from a file, or create them from scratch, or import them from Moodle outcomes. When importing competencies, any existing competencies with a matching idnumber will be updated.

[[Image:cbe_spec15.jpg|frame|center|Import competencies]]<div style="clear: both"></div>

Competencies can be imported from the following formats:

(TBD - start with import from CSV).

To see the competencies for a framework, click on the competency framework name.

[[Image:cbe_spec06_v2.jpg|frame|center|Manage competencies]]<div style="clear: both"></div>

This is where we can add and edit competencies in a framework. To edit an existing competency, select it in the competencies tree browser and choose “Edit” from the action menu in the selected competency panel.

To add a new competency, first select the competency that should be the “parent” of this competency from the tree of competencies, and then click “Add Indicator” (the name comes from the taxonomy) from the selected competency panel. Competencies can have a maximum of 3 descendants (4 levels). Tags can be used to categorise competencies for easy searching, e.g. year level, subject. Tags used for competencies are kept in a separate “tagcloud” (see https://tracker.moodle.org/browse/MDL-50851).

A competency framework can be duplicated, and there is an admin tool for migrating courses from one framework to another (as long as the idnumbers between the competencies in the frameworks can be matched).

If a competency has sub-competencies, you can configure the completion rule for the competency. The default completion rule is “Completed when all sub-competencies are complete”. For more complex rules - you can use a points based system to say when to complete or recommend a competency.

[[Image:cbe_spec23.jpg|frame|center|Add a competency]]<div style="clear: both"></div>

Competencies can be “related” to other competencies within the same framework. The only effect of this is that the related competencies are listed in the summary of each competency, whenever it is displayed in Moodle. To add a “related” competency to an existing competency, select it from the competency framework and choose “Add related competency” from the action menu.

[[Image:cbe_spec03_v2.jpg|frame|center|Relating competencies to each other]]<div style="clear: both"></div>

== Learning plan templates ==

It would be cumbersome to individually add competencies to a large group of students, and it would be awkward if you made a mistake and had to change the competencies for all the students at a later date. To make this manageable, you can create a “Learning plan template” and assign it to many students. An example of a learning plan template could be: “Computer science, Undergraduate” which lists all the required competencies for a first year computer science student, or it could be more fine grained.

Templates are created by a ”Learning Plan Administrator”. Templates can be imported and exported via CSV. Learning plan templates can be created at a course category, or a site level.

[[Image:cbe_spec22_v2.jpg|frame|center|Manage Learning Plan Templates]]<div style="clear: both"></div>

Once you have created a template, you can add competencies to it.

[[Image:cbe_spec18.jpg|frame|center|List competencies in a template]]<div style="clear: both"></div>

[[Image:cbe_spec00.jpg|frame|center|Add competency to a template]]<div style="clear: both"></div>

Adding competencies to a template will update all the learning plans based on that template.

== User learning plans ==

A user learning plan is a collection of all the competencies they should achieve, optionally before a certain date.

Any user can create their own learning plan, if they have the capability on their own context.

A “Learning Plan Administrator” can create learning plans for other users. They can create the plans individually though another users profile page, or they can create learning plans in bulk from a learning plan template.

Users learning plans can be in one of 3 states, Draft, Active or Completed. Only someone with the capability tool/lp:planmanage (or tool/lp:planmanageown if it’s their own plan) capability can approve learning plans.

A plan can be manually set to completed, by someone with the capabilities listed above, or it will be set to completed when the due date for the plan expires.

[[Image:cbe_spec07.jpg|frame|center|Single users learning plans page]]<div style="clear: both"></div>

[[Image:cbe_spec16.jpg|frame|center|Bulk create user learning plans]]<div style="clear: both"></div>

Note that sites using enrolment plugins can create a cohort based on the enrolments of a set of courses using the admin tool “Course cohorts”. More detail required here.

Competencies can be added to a users learning plan, or to the template the plan was created from and they will automatically appear in the users learning plan. Competencies that exist in the template cannot be removed from the users learning plan. If a single student requires e.g. exemptions from certain competencies - their learning plan can be "unlinked" from the template. This plan will no longer show up in reports generated from the learning plan template - but can now be freely edited.

[[Image:cbe_spec12.jpg|frame|center|User learning plan competencies]]<div style="clear: both"></div>

Note, there can be multiple types of evidence for the same competency. E.g. 2 courses may provide evidence for the same competency and both courses were completed. In this case - both would show as evidence. There can also be multiple examples of "Evidence of prior learning" attached to each competency.<br /><br />Each competency in the table is colour coded to indicate one of the following:

* brown - competency not met, and no evidence or enrolled courses cover this competency
* orange - the competency is not met, but there is evidence, or “in-progress” courses that cover this competency
* green - the competency has been met

If you have the capability tool/lp:planaddevidence you can upload files and urls against a competency in your plan as evidence of prior learning. You can also request that a someone with the capability tool/lp:planmanage reviews the evidence and either rejects or accepts the evidence and changes the status for the competency in the plan.

[[Image:cbe_spec25.jpg|frame|center|Provide evidence]]<div style="clear: both"></div>

[[Image:cbe_spec08.jpg|frame|center|Link evidence]]<div style="clear: both"></div>

To view all the current requests for review, a new “Learning plans” block can be added to an “approvers” dashboard.

[[Image:cbe_spec10.jpg|frame|center|Dashboard Block]]<div style="clear: both"></div>

A User with the capability “tool/lp:planmanage” (at the context of another users plan) can review and approve competency approval requests. A competency approval request is a request for someone to review the evidence that a user has provided against a specific competency and make a decision whether the user has either met or not met the competency. The valid statuses for a review are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

There can only be one “review” per competency for each user (if a review is rejected, and then a new request is made, the previous review will be changed from “Rejected” to “Waiting for review”).

Following the link in the Learning Plans dashboard block, the approver goes to a page that lists all the requests waiting to be approved, and from here they can approve or reject each request. They can also leave comments that will be visible to the student, or to any other reviewers.

To allow multiple authorisers to work together, when looking at a review an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a review, or a review is accepted or rejected, the student will receive a message about the change.

When a completion rule triggers a “recommendation” - the evidence will be added to the competency, and the system will request a “review” of this competency.

TODO Define a new page for assigning roles relative to a user. In totara, there is a “positions” page which does this. This will also be useful for “Mentees”.

[[Image:cbe_spec11.jpg|frame|center|Review competency requests]]<div style="clear: both"></div>

If users have the capability to create their own draft learning plans, but not approve them themselves, someone will need to review all the draft learning plan requests and decide whether or not to make them active. This user can be anyone with “tool/lp:planmanage” capability (at the context of each user with a plan to approve) and they can view all the “Learning plans to approve” link in the Learning Plans dashboard block.

A learning plan approval request made by a user with a draft learning plan from their “Manage learning plans page”. Once a request has been made, the valid statuses for a learning plan approval request are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

To allow multiple authorisers to work together, when looking at a learning plans approval request an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a learning plan approval request, or a learning plan approval request is accepted or rejected, the student will receive a message about the change.

[[Image:cbe_spec04.jpg|frame|center|Review Learning Plan Approval Requests]]<div style="clear: both"></div>

== Course Competencies ==

Competencies can also be linked to a course. This means that when a student completes a course (see course completion) - all of the linked competencies will be marked as “complete” or “recommended” in any of the students active learning plans and the course will be added as evidence against that competency. If the competency is already “met”, the course will still be added as evidence for that competency. If the competency is only set to “recommend” the course will be added as evidence and a review request will be created.

The competency will be given the default value from the competency scale. You can select multiple competencies and add them all at once.

[[Image:cbe_spec17.jpg|frame|center|Course Competencies]]<div style="clear: both"></div>

A teacher in a course, can manually mark the students against the course competencies. For each competency, the teacher will see all of the evidence linked to that competency for the student. They then can assign a value from the competency scale for the student, and optionally make a comment. A record of the teacher marking this competency will be added to the evidence of completion for this competency and the status of the competency will be updated in all active learning plans for the student.

TODO - see how the information from the coverage report can be shown when linking course competencies.

[[Image:cbe_spec14.jpg|frame|center|Grading competencies within a course]]<div style="clear: both"></div>

When manually marking a competency, it is recorded as evidence ie: "Teacher X manually specified this value in this course" - so if the same competency is linked to multiple course it can be marked in each, and this will show up as 2 pieces of evidence.

Reports

Students

For an active Learning Plan, students can see a report of the competencies that are covered/not covered by their current list of enrolled courses. For each competency, they should also be able to see which courses they could enrol in to meet that competency.

[[Image:cbe_spec24.jpg|frame|center|Student Learning Plan Competencies page shows progress, and course discovery]]<div style="clear: both"></div>

Students can see a list of their active learning plans on their dashboard, with a visual indication of progress (a progress bar). Each learning plan is a link to the learning plan report shown above.

Teachers

For teachers and course designers building a set of courses against a competency framework, they should be able to identify competencies that are over/underrepresented by a set of courses. To do this they access a learning plan template, and view the coverage report for that template. This competency coverage report initially shows the coverage from all courses that link to one of the competencies in the template, but the teacher can remove some courses from the selection and regenerate the report.

[[Image:cbe_spec09.jpg|frame|center|Coverage report]]<div style="clear: both"></div>

Teachers and course designers can also see some statistics about a learning plan template. From the learning plan template page, they choose “Statistics” from the action menu to see the number of active/completed learning plans using this template, and the average completion % for the learning plans.

[[Image:cbe_spec13.jpg|frame|center|Statistics for Learning Plan Template]]<div style="clear: both"></div>

Teachers can also see a report in a course that shows for each course competency, which users have completed or not completed it.

[[Image:cbe_spec05.jpg|frame|center|Breakdown report]]<div style="clear: both"></div>

== User roles and capabilities ==

In this system, the actions a user can perform are governed by various capabilities, and are checked at one of several different context levels.

As a reference, the relevant context levels in Moodle are organised in a tree like structure and an example is shown below:

* Site
** User A
** User B
** Category A
*** Course A
*** Course B
** Category B
*** Category C
**** Course C
**** Course D

=== Framework Administrators ===

Competency framework administrators are the central people responsible for creating and maintaining the system wide competency frameworks.

The actions a competency framework administrator can take are:

'''Create/Edit/Delete a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Create/Edit/Delete a competency within a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Mark a competency as related to another competency'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

=== Learning Plan Administrators ===

Learning plan administrators are responsible for creating and maintaining learning plan templates relating to e.g. a specific faculty, set of courses, degree or certification.

The actions a learning plan administrator can take are:

'''Create/Edit/Delete a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Add and remove competencies from a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Assign a user a learning plan from a learning plan template'''

Requires “tool/lp:planmanage“ capability defined on the “User” context level.

'''View coverage report for a learning plan template'''

Requires “report/lpcoverage:view“ capability defined on the “Site” or "Course Category" context level.

'''View statistics report for a learning plan template'''

Requires “report/lpstatistics:view“ capability defined on the “Site” or "Course Category" context level.

'''View breakdown report for a learning plan template'''

Requires “report/lpbreakdown:view“ capability defined on the “Course” context level.

'''Approve draft learning plans'''

Requires “tool/lp:planapprove“ capability defined on the “User” context level.

'''Approve competency review requests'''

Requires “tool/lp:competencygrade“ capability defined on the “User” context level.

=== Teachers ===

Teachers create and teach courses, that provide evidence of competencies.

The actions a teacher can take are:

'''Assign competencies to a course'''

Requires “tool/lp:coursecompetencymanage” capability defined at the “Course” context level.

'''Manually grade competencies linked to a course'''

Requires “tool/lp:coursecompetencygrade” capability defined at the “Course” context level.

=== Students ===

Students are users that can have learning plans.

The actions a student can take are:

'''View their own learning plans'''

Requires “tool/lp:planviewown” capability defined at the “User” context level.

'''Create their own draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Request approval for their draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Provide evidence of prior learning for a competency'''

Requires “tool/lp:planaddevidence” capability defined at the “User” context level.

'''Request for someone to grade them for a specific competency'''

Requires “tool/lp:plancompetencyrequestreview” capability defined at the “User” context level.

== Further work (out of scope for first release) ==

Add a rule to award badges when certain competencies are met

This is a simple addition to the existing rules that can be configured to award a badge.

[[Image:cbe_spec20.jpg|frame|center|Custom badge condition]]<div style="clear: both"></div>

=== Linking activities as evidence of competencies ===

[[Image:cbe_spec01.jpg|frame|center|Linking an activity to some course competencies]]<div style="clear: both"></div>

Teachers can also quickly find resources and activities that have not been mapped to any competencies. This is done on the competency mapping report which shows all resources and activities for the course, as well as the linked competencies for each. This report will also list any course competencies that are not linked to any activities or resources.

=== Alternative ways to “automatically complete” competencies ===

* Trigger based on activity completion. Configured when linking competencies to a course.

=== Additional reports ===

E.g. https://moodle.org/mod/forum/discuss.php?d=316151#p1266980

== Interaction with the existing Moodle “Outcomes” ==

Description of existing “Outcomes”

Outcomes define a set of system wide scales that can be used to grade activities. The value chosen from the scale is pushed to the gradebook for each activity and a custom report will show the average of outcomes across a course, or the entire site. Not all activities and resources support outcomes, only scorm, quiz, lti, lesson, glossary, data, chat, assign and forum.

Any activity that has an outcome attached receives a new column in the gradebook where that outcome is assessed for that activity.

Outcomes has some features that would need to be “removed” in order to make sense with competency frameworks (mainly pushing of grades to the gradebook) - this means we cannot build on outcomes, and maintain backwards compatibility. It is therefore recommended to provide:

* A site wide setting to allow competencies - allow either/or but the default will be competencies with no outcomes.
* A simple way to create a competency framework from an existing set of outcomes.
* (optional - requires activity level competencies) A way to import existing outcomes grades as evidence for competencies.

== Open questions for further feedback ==

* Would you expect a teacher to be able to create their own competencies (limited to their own course)? Would competencies that are visible only to a single course (and potentially conflicting with competencies from another course) be really useful?
* Do we need to allow competencies to be linked to individual questions?
* Do we need to allow competencies to be linked to individual items on a rubric/marking guide?
* How should self-evaluation of competencies work?

== Outstanding work for this spec ==

* The examples should use consistent names for user types, competencies and courses. It would be easier to use a real example of competencies from a real framework
* The terminology for child/parent relationships should consistently be:
** Parent
** Sub-competency
* Technical spec (this doc is the requirements).

Competency Based Education

2015-09-17T06:05:04Z

FMCorz: Clarifying how a scale must be configured

{{Infobox Project
|name = Framework for competency-based education (CBE) in Moodle
|state = In Progress
|tracker = MDL-49458
|discussion = https://moodle.org/mod/forum/discuss.php?d=316151
|assignee = [[User:Damyon Wiese]]
}}

{{Work in progress}}

=Framework for competency-based education (CBE) in Moodle=

==Summary==

This specification describes our plan to improve support for outcomes-based education in Moodle core. There have been many other attempts to add such systems to Moodle but they all use different data structures and processes and are incompatible. Our aim here is to build basic central structures and APIs to store and manipulate this data, allowing the Moodle community to build innovative custom interfaces on top of it.

This design is based on input from many existing implementations of outcomes/competencies and learning plans including:

* “Outcomes 2” in Joule
* Totara
* Referentiel Activity Module (Skills Repository)
* ELIS

The goal is to implement a system that supports competency based education in a flexible way so that it can be used effectively by the many different target audiences.

The two main concepts are:

'''Competencies''' - a unit of learning, such as "Can make exceptional beer". Competencies can be assigned as goals of courses “This course will teach you to make exceptional beer”, and also to users: “Billy can make exceptional beer”.
Competencies can also be hierarchical, so that the competency above might be marked proficient when some combination of sub-competencies has been marked proficient.
For example : Can make exceptional beer ( Can choose good malt / Can choose good yeasts / Can brew beer in the good temperature / etc..)

'''Learning plans''' - a set of competencies that can be assigned to a student (or cohorts of students). Initially, they will all be marked "incomplete". As students achieve each competency it is marked complete, thereby showing their progress towards finishing all of them. Students achieve competencies either automatically (by successfully completing a course with that competency) or manually (by proving to someone that they are competent via portfolio items etc).

== Competencies ==

A competency is a unit of learning. All competencies belong to a competency framework, and it is likely that a competency framework will be defined by an external body such as an academic standards board.

To create a competency, you first define the framework and then add the competency to it.

Competency frameworks are defined by “Framework Administrators” at the site level, or at a category level. To create and edit competency frameworks, go to “Site administration” -> “Competency Frameworks”, or "Category administration -> Competency frameworks".

[[Image:cbe_spec21_v2.jpg|frame|center|Manage competency frameworks]]<div style="clear: both"></div>

[[Image:cbe_spec19_v3.jpg|frame|center|Add new competency framework]]<div style="clear: both"></div>

Choose “Add new competency framework” and create a new competency framework.

The scale defines how a competency is marked as complete. Each competency framework can define which of the standard Moodle scales should be used when marking a competency. In addition, the “default” value from the scale (the one automatically set when a course is completed) can be configured, and the items from the scale that are deemed to be “proficient” can be defined. A "default" value and at least one "proficient" value must be defined.

A competency framework may be available to the entire site - or limited to a course category.

The taxonomy refers to the naming for each level in the framework. Up to 4 levels are supported, and the name for each level can be set from the following list:
Domain, Competency, Behaviour, Indicator, Outcome, Level, Concept, Value, Practice, Skill, Proficiency

[[Image:cbe_spec02.jpg|frame|center|Configure scale]]<div style="clear: both"></div>

Now we need to add competencies to the framework. We can import these from a file, or create them from scratch, or import them from Moodle outcomes. When importing competencies, any existing competencies with a matching idnumber will be updated.

[[Image:cbe_spec15.jpg|frame|center|Import competencies]]<div style="clear: both"></div>

Competencies can be imported from the following formats:

(TBD - start with import from CSV).

To see the competencies for a framework, click on the competency framework name.

[[Image:cbe_spec06_v2.jpg|frame|center|Manage competencies]]<div style="clear: both"></div>

This is where we can add and edit competencies in a framework. To edit an existing competency, select it in the competencies tree browser and choose “Edit” from the action menu in the selected competency panel.

To add a new competency, first select the competency that should be the “parent” of this competency from the tree of competencies, and then click “Add Indicator” (the name comes from the taxonomy) from the selected competency panel. Tags can be used to categorise competencies for easy searching, e.g. year level, subject. Tags used for competencies are kept in a separate “tagcloud” (see https://tracker.moodle.org/browse/MDL-50851).

A competency framework can be duplicated, and there is an admin tool for migrating courses from one framework to another (as long as the idnumbers between the competencies in the frameworks can be matched).

If a competency has sub-competencies, you can configure the completion rule for the competency. The default completion rule is “Completed when all sub-competencies are complete”. For more complex rules - you can use a points based system to say when to complete or recommend a competency.

[[Image:cbe_spec23.jpg|frame|center|Add a competency]]<div style="clear: both"></div>

Competencies can be “related” to other competencies. The only effect of this is that the related competencies are listed in the summary of each competency, whenever it is displayed in Moodle. To add a “related” competency to an existing competency, select it from the competency framework and choose “Add related competency” from the action menu.

[[Image:cbe_spec03_v2.jpg|frame|center|Relating competencies to each other]]<div style="clear: both"></div>

== Learning plan templates ==

It would be cumbersome to individually add competencies to a large group of students, and it would be awkward if you made a mistake and had to change the competencies for all the students at a later date. To make this manageable, you can create a “Learning plan template” and assign it to many students. An example of a learning plan template could be: “Computer science, Undergraduate” which lists all the required competencies for a first year computer science student, or it could be more fine grained.

Templates are created by a ”Learning Plan Administrator”. Templates can be imported and exported via CSV. Learning plan templates can be created at a course category, or a site level.

[[Image:cbe_spec22_v2.jpg|frame|center|Manage Learning Plan Templates]]<div style="clear: both"></div>

Once you have created a template, you can add competencies to it.

[[Image:cbe_spec18.jpg|frame|center|List competencies in a template]]<div style="clear: both"></div>

[[Image:cbe_spec00.jpg|frame|center|Add competency to a template]]<div style="clear: both"></div>

Adding competencies to a template will update all the learning plans based on that template.

== User learning plans ==

A user learning plan is a collection of all the competencies they should achieve, optionally before a certain date.

Any user can create their own learning plan, if they have the capability on their own context.

A “Learning Plan Administrator” can create learning plans for other users. They can create the plans individually though another users profile page, or they can create learning plans in bulk from a learning plan template.

Users learning plans can be in one of 3 states, Draft, Active or Completed. Only someone with the capability tool/lp:planmanage (or tool/lp:planmanageown if it’s their own plan) capability can approve learning plans.

A plan can be manually set to completed, by someone with the capabilities listed above, or it will be set to completed when the due date for the plan expires.

[[Image:cbe_spec07.jpg|frame|center|Single users learning plans page]]<div style="clear: both"></div>

[[Image:cbe_spec16.jpg|frame|center|Bulk create user learning plans]]<div style="clear: both"></div>

Note that sites using enrolment plugins can create a cohort based on the enrolments of a set of courses using the admin tool “Course cohorts”. More detail required here.

Competencies can be added to a users learning plan, or to the template the plan was created from and they will automatically appear in the users learning plan. Competencies that exist in the template cannot be removed from the users learning plan. If a single student requires e.g. exemptions from certain competencies - their learning plan can be "unlinked" from the template. This plan will no longer show up in reports generated from the learning plan template - but can now be freely edited.

[[Image:cbe_spec12.jpg|frame|center|User learning plan competencies]]<div style="clear: both"></div>

Note, there can be multiple types of evidence for the same competency. E.g. 2 courses may provide evidence for the same competency and both courses were completed. In this case - both would show as evidence. There can also be multiple examples of "Evidence of prior learning" attached to each competency.<br /><br />Each competency in the table is colour coded to indicate one of the following:

* brown - competency not met, and no evidence or enrolled courses cover this competency
* orange - the competency is not met, but there is evidence, or “in-progress” courses that cover this competency
* green - the competency has been met

If you have the capability tool/lp:planaddevidence you can upload files and urls against a competency in your plan as evidence of prior learning. You can also request that a someone with the capability tool/lp:planmanage reviews the evidence and either rejects or accepts the evidence and changes the status for the competency in the plan.

[[Image:cbe_spec25.jpg|frame|center|Provide evidence]]<div style="clear: both"></div>

[[Image:cbe_spec08.jpg|frame|center|Link evidence]]<div style="clear: both"></div>

To view all the current requests for review, a new “Learning plans” block can be added to an “approvers” dashboard.

[[Image:cbe_spec10.jpg|frame|center|Dashboard Block]]<div style="clear: both"></div>

A User with the capability “tool/lp:planmanage” (at the context of another users plan) can review and approve competency approval requests. A competency approval request is a request for someone to review the evidence that a user has provided against a specific competency and make a decision whether the user has either met or not met the competency. The valid statuses for a review are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

There can only be one “review” per competency for each user (if a review is rejected, and then a new request is made, the previous review will be changed from “Rejected” to “Waiting for review”).

Following the link in the Learning Plans dashboard block, the approver goes to a page that lists all the requests waiting to be approved, and from here they can approve or reject each request. They can also leave comments that will be visible to the student, or to any other reviewers.

To allow multiple authorisers to work together, when looking at a review an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a review, or a review is accepted or rejected, the student will receive a message about the change.

When a completion rule triggers a “recommendation” - the evidence will be added to the competency, and the system will request a “review” of this competency.

TODO Define a new page for assigning roles relative to a user. In totara, there is a “positions” page which does this. This will also be useful for “Mentees”.

[[Image:cbe_spec11.jpg|frame|center|Review competency requests]]<div style="clear: both"></div>

If users have the capability to create their own draft learning plans, but not approve them themselves, someone will need to review all the draft learning plan requests and decide whether or not to make them active. This user can be anyone with “tool/lp:planmanage” capability (at the context of each user with a plan to approve) and they can view all the “Learning plans to approve” link in the Learning Plans dashboard block.

A learning plan approval request made by a user with a draft learning plan from their “Manage learning plans page”. Once a request has been made, the valid statuses for a learning plan approval request are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

To allow multiple authorisers to work together, when looking at a learning plans approval request an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a learning plan approval request, or a learning plan approval request is accepted or rejected, the student will receive a message about the change.

[[Image:cbe_spec04.jpg|frame|center|Review Learning Plan Approval Requests]]<div style="clear: both"></div>

== Course Competencies ==

Competencies can also be linked to a course. This means that when a student completes a course (see course completion) - all of the linked competencies will be marked as “complete” or “recommended” in any of the students active learning plans and the course will be added as evidence against that competency. If the competency is already “met”, the course will still be added as evidence for that competency. If the competency is only set to “recommend” the course will be added as evidence and a review request will be created.

The competency will be given the default value from the competency scale. You can select multiple competencies and add them all at once.

[[Image:cbe_spec17.jpg|frame|center|Course Competencies]]<div style="clear: both"></div>

A teacher in a course, can manually mark the students against the course competencies. For each competency, the teacher will see all of the evidence linked to that competency for the student. They then can assign a value from the competency scale for the student, and optionally make a comment. A record of the teacher marking this competency will be added to the evidence of completion for this competency and the status of the competency will be updated in all active learning plans for the student.

TODO - see how the information from the coverage report can be shown when linking course competencies.

[[Image:cbe_spec14.jpg|frame|center|Grading competencies within a course]]<div style="clear: both"></div>

When manually marking a competency, it is recorded as evidence ie: "Teacher X manually specified this value in this course" - so if the same competency is linked to multiple course it can be marked in each, and this will show up as 2 pieces of evidence.

Reports

Students

For an active Learning Plan, students can see a report of the competencies that are covered/not covered by their current list of enrolled courses. For each competency, they should also be able to see which courses they could enrol in to meet that competency.

[[Image:cbe_spec24.jpg|frame|center|Student Learning Plan Competencies page shows progress, and course discovery]]<div style="clear: both"></div>

Students can see a list of their active learning plans on their dashboard, with a visual indication of progress (a progress bar). Each learning plan is a link to the learning plan report shown above.

Teachers

For teachers and course designers building a set of courses against a competency framework, they should be able to identify competencies that are over/underrepresented by a set of courses. To do this they access a learning plan template, and view the coverage report for that template. This competency coverage report initially shows the coverage from all courses that link to one of the competencies in the template, but the teacher can remove some courses from the selection and regenerate the report.

[[Image:cbe_spec09.jpg|frame|center|Coverage report]]<div style="clear: both"></div>

Teachers and course designers can also see some statistics about a learning plan template. From the learning plan template page, they choose “Statistics” from the action menu to see the number of active/completed learning plans using this template, and the average completion % for the learning plans.

[[Image:cbe_spec13.jpg|frame|center|Statistics for Learning Plan Template]]<div style="clear: both"></div>

Teachers can also see a report in a course that shows for each course competency, which users have completed or not completed it.

[[Image:cbe_spec05.jpg|frame|center|Breakdown report]]<div style="clear: both"></div>

== User roles and capabilities ==

In this system, the actions a user can perform are governed by various capabilities, and are checked at one of several different context levels.

As a reference, the relevant context levels in Moodle are organised in a tree like structure and an example is shown below:

* Site
** User A
** User B
** Category A
*** Course A
*** Course B
** Category B
*** Category C
**** Course C
**** Course D

=== Framework Administrators ===

Competency framework administrators are the central people responsible for creating and maintaining the system wide competency frameworks.

The actions a competency framework administrator can take are:

'''Create/Edit/Delete a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Create/Edit/Delete a competency within a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Mark a competency as related to another competency'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

=== Learning Plan Administrators ===

Learning plan administrators are responsible for creating and maintaining learning plan templates relating to e.g. a specific faculty, set of courses, degree or certification.

The actions a learning plan administrator can take are:

'''Create/Edit/Delete a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Add and remove competencies from a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Assign a user a learning plan from a learning plan template'''

Requires “tool/lp:planmanage“ capability defined on the “User” context level.

'''View coverage report for a learning plan template'''

Requires “report/lpcoverage:view“ capability defined on the “Site” or "Course Category" context level.

'''View statistics report for a learning plan template'''

Requires “report/lpstatistics:view“ capability defined on the “Site” or "Course Category" context level.

'''View breakdown report for a learning plan template'''

Requires “report/lpbreakdown:view“ capability defined on the “Course” context level.

'''Approve draft learning plans'''

Requires “tool/lp:planapprove“ capability defined on the “User” context level.

'''Approve competency review requests'''

Requires “tool/lp:competencygrade“ capability defined on the “User” context level.

=== Teachers ===

Teachers create and teach courses, that provide evidence of competencies.

The actions a teacher can take are:

'''Assign competencies to a course'''

Requires “tool/lp:coursecompetencymanage” capability defined at the “Course” context level.

'''Manually grade competencies linked to a course'''

Requires “tool/lp:coursecompetencygrade” capability defined at the “Course” context level.

=== Students ===

Students are users that can have learning plans.

The actions a student can take are:

'''View their own learning plans'''

Requires “tool/lp:planviewown” capability defined at the “User” context level.

'''Create their own draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Request approval for their draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Provide evidence of prior learning for a competency'''

Requires “tool/lp:planaddevidence” capability defined at the “User” context level.

'''Request for someone to grade them for a specific competency'''

Requires “tool/lp:plancompetencyrequestreview” capability defined at the “User” context level.

== Further work (out of scope for first release) ==

Add a rule to award badges when certain competencies are met

This is a simple addition to the existing rules that can be configured to award a badge.

[[Image:cbe_spec20.jpg|frame|center|Custom badge condition]]<div style="clear: both"></div>

=== Linking activities as evidence of competencies ===

[[Image:cbe_spec01.jpg|frame|center|Linking an activity to some course competencies]]<div style="clear: both"></div>

Teachers can also quickly find resources and activities that have not been mapped to any competencies. This is done on the competency mapping report which shows all resources and activities for the course, as well as the linked competencies for each. This report will also list any course competencies that are not linked to any activities or resources.

=== Alternative ways to “automatically complete” competencies ===

* Trigger based on activity completion. Configured when linking competencies to a course.

=== Additional reports ===

E.g. https://moodle.org/mod/forum/discuss.php?d=316151#p1266980

== Interaction with the existing Moodle “Outcomes” ==

Description of existing “Outcomes”

Outcomes define a set of system wide scales that can be used to grade activities. The value chosen from the scale is pushed to the gradebook for each activity and a custom report will show the average of outcomes across a course, or the entire site. Not all activities and resources support outcomes, only scorm, quiz, lti, lesson, glossary, data, chat, assign and forum.

Any activity that has an outcome attached receives a new column in the gradebook where that outcome is assessed for that activity.

Outcomes has some features that would need to be “removed” in order to make sense with competency frameworks (mainly pushing of grades to the gradebook) - this means we cannot build on outcomes, and maintain backwards compatibility. It is therefore recommended to provide:

* A site wide setting to allow competencies - allow either/or but the default will be competencies with no outcomes.
* A simple way to create a competency framework from an existing set of outcomes.
* (optional - requires activity level competencies) A way to import existing outcomes grades as evidence for competencies.

== Open questions for further feedback ==

* Would you expect a teacher to be able to create their own competencies (limited to their own course)? Would competencies that are visible only to a single course (and potentially conflicting with competencies from another course) be really useful?
* Do we need to allow competencies to be linked to individual questions?
* Do we need to allow competencies to be linked to individual items on a rubric/marking guide?
* How should self-evaluation of competencies work?

== Outstanding work for this spec ==

* The examples should use consistent names for user types, competencies and courses. It would be easier to use a real example of competencies from a real framework
* The terminology for child/parent relationships should consistently be:
** Parent
** Sub-competency
* Technical spec (this doc is the requirements).

Competency Based Education

2015-09-17T05:08:39Z

FMCorz: Clarifying that competency frameworks can be created at category level

{{Infobox Project
|name = Framework for competency-based education (CBE) in Moodle
|state = In Progress
|tracker = MDL-49458
|discussion = https://moodle.org/mod/forum/discuss.php?d=316151
|assignee = [[User:Damyon Wiese]]
}}

{{Work in progress}}

=Framework for competency-based education (CBE) in Moodle=

==Summary==

This specification describes our plan to improve support for outcomes-based education in Moodle core. There have been many other attempts to add such systems to Moodle but they all use different data structures and processes and are incompatible. Our aim here is to build basic central structures and APIs to store and manipulate this data, allowing the Moodle community to build innovative custom interfaces on top of it.

This design is based on input from many existing implementations of outcomes/competencies and learning plans including:

* “Outcomes 2” in Joule
* Totara
* Referentiel Activity Module (Skills Repository)
* ELIS

The goal is to implement a system that supports competency based education in a flexible way so that it can be used effectively by the many different target audiences.

The two main concepts are:

'''Competencies''' - a unit of learning, such as "Can make exceptional beer". Competencies can be assigned as goals of courses “This course will teach you to make exceptional beer”, and also to users: “Billy can make exceptional beer”.
Competencies can also be hierarchical, so that the competency above might be marked proficient when some combination of sub-competencies has been marked proficient.
For example : Can make exceptional beer ( Can choose good malt / Can choose good yeasts / Can brew beer in the good temperature / etc..)

'''Learning plans''' - a set of competencies that can be assigned to a student (or cohorts of students). Initially, they will all be marked "incomplete". As students achieve each competency it is marked complete, thereby showing their progress towards finishing all of them. Students achieve competencies either automatically (by successfully completing a course with that competency) or manually (by proving to someone that they are competent via portfolio items etc).

== Competencies ==

A competency is a unit of learning. All competencies belong to a competency framework, and it is likely that a competency framework will be defined by an external body such as an academic standards board.

To create a competency, you first define the framework and then add the competency to it.

Competency frameworks are defined by “Framework Administrators” at the site level, or at a category level. To create and edit competency frameworks, go to “Site administration” -> “Competency Frameworks”, or "Category administration -> Competency frameworks".

[[Image:cbe_spec21_v2.jpg|frame|center|Manage competency frameworks]]<div style="clear: both"></div>

[[Image:cbe_spec19_v3.jpg|frame|center|Add new competency framework]]<div style="clear: both"></div>

Choose “Add new competency framework” and create a new competency framework.

The scale defines how a competency is marked as complete. Each competency framework can define which of the standard Moodle scales should be used when marking a competency. In addition, the “default” value from the scale (the one automatically set when a course is completed) can be configured, and the items from the scale that are deemed to be “proficient” can be defined.

A competency framework may be available to the entire site - or limited to a course category.

The taxonomy refers to the naming for each level in the framework. Up to 4 levels are supported, and the name for each level can be set from the following list:
Domain, Competency, Behaviour, Indicator, Outcome, Level, Concept, Value, Practice, Skill, Proficiency

[[Image:cbe_spec02.jpg|frame|center|Configure scale]]<div style="clear: both"></div>

Now we need to add competencies to the framework. We can import these from a file, or create them from scratch, or import them from Moodle outcomes. When importing competencies, any existing competencies with a matching idnumber will be updated.

[[Image:cbe_spec15.jpg|frame|center|Import competencies]]<div style="clear: both"></div>

Competencies can be imported from the following formats:

(TBD - start with import from CSV).

To see the competencies for a framework, click on the competency framework name.

[[Image:cbe_spec06_v2.jpg|frame|center|Manage competencies]]<div style="clear: both"></div>

This is where we can add and edit competencies in a framework. To edit an existing competency, select it in the competencies tree browser and choose “Edit” from the action menu in the selected competency panel.

To add a new competency, first select the competency that should be the “parent” of this competency from the tree of competencies, and then click “Add Indicator” (the name comes from the taxonomy) from the selected competency panel. Tags can be used to categorise competencies for easy searching, e.g. year level, subject. Tags used for competencies are kept in a separate “tagcloud” (see https://tracker.moodle.org/browse/MDL-50851).

A competency framework can be duplicated, and there is an admin tool for migrating courses from one framework to another (as long as the idnumbers between the competencies in the frameworks can be matched).

If a competency has sub-competencies, you can configure the completion rule for the competency. The default completion rule is “Completed when all sub-competencies are complete”. For more complex rules - you can use a points based system to say when to complete or recommend a competency.

[[Image:cbe_spec23.jpg|frame|center|Add a competency]]<div style="clear: both"></div>

Competencies can be “related” to other competencies. The only effect of this is that the related competencies are listed in the summary of each competency, whenever it is displayed in Moodle. To add a “related” competency to an existing competency, select it from the competency framework and choose “Add related competency” from the action menu.

[[Image:cbe_spec03_v2.jpg|frame|center|Relating competencies to each other]]<div style="clear: both"></div>

== Learning plan templates ==

It would be cumbersome to individually add competencies to a large group of students, and it would be awkward if you made a mistake and had to change the competencies for all the students at a later date. To make this manageable, you can create a “Learning plan template” and assign it to many students. An example of a learning plan template could be: “Computer science, Undergraduate” which lists all the required competencies for a first year computer science student, or it could be more fine grained.

Templates are created by a ”Learning Plan Administrator”. Templates can be imported and exported via CSV. Learning plan templates can be created at a course category, or a site level.

[[Image:cbe_spec22_v2.jpg|frame|center|Manage Learning Plan Templates]]<div style="clear: both"></div>

Once you have created a template, you can add competencies to it.

[[Image:cbe_spec18.jpg|frame|center|List competencies in a template]]<div style="clear: both"></div>

[[Image:cbe_spec00.jpg|frame|center|Add competency to a template]]<div style="clear: both"></div>

Adding competencies to a template will update all the learning plans based on that template.

== User learning plans ==

A user learning plan is a collection of all the competencies they should achieve, optionally before a certain date.

Any user can create their own learning plan, if they have the capability on their own context.

A “Learning Plan Administrator” can create learning plans for other users. They can create the plans individually though another users profile page, or they can create learning plans in bulk from a learning plan template.

Users learning plans can be in one of 3 states, Draft, Active or Completed. Only someone with the capability tool/lp:planmanage (or tool/lp:planmanageown if it’s their own plan) capability can approve learning plans.

A plan can be manually set to completed, by someone with the capabilities listed above, or it will be set to completed when the due date for the plan expires.

[[Image:cbe_spec07.jpg|frame|center|Single users learning plans page]]<div style="clear: both"></div>

[[Image:cbe_spec16.jpg|frame|center|Bulk create user learning plans]]<div style="clear: both"></div>

Note that sites using enrolment plugins can create a cohort based on the enrolments of a set of courses using the admin tool “Course cohorts”. More detail required here.

Competencies can be added to a users learning plan, or to the template the plan was created from and they will automatically appear in the users learning plan. Competencies that exist in the template cannot be removed from the users learning plan. If a single student requires e.g. exemptions from certain competencies - their learning plan can be "unlinked" from the template. This plan will no longer show up in reports generated from the learning plan template - but can now be freely edited.

[[Image:cbe_spec12.jpg|frame|center|User learning plan competencies]]<div style="clear: both"></div>

Note, there can be multiple types of evidence for the same competency. E.g. 2 courses may provide evidence for the same competency and both courses were completed. In this case - both would show as evidence. There can also be multiple examples of "Evidence of prior learning" attached to each competency.<br /><br />Each competency in the table is colour coded to indicate one of the following:

* brown - competency not met, and no evidence or enrolled courses cover this competency
* orange - the competency is not met, but there is evidence, or “in-progress” courses that cover this competency
* green - the competency has been met

If you have the capability tool/lp:planaddevidence you can upload files and urls against a competency in your plan as evidence of prior learning. You can also request that a someone with the capability tool/lp:planmanage reviews the evidence and either rejects or accepts the evidence and changes the status for the competency in the plan.

[[Image:cbe_spec25.jpg|frame|center|Provide evidence]]<div style="clear: both"></div>

[[Image:cbe_spec08.jpg|frame|center|Link evidence]]<div style="clear: both"></div>

To view all the current requests for review, a new “Learning plans” block can be added to an “approvers” dashboard.

[[Image:cbe_spec10.jpg|frame|center|Dashboard Block]]<div style="clear: both"></div>

A User with the capability “tool/lp:planmanage” (at the context of another users plan) can review and approve competency approval requests. A competency approval request is a request for someone to review the evidence that a user has provided against a specific competency and make a decision whether the user has either met or not met the competency. The valid statuses for a review are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

There can only be one “review” per competency for each user (if a review is rejected, and then a new request is made, the previous review will be changed from “Rejected” to “Waiting for review”).

Following the link in the Learning Plans dashboard block, the approver goes to a page that lists all the requests waiting to be approved, and from here they can approve or reject each request. They can also leave comments that will be visible to the student, or to any other reviewers.

To allow multiple authorisers to work together, when looking at a review an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a review, or a review is accepted or rejected, the student will receive a message about the change.

When a completion rule triggers a “recommendation” - the evidence will be added to the competency, and the system will request a “review” of this competency.

TODO Define a new page for assigning roles relative to a user. In totara, there is a “positions” page which does this. This will also be useful for “Mentees”.

[[Image:cbe_spec11.jpg|frame|center|Review competency requests]]<div style="clear: both"></div>

If users have the capability to create their own draft learning plans, but not approve them themselves, someone will need to review all the draft learning plan requests and decide whether or not to make them active. This user can be anyone with “tool/lp:planmanage” capability (at the context of each user with a plan to approve) and they can view all the “Learning plans to approve” link in the Learning Plans dashboard block.

A learning plan approval request made by a user with a draft learning plan from their “Manage learning plans page”. Once a request has been made, the valid statuses for a learning plan approval request are:

* Waiting for review
* In review
* Accepted
* Rejected

[[Image:review_flow_v2.jpg|frame|center|Flow chart of review process]]<div style="clear: both"></div>

To allow multiple authorisers to work together, when looking at a learning plans approval request an authoriser can click on a “Start review” button which will change the status of the request to “In review” and assign them as the reviewer for the request.

Whenever a comment is made against a learning plan approval request, or a learning plan approval request is accepted or rejected, the student will receive a message about the change.

[[Image:cbe_spec04.jpg|frame|center|Review Learning Plan Approval Requests]]<div style="clear: both"></div>

== Course Competencies ==

Competencies can also be linked to a course. This means that when a student completes a course (see course completion) - all of the linked competencies will be marked as “complete” or “recommended” in any of the students active learning plans and the course will be added as evidence against that competency. If the competency is already “met”, the course will still be added as evidence for that competency. If the competency is only set to “recommend” the course will be added as evidence and a review request will be created.

The competency will be given the default value from the competency scale. You can select multiple competencies and add them all at once.

[[Image:cbe_spec17.jpg|frame|center|Course Competencies]]<div style="clear: both"></div>

A teacher in a course, can manually mark the students against the course competencies. For each competency, the teacher will see all of the evidence linked to that competency for the student. They then can assign a value from the competency scale for the student, and optionally make a comment. A record of the teacher marking this competency will be added to the evidence of completion for this competency and the status of the competency will be updated in all active learning plans for the student.

TODO - see how the information from the coverage report can be shown when linking course competencies.

[[Image:cbe_spec14.jpg|frame|center|Grading competencies within a course]]<div style="clear: both"></div>

When manually marking a competency, it is recorded as evidence ie: "Teacher X manually specified this value in this course" - so if the same competency is linked to multiple course it can be marked in each, and this will show up as 2 pieces of evidence.

Reports

Students

For an active Learning Plan, students can see a report of the competencies that are covered/not covered by their current list of enrolled courses. For each competency, they should also be able to see which courses they could enrol in to meet that competency.

[[Image:cbe_spec24.jpg|frame|center|Student Learning Plan Competencies page shows progress, and course discovery]]<div style="clear: both"></div>

Students can see a list of their active learning plans on their dashboard, with a visual indication of progress (a progress bar). Each learning plan is a link to the learning plan report shown above.

Teachers

For teachers and course designers building a set of courses against a competency framework, they should be able to identify competencies that are over/underrepresented by a set of courses. To do this they access a learning plan template, and view the coverage report for that template. This competency coverage report initially shows the coverage from all courses that link to one of the competencies in the template, but the teacher can remove some courses from the selection and regenerate the report.

[[Image:cbe_spec09.jpg|frame|center|Coverage report]]<div style="clear: both"></div>

Teachers and course designers can also see some statistics about a learning plan template. From the learning plan template page, they choose “Statistics” from the action menu to see the number of active/completed learning plans using this template, and the average completion % for the learning plans.

[[Image:cbe_spec13.jpg|frame|center|Statistics for Learning Plan Template]]<div style="clear: both"></div>

Teachers can also see a report in a course that shows for each course competency, which users have completed or not completed it.

[[Image:cbe_spec05.jpg|frame|center|Breakdown report]]<div style="clear: both"></div>

== User roles and capabilities ==

In this system, the actions a user can perform are governed by various capabilities, and are checked at one of several different context levels.

As a reference, the relevant context levels in Moodle are organised in a tree like structure and an example is shown below:

* Site
** User A
** User B
** Category A
*** Course A
*** Course B
** Category B
*** Category C
**** Course C
**** Course D

=== Framework Administrators ===

Competency framework administrators are the central people responsible for creating and maintaining the system wide competency frameworks.

The actions a competency framework administrator can take are:

'''Create/Edit/Delete a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Create/Edit/Delete a competency within a competency framework'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

'''Mark a competency as related to another competency'''

Requires “tool/lp:competencymanage” capability defined at the “Site” or "Course Category" context level.

=== Learning Plan Administrators ===

Learning plan administrators are responsible for creating and maintaining learning plan templates relating to e.g. a specific faculty, set of courses, degree or certification.

The actions a learning plan administrator can take are:

'''Create/Edit/Delete a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Add and remove competencies from a learning plan template'''

Requires “tool/lp:templatemanage” capability defined at the “Site” or "Course Category" context level.

'''Assign a user a learning plan from a learning plan template'''

Requires “tool/lp:planmanage“ capability defined on the “User” context level.

'''View coverage report for a learning plan template'''

Requires “report/lpcoverage:view“ capability defined on the “Site” or "Course Category" context level.

'''View statistics report for a learning plan template'''

Requires “report/lpstatistics:view“ capability defined on the “Site” or "Course Category" context level.

'''View breakdown report for a learning plan template'''

Requires “report/lpbreakdown:view“ capability defined on the “Course” context level.

'''Approve draft learning plans'''

Requires “tool/lp:planapprove“ capability defined on the “User” context level.

'''Approve competency review requests'''

Requires “tool/lp:competencygrade“ capability defined on the “User” context level.

=== Teachers ===

Teachers create and teach courses, that provide evidence of competencies.

The actions a teacher can take are:

'''Assign competencies to a course'''

Requires “tool/lp:coursecompetencymanage” capability defined at the “Course” context level.

'''Manually grade competencies linked to a course'''

Requires “tool/lp:coursecompetencygrade” capability defined at the “Course” context level.

=== Students ===

Students are users that can have learning plans.

The actions a student can take are:

'''View their own learning plans'''

Requires “tool/lp:planviewown” capability defined at the “User” context level.

'''Create their own draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Request approval for their draft learning plan'''

Requires “tool/lp:plancreatedraft” capability defined at the “User” context level.

'''Provide evidence of prior learning for a competency'''

Requires “tool/lp:planaddevidence” capability defined at the “User” context level.

'''Request for someone to grade them for a specific competency'''

Requires “tool/lp:plancompetencyrequestreview” capability defined at the “User” context level.

== Further work (out of scope for first release) ==

Add a rule to award badges when certain competencies are met

This is a simple addition to the existing rules that can be configured to award a badge.

[[Image:cbe_spec20.jpg|frame|center|Custom badge condition]]<div style="clear: both"></div>

=== Linking activities as evidence of competencies ===

[[Image:cbe_spec01.jpg|frame|center|Linking an activity to some course competencies]]<div style="clear: both"></div>

Teachers can also quickly find resources and activities that have not been mapped to any competencies. This is done on the competency mapping report which shows all resources and activities for the course, as well as the linked competencies for each. This report will also list any course competencies that are not linked to any activities or resources.

=== Alternative ways to “automatically complete” competencies ===

* Trigger based on activity completion. Configured when linking competencies to a course.

=== Additional reports ===

E.g. https://moodle.org/mod/forum/discuss.php?d=316151#p1266980

== Interaction with the existing Moodle “Outcomes” ==

Description of existing “Outcomes”

Outcomes define a set of system wide scales that can be used to grade activities. The value chosen from the scale is pushed to the gradebook for each activity and a custom report will show the average of outcomes across a course, or the entire site. Not all activities and resources support outcomes, only scorm, quiz, lti, lesson, glossary, data, chat, assign and forum.

Any activity that has an outcome attached receives a new column in the gradebook where that outcome is assessed for that activity.

Outcomes has some features that would need to be “removed” in order to make sense with competency frameworks (mainly pushing of grades to the gradebook) - this means we cannot build on outcomes, and maintain backwards compatibility. It is therefore recommended to provide:

* A site wide setting to allow competencies - allow either/or but the default will be competencies with no outcomes.
* A simple way to create a competency framework from an existing set of outcomes.
* (optional - requires activity level competencies) A way to import existing outcomes grades as evidence for competencies.

== Open questions for further feedback ==

* Would you expect a teacher to be able to create their own competencies (limited to their own course)? Would competencies that are visible only to a single course (and potentially conflicting with competencies from another course) be really useful?
* Do we need to allow competencies to be linked to individual questions?
* Do we need to allow competencies to be linked to individual items on a rubric/marking guide?
* How should self-evaluation of competencies work?

== Outstanding work for this spec ==

* The examples should use consistent names for user types, competencies and courses. It would be easier to use a real example of competencies from a real framework
* The terminology for child/parent relationships should consistently be:
** Parent
** Sub-competency
* Technical spec (this doc is the requirements).

Moodle libraries credits

2015-05-06T04:04:13Z

FMCorz: Adding Amazon S3

Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:

==ADOdb==

''lib/adodb''

Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.

Version: 5.19

Copyright © 2000-2006 John Lim (''jlim AT natsoft DOT com DOT my'')

License: Dual LGPL and BSD-style

http://adodb.sourceforge.net

==Amazon S3==

''repository/s3/S3.php''

A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR.

Version: 0.5.1-dev

Copyright (c) 2013, Donovan Schönknecht

License: BSD 2-Clause

https://github.com/tpyo/amazon-s3-php-class

==EvalMath==

''lib/evalmath''

Class to safely evaluate math expressions

Copyright Miles Kaufmann

License: BSD

http://www.twmagic.com/

==FLV player==

''filter/mediaplugin/flvplayer.swf''

Flash movie to play FLV files

Copyright Jeroen Wijering

License: GNU GPL

http://www.jeroenwijering.com

==FPDF Class==

''lib/fpdf''

Class to generate PDF files

Version: 1.53

Copyright Olivier PLATHEY

License: Freeware

==GeoIP==

''lib/geoip''

Library for precessing of GeoIP data files

Version: 1.6

Copyright MaxMind

License: LGPL

http://www.maxmind.com/app/php

==Graph Class==

''lib/graphlib.php''

Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.

Version: 1.6.3 (with modifications)

Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')

License: LGPL

==html2text==

''lib/html2text.php''

PHP script to convert HTML into an approximate text equivalent

Version: 1.0 (with modifications)

Copyright © 2002 Mark Wilton-Jones

License: GNU GPL

http://roundcube.net/

==htmlArea==

''lib/editor''

Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla

Version: 3.0 beta (with modifications)

Copyright © 2002 interactivetools.com, inc.

License: htmlArea License (based on BSD license)

==IP-Atlas==

''lib/ipatlas''

PHP scripts to show the location of an IP address on a map.

Version: 1.0 (with modifications)

Copyright © 2002 Ivan Kozik

License: GNU GPL

http://www.xpenguin.com/ip-atlas.php

==Services_JSON==

''lib/json''

Allows PHP->JS communication via JSON

Version: 1.3.1

Copyright © 2005 Michal Migurski

License: Modified BSD (GPL-compatible)

http://pear.php.net/pepr/pepr-proposal-show.php?id=198

==kses==

''lib/kses.php''

HTML/XHTML filter that only allows some elements and attributes

Version: 0.2.2

Copyright © 2002, 2003, 2005 Ulf Harnhammar

License: GNU GPL

http://sourceforge.net/projects/kses

==mimeTeX==

''filter/tex''

Compiled C program to convert TeX into GIFs

Version: 1.4

Copyright © 2002-2004 John Forkosh Associates, Inc

License: GNU GPL

http://www.forkosh.com/mimetex.html

==mp3player==

''lib/mp3player''

Flash movie to play streaming MP3s

Copyright © 2005 Andrew Walker

License: GNU GPL

==overlibmws==

''lib/overlib.js''

Javascript library to enable DHTML popups, floating windows, events etc

Version: July 2004

Copyright © 2002-2004 Foteos Macrides

Copyright © 1998-2004 Erik Bosrup

License: Artistic Open Source License

http://www.macridesweb.com/oltest/

==PclZip==

''lib/pclzip''

Class to create, manage and unpack zip files.

Version: 2.4 RC1

Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')

License: GNU GPL

http://www.phpconcept.net

==PEAR OLE Classes==

''lib/pear''

Class to write Excel files

Version: 0.5

Copyright © 2004 Xavier Noguer

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/OLE

==PEAR Spreadsheet_Excel_Writer==

''lib/pear''

Class to write Excel files

Version: 0.9.1

Copyright © 2004 Xavier Noguer and Mika Tuupola

License: LGPL

http://pear.php.net/package/Spreadsheet_Excel_Writer

==PEAR HTML_Quickform==

''lib/pear''

Class to write forms

Version: 3.2.6

Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform

==PEAR HTML_Quickform_Renderer_Tableless==

''lib/pear''

Class to render forms without tables

Version: 0.3.4

Copyright © 2005 Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform_Renderer_Tableless

==PEAR HTML_QuickForm_DHTMLRulesTableless==

''lib/pear''

Class to render validation notices with dhtml

Version: 0.1.2

Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless

==PEAR HTML_Common==

''lib/pear''

Class with many common HTML functions (used by HTML Quickform)

Version: 0.3.4

Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Common

==PEAR XML_Parser==

''lib/pear''

Class implementing one handy (sax-expat) XML parser

Version: 1.3.2

Copyright © 2004-2008 The PHP Group & Stephan Schmidt

License: New BSD License

http://pear.php.net/package/XML_Parser

==PHP mailer==

''lib/class.phpmailer.php''

Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.

Version 1.73

Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')
License: LGPL

http://phpmailer.sourceforge.net

==PHP Markdown==

''lib/markdown.php''

Functions to convert from the Markdown text format into clean XHTML.

Version: 1.0b9 (with modifications)

Copyright © 2003-2004 , John Gruber

Copyright © 2004 , Michel Fortin

License: LGPL

http://www.michelf.com/projects/php-markdown/

==Snoopy==

''lib/snoopy''

A PHP net client

Version: 1.0

Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')
License: GNU LGPL

http://snoopy.sourceforge.com

==SMTP class==

''lib/class.smtp.php''

Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.

Version: 03/26/2001

Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')

==Spike PHPCoverage==

''lib/spikephpcoverage''

PHP code coverage reporting tool

Version: 0.8.2 (with modifications)

Copyright © 2004 SpikeSource Inc

License: LGPL

http://developer.spikesource.com/projects/phpcoverage

==Typo3 Character Set Class==

''lib/typo3''

Class for conversion between charsets and multibyte-savy operations with strings.

Version: 4.7.19

Copyright © 2003-2005 Kasper Skaarhoj

Licence: GNU GPL

http://typo3.org/

==Yahoo User Interface==

''lib/yui''

The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.

CVS version: 2.3.0

Copyright (c) 2006, Yahoo! Inc.

Licence: BSD

http://developer.yahoo.com/yui/

[[Category:Credits]]

Moodle libraries credits

2015-05-06T03:59:02Z

FMCorz: /* ADOdb */

Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:

==ADOdb==

''lib/adodb''

Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.

Version: 5.19

Copyright © 2000-2006 John Lim (''jlim AT natsoft DOT com DOT my'')

License: Dual LGPL and BSD-style

http://adodb.sourceforge.net

==EvalMath==

''lib/evalmath''

Class to safely evaluate math expressions

Copyright Miles Kaufmann

License: BSD

http://www.twmagic.com/

==FLV player==

''filter/mediaplugin/flvplayer.swf''

Flash movie to play FLV files

Copyright Jeroen Wijering

License: GNU GPL

http://www.jeroenwijering.com

==FPDF Class==

''lib/fpdf''

Class to generate PDF files

Version: 1.53

Copyright Olivier PLATHEY

License: Freeware

==GeoIP==

''lib/geoip''

Library for precessing of GeoIP data files

Version: 1.6

Copyright MaxMind

License: LGPL

http://www.maxmind.com/app/php

==Graph Class==

''lib/graphlib.php''

Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.

Version: 1.6.3 (with modifications)

Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')

License: LGPL

==html2text==

''lib/html2text.php''

PHP script to convert HTML into an approximate text equivalent

Version: 1.0 (with modifications)

Copyright © 2002 Mark Wilton-Jones

License: GNU GPL

http://roundcube.net/

==htmlArea==

''lib/editor''

Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla

Version: 3.0 beta (with modifications)

Copyright © 2002 interactivetools.com, inc.

License: htmlArea License (based on BSD license)

==IP-Atlas==

''lib/ipatlas''

PHP scripts to show the location of an IP address on a map.

Version: 1.0 (with modifications)

Copyright © 2002 Ivan Kozik

License: GNU GPL

http://www.xpenguin.com/ip-atlas.php

==Services_JSON==

''lib/json''

Allows PHP->JS communication via JSON

Version: 1.3.1

Copyright © 2005 Michal Migurski

License: Modified BSD (GPL-compatible)

http://pear.php.net/pepr/pepr-proposal-show.php?id=198

==kses==

''lib/kses.php''

HTML/XHTML filter that only allows some elements and attributes

Version: 0.2.2

Copyright © 2002, 2003, 2005 Ulf Harnhammar

License: GNU GPL

http://sourceforge.net/projects/kses

==mimeTeX==

''filter/tex''

Compiled C program to convert TeX into GIFs

Version: 1.4

Copyright © 2002-2004 John Forkosh Associates, Inc

License: GNU GPL

http://www.forkosh.com/mimetex.html

==mp3player==

''lib/mp3player''

Flash movie to play streaming MP3s

Copyright © 2005 Andrew Walker

License: GNU GPL

==overlibmws==

''lib/overlib.js''

Javascript library to enable DHTML popups, floating windows, events etc

Version: July 2004

Copyright © 2002-2004 Foteos Macrides

Copyright © 1998-2004 Erik Bosrup

License: Artistic Open Source License

http://www.macridesweb.com/oltest/

==PclZip==

''lib/pclzip''

Class to create, manage and unpack zip files.

Version: 2.4 RC1

Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')

License: GNU GPL

http://www.phpconcept.net

==PEAR OLE Classes==

''lib/pear''

Class to write Excel files

Version: 0.5

Copyright © 2004 Xavier Noguer

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/OLE

==PEAR Spreadsheet_Excel_Writer==

''lib/pear''

Class to write Excel files

Version: 0.9.1

Copyright © 2004 Xavier Noguer and Mika Tuupola

License: LGPL

http://pear.php.net/package/Spreadsheet_Excel_Writer

==PEAR HTML_Quickform==

''lib/pear''

Class to write forms

Version: 3.2.6

Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform

==PEAR HTML_Quickform_Renderer_Tableless==

''lib/pear''

Class to render forms without tables

Version: 0.3.4

Copyright © 2005 Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform_Renderer_Tableless

==PEAR HTML_QuickForm_DHTMLRulesTableless==

''lib/pear''

Class to render validation notices with dhtml

Version: 0.1.2

Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless

==PEAR HTML_Common==

''lib/pear''

Class with many common HTML functions (used by HTML Quickform)

Version: 0.3.4

Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Common

==PEAR XML_Parser==

''lib/pear''

Class implementing one handy (sax-expat) XML parser

Version: 1.3.2

Copyright © 2004-2008 The PHP Group & Stephan Schmidt

License: New BSD License

http://pear.php.net/package/XML_Parser

==PHP mailer==

''lib/class.phpmailer.php''

Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.

Version 1.73

Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')
License: LGPL

http://phpmailer.sourceforge.net

==PHP Markdown==

''lib/markdown.php''

Functions to convert from the Markdown text format into clean XHTML.

Version: 1.0b9 (with modifications)

Copyright © 2003-2004 , John Gruber

Copyright © 2004 , Michel Fortin

License: LGPL

http://www.michelf.com/projects/php-markdown/

==Snoopy==

''lib/snoopy''

A PHP net client

Version: 1.0

Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')
License: GNU LGPL

http://snoopy.sourceforge.com

==SMTP class==

''lib/class.smtp.php''

Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.

Version: 03/26/2001

Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')

==Spike PHPCoverage==

''lib/spikephpcoverage''

PHP code coverage reporting tool

Version: 0.8.2 (with modifications)

Copyright © 2004 SpikeSource Inc

License: LGPL

http://developer.spikesource.com/projects/phpcoverage

==Typo3 Character Set Class==

''lib/typo3''

Class for conversion between charsets and multibyte-savy operations with strings.

Version: 4.7.19

Copyright © 2003-2005 Kasper Skaarhoj

Licence: GNU GPL

http://typo3.org/

==Yahoo User Interface==

''lib/yui''

The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.

CVS version: 2.3.0

Copyright (c) 2006, Yahoo! Inc.

Licence: BSD

http://developer.yahoo.com/yui/

[[Category:Credits]]

Moodle libraries credits

2015-05-06T03:55:12Z

FMCorz: /* Typo3 Character Set Class */

Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:

==ADOdb==

''lib/adodb''

Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.

Version: 4.93

Copyright © 2000-2006 John Lim (''jlim AT natsoft DOT com DOT my'')

License: Dual LGPL and BSD-style

http://adodb.sourceforge.net

==EvalMath==

''lib/evalmath''

Class to safely evaluate math expressions

Copyright Miles Kaufmann

License: BSD

http://www.twmagic.com/

==FLV player==

''filter/mediaplugin/flvplayer.swf''

Flash movie to play FLV files

Copyright Jeroen Wijering

License: GNU GPL

http://www.jeroenwijering.com

==FPDF Class==

''lib/fpdf''

Class to generate PDF files

Version: 1.53

Copyright Olivier PLATHEY

License: Freeware

==GeoIP==

''lib/geoip''

Library for precessing of GeoIP data files

Version: 1.6

Copyright MaxMind

License: LGPL

http://www.maxmind.com/app/php

==Graph Class==

''lib/graphlib.php''

Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.

Version: 1.6.3 (with modifications)

Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')

License: LGPL

==html2text==

''lib/html2text.php''

PHP script to convert HTML into an approximate text equivalent

Version: 1.0 (with modifications)

Copyright © 2002 Mark Wilton-Jones

License: GNU GPL

http://roundcube.net/

==htmlArea==

''lib/editor''

Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla

Version: 3.0 beta (with modifications)

Copyright © 2002 interactivetools.com, inc.

License: htmlArea License (based on BSD license)

==IP-Atlas==

''lib/ipatlas''

PHP scripts to show the location of an IP address on a map.

Version: 1.0 (with modifications)

Copyright © 2002 Ivan Kozik

License: GNU GPL

http://www.xpenguin.com/ip-atlas.php

==Services_JSON==

''lib/json''

Allows PHP->JS communication via JSON

Version: 1.3.1

Copyright © 2005 Michal Migurski

License: Modified BSD (GPL-compatible)

http://pear.php.net/pepr/pepr-proposal-show.php?id=198

==kses==

''lib/kses.php''

HTML/XHTML filter that only allows some elements and attributes

Version: 0.2.2

Copyright © 2002, 2003, 2005 Ulf Harnhammar

License: GNU GPL

http://sourceforge.net/projects/kses

==mimeTeX==

''filter/tex''

Compiled C program to convert TeX into GIFs

Version: 1.4

Copyright © 2002-2004 John Forkosh Associates, Inc

License: GNU GPL

http://www.forkosh.com/mimetex.html

==mp3player==

''lib/mp3player''

Flash movie to play streaming MP3s

Copyright © 2005 Andrew Walker

License: GNU GPL

==overlibmws==

''lib/overlib.js''

Javascript library to enable DHTML popups, floating windows, events etc

Version: July 2004

Copyright © 2002-2004 Foteos Macrides

Copyright © 1998-2004 Erik Bosrup

License: Artistic Open Source License

http://www.macridesweb.com/oltest/

==PclZip==

''lib/pclzip''

Class to create, manage and unpack zip files.

Version: 2.4 RC1

Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')

License: GNU GPL

http://www.phpconcept.net

==PEAR OLE Classes==

''lib/pear''

Class to write Excel files

Version: 0.5

Copyright © 2004 Xavier Noguer

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/OLE

==PEAR Spreadsheet_Excel_Writer==

''lib/pear''

Class to write Excel files

Version: 0.9.1

Copyright © 2004 Xavier Noguer and Mika Tuupola

License: LGPL

http://pear.php.net/package/Spreadsheet_Excel_Writer

==PEAR HTML_Quickform==

''lib/pear''

Class to write forms

Version: 3.2.6

Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform

==PEAR HTML_Quickform_Renderer_Tableless==

''lib/pear''

Class to render forms without tables

Version: 0.3.4

Copyright © 2005 Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Quickform_Renderer_Tableless

==PEAR HTML_QuickForm_DHTMLRulesTableless==

''lib/pear''

Class to render validation notices with dhtml

Version: 0.1.2

Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless

==PEAR HTML_Common==

''lib/pear''

Class with many common HTML functions (used by HTML Quickform)

Version: 0.3.4

Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

http://pear.php.net/package/HTML_Common

==PEAR XML_Parser==

''lib/pear''

Class implementing one handy (sax-expat) XML parser

Version: 1.3.2

Copyright © 2004-2008 The PHP Group & Stephan Schmidt

License: New BSD License

http://pear.php.net/package/XML_Parser

==PHP mailer==

''lib/class.phpmailer.php''

Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.

Version 1.73

Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')
License: LGPL

http://phpmailer.sourceforge.net

==PHP Markdown==

''lib/markdown.php''

Functions to convert from the Markdown text format into clean XHTML.

Version: 1.0b9 (with modifications)

Copyright © 2003-2004 , John Gruber

Copyright © 2004 , Michel Fortin

License: LGPL

http://www.michelf.com/projects/php-markdown/

==Snoopy==

''lib/snoopy''

A PHP net client

Version: 1.0

Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')
License: GNU LGPL

http://snoopy.sourceforge.com

==SMTP class==

''lib/class.smtp.php''

Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.

Version: 03/26/2001

Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')

==Spike PHPCoverage==

''lib/spikephpcoverage''

PHP code coverage reporting tool

Version: 0.8.2 (with modifications)

Copyright © 2004 SpikeSource Inc

License: LGPL

http://developer.spikesource.com/projects/phpcoverage

==Typo3 Character Set Class==

''lib/typo3''

Class for conversion between charsets and multibyte-savy operations with strings.

Version: 4.7.19

Copyright © 2003-2005 Kasper Skaarhoj

Licence: GNU GPL

http://typo3.org/

==Yahoo User Interface==

''lib/yui''

The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.

CVS version: 2.3.0

Copyright (c) 2006, Yahoo! Inc.

Licence: BSD

http://developer.yahoo.com/yui/

[[Category:Credits]]

Message API

2015-04-23T05:19:27Z

FMCorz: Example of message popup

==What is this document?==

This document describes how to make use of the Moodle Messaging API to send messages to Moodle users.

If you are after a general introduction on using the Moodle Messaging system go to [[:en:Messaging|messaging user documentation]].

If you are looking for details of how the Messaging system's internal structure was implemented, go to [[Messaging 2.0]].

If you are looking for instructions on the implementation of a custom message processor (a component that receives messages sent to a user), go to [[Messaging custom components]].

If you are looking for instructions on sending messages programatically within Moodle then read on...

==Overview==

Moodle components have the ability to send messages to users via the Moodle messaging system. Any type of component, for example a plugin or block, can register as a message producer then send messages to users.

==File locations==

The Message API code is contained within lib/messagelib.php and is automatically included for you during page setup.

==Functions==

message_send() is the primary point of contact for the message API. Call it to send a message to a user. You can find a full description of the arguments that must be supplied at (link to phpdocs). There is also an example below.

==Message popup==
{{Moodle_2.9}}
A Javascript popup can be displayed through a link to invite a user to message another. In order to use this feature, you need to require the Javascript libraries using ''message_messenger_requirejs()'' and create a link with the attributes returned by ''message_messenger_sendmessage_link_params()''. More in the examples.

==Examples==

===How to register as a message producer===

The messages produced by a message provider is defined in the /db/messages.php file of a component. Below is code from the quiz module's messages.php file, shown as an example.
<code php>
defined('MOODLE_INTERNAL') || die();
$messageproviders = array (
// Notify teacher that a student has submitted a quiz attempt
'submission' => array (
'capability' => 'mod/quiz:emailnotifysubmission'
),
// Confirm a student's quiz attempt
'confirmation' => array (
'capability' => 'mod/quiz:emailconfirmsubmission'
)
);
</code>

The quiz can send two kinds of messages, quiz "submission" and "confirmation" notifications. Each message type is only available to users with the appropriate capability. Please note that the capability is checked at the system level context. Users who have this capability will have this message listed in their messaging preferences. You can omit the capability section if your message should be visible for all users. For example forum post notifications are available to all users.

<code php>
$messageproviders = array (
// Ordinary single forum posts
'posts' => array (
)
);
</code>

When displaying your message types in a user's messaging preferences it will use a string from your component's language file called "messageprovider:messagename". For example here are the relevant strings from the quiz's language file.
<code php>
$string['messageprovider:confirmation'] = 'Confirmation of your own quiz submissions';
$string['messageprovider:submission'] = 'Notification of quiz submissions';
</code>

Once your messages.php is complete you need to increase the version number of your component in its version.php. That will cause Moodle to check messages.php looking for new or changed message definitions. Log in as an admin and go to /admin/index.php (the Notifications page) to start the upgrade process.

===How to send a message===

Here is example code showing you how to actually send a message. The example shows the construction of a object with specific properties, which is then passed to the message_send() function that uses the information to send a message.
<code php>
$eventdata = new stdClass();
$eventdata->component = 'mod_quiz'; //your component name
$eventdata->name = 'submission'; //this is the message name from messages.php
$eventdata->userfrom = $USER;
$eventdata->userto = $touser;
$eventdata->subject = $subject;
$eventdata->fullmessage = $message;
$eventdata->fullmessageformat = FORMAT_PLAIN;
$eventdata->fullmessagehtml = '';
$eventdata->smallmessage = '';
$eventdata->notification = 1; //this is only set to 0 for personal messages between users
message_send($eventdata);
</code>

===How to set-up the message popup===

Here is example code showing you how to set-up the Javascript popup link.
<code php>
require_once('message/lib.php');
$userid = 2;
$userto = $DB->get_record('user', array('id' => $userid));

message_messenger_requirejs();
$url = new moodle_url('message/index.php', array('id' => $userto->id));
$attributes = message_messenger_sendmessage_link_params($userto);
echo html_writer::link($url, 'Send a message', $attributes);
</code>

==See also==
* [[Core APIs]]

[[Category:API]]
[[Category:Tutorial]]
[[Category:Plugins]]
[[Category:Messaging]]

Message API

2015-04-23T05:12:41Z

FMCorz: Adding docs about the message popup

==What is this document?==

This document describes how to make use of the Moodle Messaging API to send messages to Moodle users.

If you are after a general introduction on using the Moodle Messaging system go to [[:en:Messaging|messaging user documentation]].

If you are looking for details of how the Messaging system's internal structure was implemented, go to [[Messaging 2.0]].

If you are looking for instructions on the implementation of a custom message processor (a component that receives messages sent to a user), go to [[Messaging custom components]].

If you are looking for instructions on sending messages programatically within Moodle then read on...

==Overview==

Moodle components have the ability to send messages to users via the Moodle messaging system. Any type of component, for example a plugin or block, can register as a message producer then send messages to users.

==File locations==

The Message API code is contained within lib/messagelib.php and is automatically included for you during page setup.

==Functions==

message_send() is the primary point of contact for the message API. Call it to send a message to a user. You can find a full description of the arguments that must be supplied at (link to phpdocs). There is also an example below.

==Message popup==
{{Moodle_2.9}}
A Javascript popup can be displayed through a link to invite a user to message another. In order to use this feature, you need to require the Javascript libraries using ''message_messenger_requirejs()'' and create a link with the attributes returned by ''message_messenger_sendmessage_link_params()''. More in the examples.

==Examples==

===How to register as a message producer===

The messages produced by a message provider is defined in the /db/messages.php file of a component. Below is code from the quiz module's messages.php file, shown as an example.
<code php>
defined('MOODLE_INTERNAL') || die();
$messageproviders = array (
// Notify teacher that a student has submitted a quiz attempt
'submission' => array (
'capability' => 'mod/quiz:emailnotifysubmission'
),
// Confirm a student's quiz attempt
'confirmation' => array (
'capability' => 'mod/quiz:emailconfirmsubmission'
)
);
</code>

The quiz can send two kinds of messages, quiz "submission" and "confirmation" notifications. Each message type is only available to users with the appropriate capability. Please note that the capability is checked at the system level context. Users who have this capability will have this message listed in their messaging preferences. You can omit the capability section if your message should be visible for all users. For example forum post notifications are available to all users.

<code php>
$messageproviders = array (
// Ordinary single forum posts
'posts' => array (
)
);
</code>

When displaying your message types in a user's messaging preferences it will use a string from your component's language file called "messageprovider:messagename". For example here are the relevant strings from the quiz's language file.
<code php>
$string['messageprovider:confirmation'] = 'Confirmation of your own quiz submissions';
$string['messageprovider:submission'] = 'Notification of quiz submissions';
</code>

Once your messages.php is complete you need to increase the version number of your component in its version.php. That will cause Moodle to check messages.php looking for new or changed message definitions. Log in as an admin and go to /admin/index.php (the Notifications page) to start the upgrade process.

===How to send a message===

Here is example code showing you how to actually send a message. The example shows the construction of a object with specific properties, which is then passed to the message_send() function that uses the information to send a message.
<code php>
$eventdata = new stdClass();
$eventdata->component = 'mod_quiz'; //your component name
$eventdata->name = 'submission'; //this is the message name from messages.php
$eventdata->userfrom = $USER;
$eventdata->userto = $touser;
$eventdata->subject = $subject;
$eventdata->fullmessage = $message;
$eventdata->fullmessageformat = FORMAT_PLAIN;
$eventdata->fullmessagehtml = '';
$eventdata->smallmessage = '';
$eventdata->notification = 1; //this is only set to 0 for personal messages between users
message_send($eventdata);
</code>

==See also==
* [[Core APIs]]

[[Category:API]]
[[Category:Tutorial]]
[[Category:Plugins]]
[[Category:Messaging]]

User:Frédéric Massart 2

2014-11-10T10:03:21Z

FMCorz: /* test http://google.com */

= test http://google.com =
1
= test http://google.com =
3
= test http://google.com =
4
= test http://google.com =

User:Frédéric Massart 2

2014-11-10T10:02:59Z

FMCorz: Created page with "==== test http://google.com ===="

==== test http://google.com ====

Cache API

2014-09-24T09:36:38Z

FMCorz: /* Creating a definition */

This document details the Cache API aka MUC aka Moodle's Universal Cache.
I've chosen to use a tutorial/example flow for this document always working with a theoretical module plugin called myplugin.
There is also a [[Cache API - Quick reference]] if you would rather read that.

==Basic usage==
It's very easy to get started with the Cache API. It is designed to be as easy and as quick to use as possible and is predominantely self contained.
All you need to do is add a definition for your cache and you are ready to start working with the Cache API.

===Creating a definition===
Cache definitions exist within the db/caches.php file for a component/plugin.<br />
In the case of core that is the moodle/lib/db/caches.php file, in the case of a module that would be moodle/mod/myplugin/db/caches.php.

The definition is used API in order to understand a little about the cache and what it is being used for, it also allows the administrator to set things up especially for the definition if they want.
From a development point of view the definition allows you to tell the API about your cache, what it requires, and any (if any) advanced features you want it to have.<br />
The following shows a basic definition containing just the bare minimum:
<code php>
// moodle/mod/myplugin/db/caches.php
$definitions = array(
'somedata' => array(
'mode' => cache_store::MODE_APPLICATION
)
);
</code>
This informs the API that the myplugin module has a cache called ''somedata'' and that it is an application (globally shared) cache.<br />
When creating a definition thats the bare minimum, to provide an area ''(somedata)'' and declare the type of the cache application, session, or request.<br />
:An application cache is a shared cache, all users can access it.<br />
:Session caches are, well, just stores in the users session.<br />
:Request caches you can think of as static caches, only available to the user owning the request, and only alive until the end of the request.<br />
There are of course many more options available that allow you to really take the cache by the reigns, you can read about some of the important ones further on, or skip ahead to [[#The definition]] section which details the available options in full.

Please note that for each definition a language string with the name ''cachedef_'' followed by the name of the definition is expected. Using the example above you would have to define:

<code php>
// moodle/mod/myplugin/lang/en/mod_myplugin.php
$string['cachedef_somedata'] = 'This is the description of the cache somedata';
</code>

===Getting a cache object===
Once your definition has been created you should bump the version number so that Moodle upgrades and processes the definitions file at which point your definition will be useable.

Now within code you can get a cache object to interact with in the following manner.

<code php>
$cache = cache::make('mod_myplugin', 'mycache');
</code>

The cache::make method is a factory method, it will create a cache object to allow you to work with your cache. The cache object will be one of several classes chosen by the API based upon what your definition contains. All of these classes will extend the base cache class, and in nearly all cases you will get one of cache_application, cache_session, or cache_request depending upon the mode you selected.

===Using your cache object===
Once you have a cache object (will extend the cache class and implements cache_loader) you are ready to start interacting with the cache.

Of course there are three basic basic operations. get, set, and delete.

The first is to send something to the cache.
<code php>
$result = $cache->set('key', 'value');
</code>
Easy enough. The key must an int or a string. The value can be absolutely anything your want.
The result is true if the operation was a success, false otherwise.

The second is to fetch something from the cache.
<code php>
$data = $cache->get('key');
</code>
$data will either be what ever was being stored in the cache, or false if the cache could not find the key.

The third and final operation is delete.
<code php>
$result = $cache->delete('key');
</code>
Again just like set the result will either be true if the operation was a success, or false otherwise.

You can also set, get, and delete multiple key=>value pairs in a single transaction.
<code php>
$result = $cache->set_many(array(
'key1' => 'data1',
'key3' => 'data3'
));
// $result will be the number of pairs sucessfully set.

$result = $cache->get_many(array('key1', 'key2', 'key3'));
print_r($result);
// Will print the following:
// array(
// 'key1' => 'data1',
// 'key2' => false,
// 'key3' => 'data3'
// )

$result = $cache->delete_many(array('key1', 'key3');
// $result will be the number of records sucessfully deleted.
</code>

That covers the basic operation of the Cache API.<br />
In many situations there is not going to be any more to it than that.

==Ad-hoc Caches==
This is the alternative method of using the cache API.<br />
It involves creating a cache using just the required params at the time that it is required. It doesn't require that a definition exists making it quicker and easier to use, however it can only use the default settings and is only recommended for insignificant caches (rarely used during operation, never to be mapped or customised, only existsing in a single place in code).

Once a cache object has been retrieved it operates exactly as the same as a cache that has been created for a definition.

To create an ad-hoc cache you would use the following:
<code php>
$cache = cache::make_from_params(cache_store::MODE_APPLICATION, 'mod_myplugin', 'mycache');
</code>

Really don't be lazy, if you don't have a good reason to use an ad-hoc cache you should be spending a extra 5 minutes creating a definition.

==The definition==

The above section illustrated how to create a basic definition, specifying just the area name (the key) and the mode for the definition. Those being the two required properties for a definition.<br />
There are many other options that will let you make the most of the Cache API and will undoubtedly be required when implementing and converting cache solutions to the Cache API.

The following details the options available to a definition and their defaults if not applied:

<code php>
$definitions = array(
// The name of the cache area is the key. The component/plugin will be picked up from the file location.
'area' => array(
'mode' => cache_store::MODE_*,
'simplekeys' => false,
'simpledata' => false,
'requireidentifiers' => array('ident1', 'ident2'),
'requiredataguarantee' => false,
'requiremultipleidentifiers' => false,
'requirelockingread' => false,
'requirelockingwrite' => false,
'maxsize' => null,
'overrideclass' => null,
'overrideclassfile' => null,
'datasource' => null,
'datasourcefile' => null,
'staticacceleration' => false,
'staticaccelerationsize' => null,
'ttl' => 0,
'mappingsonly' => false,
'invalidationevents' => array('event1', 'event2'),
'sharingoptions' => cache_definition::SHARING_DEFAULT,
'defaultsharing' => cache_definition::SHARING_DEFAULT,
)
);
</code>

===Setting requirements===
The definition can specify several requirements for the cache.<br />
This includes identifiers that must be provided when creating the cache object, that the store guarantees data stored in it will remain there until removed, a store that supports multiple identifiers, and finally read/write locking.
The options for these are as follows:

; simplekeys : [bool] Set to true if your cache will only use simple keys for its items.<br />Simple keys consist of digits, underscores and the 26 chars of the english language. a-zA-Z0-9_<br />If true the keys won't be hashed before being passed to the cache store for gets/sets/deletes. It will be better for performance and possible only because we know the keys are safe.
; simpledata : [bool] If set to true we know that the data is scalar or array of scalar.
; requireidentifiers : [array] An array of identifiers that must be provided to the cache when it is created.
; requiredataguarantee : [bool] If set to true then only stores that can guarantee data will remain available once set will be used.
; requiremultipleidentifiers : [bool] If set to true then only stores that support multiple identifiers will be used.
; requirelockingread : [bool] If set to true then a lock will be gained before reading from the cache store. It is recommended not to use this setting unless 100% absolutely positively required.<br />Remember 99.9% of caches will NOT need this setting.<br />This setting will only be used for application caches presently.
; requirelockingwrite : [bool] If set to true then a lock will be gained before writing to the cache store. As above this is not recommended unless truly needed. Please think about the order of your code and deal with race conditions there first.<br />This setting will only be used for application caches presently.

===Cache modifiers===
You are also to modify the way in which the cache is going to operate when working for your definition.<br />
By enabling the static option the Cache API will only ever generate a single cache object for your definition on the first request for it, further requests will be returned the original instance.<br />This greatly speeds up the collecting of a cache object.<br />
Enabling persistence also enables a static store within the cache object, anything set to the cache, or retrieved from it will be stored in that static array for the life of the request.
This makes the persistence options some of the most powerful. If you know you are going to be using you cache over and over again or if you know you will be making lots of requests for the same items then this will provide a great performance boost.
Of course the static storage of cache objects and of data is costly in terms of memory and should only be used when actually required, as such it is turned off by default.
As well as persistence you can also set a maximum number of items that the cache should store (not a hard limit, its up to each store) and a time to live (ttl) although both are discouraged as efficient design negates the need for both in most situations.

; staticacceleration : [bool] This setting does two important things. First it tells the cache API to only instantiate the cache structure for this definition once, further requests will be given the original instance.<br />Second the cache loader will keep an array of the items set and retrieved to the cache during the request.<br />This has several advantages including better performance without needing to start passing the cache instance between function calls, the downside is that the cache instance + the items used stay within memory.<br />Consider using this setting when you know that there are going to be many calls to the cache for the same information or when you are converting existing code to the cache and need to access the cache within functions but don't want to add it as an argument to the function.
; staticaccelerationsize : [int] This supplements the above setting by limiting the number of items in the caches persistent array of items.<br />Tweaking this setting lower will allow you to minimise the memory implications above while hopefully still managing to offset calls to the cache store.
; ttl : [int] A time to live for the data (in seconds). It is strongly recommended that you don't make use of this and instead try to create an event driven invalidation system (even if the event is just time expiring, better not to rely on ttl).<br />Not all cache stores will support this natively and there are undesired performance impacts if the cache store does not.
; maxsize : [int] If set this will be used as the maximum number of entries within the cache store for this definition.<br />Its important to note that cache stores don't actually have to acknowledge this setting or maintain it as a hard limit.

===Overriding a cache loader===
This is a super advanced feature and should not be done. ever. Unless you have an very good reason to do so.
It allows you to create your own cache loader and have it be used instead of the default cache loader class. The cache object you get back from the make operations will be an instance of this class.

; overrideclass : [string] A class to use as the loader for this cache. This is an advanced setting and will allow the developer of the definition to take 100% control of the caching solution.<br />Any class used here must inherit the cache_loader interface and must extend default cache loader for the mode they are using.
; overrideclassfile : [string] Suplements the above setting indicated the file containing the class to be used. This file is included when required.

===Specifying a data source===
This is a great wee feature, especially if your code is object orientated.<br />
It allows you to specify a class that must inherit the cache_data_source object and will be used to load any information requested from the cache that is not already being stored.<br />
When the requested key cannot be found in the cache the data source will be asked to load it. The data source will then return the information to the cache, the cache will store it, and it will then return it to the user as a request of their get request. Essentially no get request should ever fail if you have a data source specified.

; datasource : [string] A class to use as the data loader for this definition.<br />Any class used here must inherit the cache_data_loader interface.
; datasourcefile : [string] Suplements the above setting indicated the file containing the class to be used. This file is included when required.

===Misc settings===
The following are stand along settings that don't fall into any of the above categories.

; invalidationevents : [array] An array of events that should cause this cache to invalidate some or all of the items within it.
; mappingsonly : [bool] If set to true only the mapped cache store(s) will be used and the default mode store will not. This is a super advanced setting and should not be used unless absolutely required. It allows you to avoid the default stores for one reason or another.
; sharingoptions : [int] The sharing options that are appropriate for this definition. Should be the sum of the possible options.
; defaultsharing : [int] The default sharing option to use. It's highly recommended that you don't set this unless there is a very specific reason not to use the system default.

==The loader==

==Using a data source==

==Developing cache plugins==

Cache API

2014-09-24T09:35:32Z

FMCorz: Adding language string requirements details

This document details the Cache API aka MUC aka Moodle's Universal Cache.
I've chosen to use a tutorial/example flow for this document always working with a theoretical module plugin called myplugin.
There is also a [[Cache API - Quick reference]] if you would rather read that.

==Basic usage==
It's very easy to get started with the Cache API. It is designed to be as easy and as quick to use as possible and is predominantely self contained.
All you need to do is add a definition for your cache and you are ready to start working with the Cache API.

===Creating a definition===
Cache definitions exist within the db/caches.php file for a component/plugin.<br />
In the case of core that is the moodle/lib/db/caches.php file, in the case of a module that would be moodle/mod/myplugin/db/caches.php.

The definition is used API in order to understand a little about the cache and what it is being used for, it also allows the administrator to set things up especially for the definition if they want.
From a development point of view the definition allows you to tell the API about your cache, what it requires, and any (if any) advanced features you want it to have.<br />
The following shows a basic definition containing just the bare minimum:
<code php>
// moodle/mod/myplugin/db/caches.php
$definitions = array(
'somedata' => array(
'mode' => cache_store::MODE_APPLICATION
)
);
</code>
This informs the API that the myplugin module has a cache called ''somedata'' and that it is an application (globally shared) cache.<br />
When creating a definition thats the bare minimum, to provide an area ''(somedata)'' and declare the type of the cache application, session, or request.<br />
:An application cache is a shared cache, all users can access it.<br />
:Session caches are, well, just stores in the users session.<br />
:Request caches you can think of as static caches, only available to the user owning the request, and only alive until the end of the request.<br />
There are of course many more options available that allow you to really take the cache by the reigns, you can read about some of the important ones further on, or skip ahead to [[#The definition]] section which details the available options in full.

Please note that for each definition a language string with the name ''cachedef_'' followed by the name of the definition is expected. Using the example above you would have to define:

<code php>
$string['cachedef_somedata'] = 'This is the description of the cache somedata';
</code>

===Getting a cache object===
Once your definition has been created you should bump the version number so that Moodle upgrades and processes the definitions file at which point your definition will be useable.

Now within code you can get a cache object to interact with in the following manner.

<code php>
$cache = cache::make('mod_myplugin', 'mycache');
</code>

The cache::make method is a factory method, it will create a cache object to allow you to work with your cache. The cache object will be one of several classes chosen by the API based upon what your definition contains. All of these classes will extend the base cache class, and in nearly all cases you will get one of cache_application, cache_session, or cache_request depending upon the mode you selected.

===Using your cache object===
Once you have a cache object (will extend the cache class and implements cache_loader) you are ready to start interacting with the cache.

Of course there are three basic basic operations. get, set, and delete.

The first is to send something to the cache.
<code php>
$result = $cache->set('key', 'value');
</code>
Easy enough. The key must an int or a string. The value can be absolutely anything your want.
The result is true if the operation was a success, false otherwise.

The second is to fetch something from the cache.
<code php>
$data = $cache->get('key');
</code>
$data will either be what ever was being stored in the cache, or false if the cache could not find the key.

The third and final operation is delete.
<code php>
$result = $cache->delete('key');
</code>
Again just like set the result will either be true if the operation was a success, or false otherwise.

You can also set, get, and delete multiple key=>value pairs in a single transaction.
<code php>
$result = $cache->set_many(array(
'key1' => 'data1',
'key3' => 'data3'
));
// $result will be the number of pairs sucessfully set.

$result = $cache->get_many(array('key1', 'key2', 'key3'));
print_r($result);
// Will print the following:
// array(
// 'key1' => 'data1',
// 'key2' => false,
// 'key3' => 'data3'
// )

$result = $cache->delete_many(array('key1', 'key3');
// $result will be the number of records sucessfully deleted.
</code>

That covers the basic operation of the Cache API.<br />
In many situations there is not going to be any more to it than that.

==Ad-hoc Caches==
This is the alternative method of using the cache API.<br />
It involves creating a cache using just the required params at the time that it is required. It doesn't require that a definition exists making it quicker and easier to use, however it can only use the default settings and is only recommended for insignificant caches (rarely used during operation, never to be mapped or customised, only existsing in a single place in code).

Once a cache object has been retrieved it operates exactly as the same as a cache that has been created for a definition.

To create an ad-hoc cache you would use the following:
<code php>
$cache = cache::make_from_params(cache_store::MODE_APPLICATION, 'mod_myplugin', 'mycache');
</code>

Really don't be lazy, if you don't have a good reason to use an ad-hoc cache you should be spending a extra 5 minutes creating a definition.

==The definition==

The above section illustrated how to create a basic definition, specifying just the area name (the key) and the mode for the definition. Those being the two required properties for a definition.<br />
There are many other options that will let you make the most of the Cache API and will undoubtedly be required when implementing and converting cache solutions to the Cache API.

The following details the options available to a definition and their defaults if not applied:

<code php>
$definitions = array(
// The name of the cache area is the key. The component/plugin will be picked up from the file location.
'area' => array(
'mode' => cache_store::MODE_*,
'simplekeys' => false,
'simpledata' => false,
'requireidentifiers' => array('ident1', 'ident2'),
'requiredataguarantee' => false,
'requiremultipleidentifiers' => false,
'requirelockingread' => false,
'requirelockingwrite' => false,
'maxsize' => null,
'overrideclass' => null,
'overrideclassfile' => null,
'datasource' => null,
'datasourcefile' => null,
'staticacceleration' => false,
'staticaccelerationsize' => null,
'ttl' => 0,
'mappingsonly' => false,
'invalidationevents' => array('event1', 'event2'),
'sharingoptions' => cache_definition::SHARING_DEFAULT,
'defaultsharing' => cache_definition::SHARING_DEFAULT,
)
);
</code>

===Setting requirements===
The definition can specify several requirements for the cache.<br />
This includes identifiers that must be provided when creating the cache object, that the store guarantees data stored in it will remain there until removed, a store that supports multiple identifiers, and finally read/write locking.
The options for these are as follows:

; simplekeys : [bool] Set to true if your cache will only use simple keys for its items.<br />Simple keys consist of digits, underscores and the 26 chars of the english language. a-zA-Z0-9_<br />If true the keys won't be hashed before being passed to the cache store for gets/sets/deletes. It will be better for performance and possible only because we know the keys are safe.
; simpledata : [bool] If set to true we know that the data is scalar or array of scalar.
; requireidentifiers : [array] An array of identifiers that must be provided to the cache when it is created.
; requiredataguarantee : [bool] If set to true then only stores that can guarantee data will remain available once set will be used.
; requiremultipleidentifiers : [bool] If set to true then only stores that support multiple identifiers will be used.
; requirelockingread : [bool] If set to true then a lock will be gained before reading from the cache store. It is recommended not to use this setting unless 100% absolutely positively required.<br />Remember 99.9% of caches will NOT need this setting.<br />This setting will only be used for application caches presently.
; requirelockingwrite : [bool] If set to true then a lock will be gained before writing to the cache store. As above this is not recommended unless truly needed. Please think about the order of your code and deal with race conditions there first.<br />This setting will only be used for application caches presently.

===Cache modifiers===
You are also to modify the way in which the cache is going to operate when working for your definition.<br />
By enabling the static option the Cache API will only ever generate a single cache object for your definition on the first request for it, further requests will be returned the original instance.<br />This greatly speeds up the collecting of a cache object.<br />
Enabling persistence also enables a static store within the cache object, anything set to the cache, or retrieved from it will be stored in that static array for the life of the request.
This makes the persistence options some of the most powerful. If you know you are going to be using you cache over and over again or if you know you will be making lots of requests for the same items then this will provide a great performance boost.
Of course the static storage of cache objects and of data is costly in terms of memory and should only be used when actually required, as such it is turned off by default.
As well as persistence you can also set a maximum number of items that the cache should store (not a hard limit, its up to each store) and a time to live (ttl) although both are discouraged as efficient design negates the need for both in most situations.

; staticacceleration : [bool] This setting does two important things. First it tells the cache API to only instantiate the cache structure for this definition once, further requests will be given the original instance.<br />Second the cache loader will keep an array of the items set and retrieved to the cache during the request.<br />This has several advantages including better performance without needing to start passing the cache instance between function calls, the downside is that the cache instance + the items used stay within memory.<br />Consider using this setting when you know that there are going to be many calls to the cache for the same information or when you are converting existing code to the cache and need to access the cache within functions but don't want to add it as an argument to the function.
; staticaccelerationsize : [int] This supplements the above setting by limiting the number of items in the caches persistent array of items.<br />Tweaking this setting lower will allow you to minimise the memory implications above while hopefully still managing to offset calls to the cache store.
; ttl : [int] A time to live for the data (in seconds). It is strongly recommended that you don't make use of this and instead try to create an event driven invalidation system (even if the event is just time expiring, better not to rely on ttl).<br />Not all cache stores will support this natively and there are undesired performance impacts if the cache store does not.
; maxsize : [int] If set this will be used as the maximum number of entries within the cache store for this definition.<br />Its important to note that cache stores don't actually have to acknowledge this setting or maintain it as a hard limit.

===Overriding a cache loader===
This is a super advanced feature and should not be done. ever. Unless you have an very good reason to do so.
It allows you to create your own cache loader and have it be used instead of the default cache loader class. The cache object you get back from the make operations will be an instance of this class.

; overrideclass : [string] A class to use as the loader for this cache. This is an advanced setting and will allow the developer of the definition to take 100% control of the caching solution.<br />Any class used here must inherit the cache_loader interface and must extend default cache loader for the mode they are using.
; overrideclassfile : [string] Suplements the above setting indicated the file containing the class to be used. This file is included when required.

===Specifying a data source===
This is a great wee feature, especially if your code is object orientated.<br />
It allows you to specify a class that must inherit the cache_data_source object and will be used to load any information requested from the cache that is not already being stored.<br />
When the requested key cannot be found in the cache the data source will be asked to load it. The data source will then return the information to the cache, the cache will store it, and it will then return it to the user as a request of their get request. Essentially no get request should ever fail if you have a data source specified.

; datasource : [string] A class to use as the data loader for this definition.<br />Any class used here must inherit the cache_data_loader interface.
; datasourcefile : [string] Suplements the above setting indicated the file containing the class to be used. This file is included when required.

===Misc settings===
The following are stand along settings that don't fall into any of the above categories.

; invalidationevents : [array] An array of events that should cause this cache to invalidate some or all of the items within it.
; mappingsonly : [bool] If set to true only the mapped cache store(s) will be used and the default mode store will not. This is a super advanced setting and should not be used unless absolutely required. It allows you to avoid the default stores for one reason or another.
; sharingoptions : [int] The sharing options that are appropriate for this definition. Should be the sum of the possible options.
; defaultsharing : [int] The default sharing option to use. It's highly recommended that you don't set this unless there is a very specific reason not to use the system default.

==The loader==

==Using a data source==

==Developing cache plugins==