MoodleDocs - User contributions [en]

Progress Bar

2017-08-29T08:51:21Z

Johnok: Update usage of update function

= Progress Bar Lib =
There are two Progress Bar libs avaiable in Moodle, the old one and a OOP one.

== Old Progress Bar ==
<code php>
function print_progress($done, $total, $updatetime=5, $sleeptime=1, $donetext='')
</code>
== OOP Progress Bar ==

Usage:
<code php>
set_time_limit(0);
$pb = new progressbar('bar', 500);
$pb->create();
$num_tasks = 200; // the number of tasks to be completed.
for($cur_task = 0; $cur_task <= $num_tasks; $cur_task++)
{
for ($i=0; $i<100000; $i++)
{
;;;
}
$pb->update($cur_task, $num_tasks, 'this is'. $cur_task . 'h');
}
?>
<hr/>
<?php
$pt = new progressbar('zbar', 900);
$pt->create();
$num_tasks = 200; // the number of tasks to be completed.
for($cur_task = 0; $cur_task <= $num_tasks; $cur_task++)
{
for ($i=0; $i<100000; $i++)
{
;;;
}
$pt->update($cur_task, $num_tasks, 'this is'. $cur_task . 'h');
}
</code>

Talk:LTI ContentItem Enhancements

2017-07-25T00:21:29Z

Johnok: Initial thoughts about the proposal

Thanks! These proposals make sense and will be great improvements. I wish we could avoid another checkbox for the content item flow. I wonder if it's too bad to just always skip the edit page for anything that supports it? But yeah I suppose the setting is the safer choice. I'd like more info and maybe mockups for how the adding multiple links at once will work. --[[User:John Okely|John Okely]] ([[User talk:John Okely|talk]]) 08:21, 25 July 2017 (AWST)

Peer reviewing

2017-06-02T01:37:27Z

Johnok: Ask for more detail about why certain performance decisions were made

=Process=

Peer review process helps to prepare the issue for integration. The peer reviewer is another developer who was not involved in the development process on the issue and therefore can take a fresh look and notice something that original developer might have forgotten during development. It is important to check that the bug actually is present and the code fixes it without creating new regressions.

==Completing Peer review as a community member==

Any other developer can review any change. That is why it is called 'peer' review. However, not everyone has the necessary permissions in the tracker to click the buttons 'Start peer review', 'Finish peer review' etc. This should not discourage you from looking at other contributors code and providing comments and feedback. The issue will still need to wait for someone with the right permissions to come along and click the buttons, but they can read your review and then need do no more than double-check some points, which will save a lot of time.

To provide feedback to the developer, leave the issue in "Waiting for Peer Review" (since you don't have permission to do anything else, and also that makes it easy for someone with sufficient permissions to find the issue and move it forwards). Review the code using the checklist below, including any appropriate comments. Once finished, please post a comment clearly stating the outcome of your review. If you think it needs more work then indicate what needs to be changes. If you are happy with the patch, leave a clear comment that you believe this is ready to be made part of Moodle. This can then easily be seen by a HQ developer or component lead and they can quickly take appropriate action.

If a followup review happens to identify something you did not find, you have an opportunity to expand your knowledge and provide better reviews in the future as well as having saved everybody else some time.

Feedback to indicate the issue is ready to progress might look like the following;
<p class="note">
Thanks again for your contribution. I have reviewed the patch:
<br><br>
[Copy and paste the checklist here, and complete it]
<br><br>
I don't have permission to use the peer review buttons on this issue. I hope that someone with sufficient permissions will move the issue forwards soon.
</p>

Feedback to indicate the issue requires further work might look like the following;
<p class="note">
Thanks for providing a patch. I think the following points require further work
<br><br>
[Copy and paste the checklist here, and complete it]
<br><br>
Please indicate If you are willing to continue working on this issue and complete the solution.
</p>

==Peer review for development by HQ or a known common contributor==

When code comes from a HQ developer or external developer who has been contributing significantly to Moodle and is well acquainted with Moodle standards, peer review is limited to checking the code according to the Checklist below.

If everything is fine, the peer reviewer submits the issue for integration.

If some additional work is needed or the author specifically asked not to submit for integration yet, the peer reviewer clicks on “Finish peer review” and the issue state returns to “Development in progress”. Usually the name of the peer reviewer stays on the issue and if a second peer review is requested it is expected that the same Peer reviewer picks it up. If the peer reviewer is not able to do the second review, they should remove their name and comment about it. Otherwise the issue does not appear on “waiting for peer review” dashboard. Please remember that not all jira users have permission to submit for integration.

==Peer review for external developers==

When the code has come from an external developer, the peer reviewer will also help the developer to lead the issue to integration. In this case the peer reviewer should not use “Finish peer review” button.

If the issue needs additional work, the peer reviewer comments about the suggested changes but does not change the status of the issue and it remains as “Peer review in progress”. If the author of the patch does not reply in 4 days, the peer reviewer may select either to complete the patch themselves or reopen the issue. The decision should be based on the amount of work required to complete the solution, for example, changing coding style or commit message, rebasing, backporting, adding testing instructions, etc. should be performed by the peer reviewer. This may require picking the commits into reviewer’s git branch.

It is very important to give the credit to the author of the code by either keeping their authorship on the commit or adding “Thanks to XXXX for providing the patch” to the commit message. If the author of the patch is not in jira-developers group the special user 'moodle.com' should be entered in Assignee field.

There could be situations when the patch is incomplete, does not fix the original issue, creates regressions or otherwise is not correct. As stated above, the peer reviewer should comment about it and wait for the feedback from the author. If there is no feedback, or the author can not work on this issue any more, and the peer reviewer also does not find it easy and important enough to complete, the issue needs to be reopened. Button “Fail peer review” (available to HQ developers only) will reset the issue status to “Reopened”. On this screen peer reviewer should remove assignee, peer reviewer and “patch” label from the issue. This way issue will become available again for anybody who want to work on it. All communication will remain in comments and issue history.

If the issue has passed peer review but the integrator or tester has raised some questions about it, then normally the developer who created the patch would be expected to respond. If they do no respond quickly enough, then the peer reviewer is expected to step in and take responsibility for the change they reviewed.

Once the issue is ready for integration, you can submit it to integration on behalf of the developer. Most external developers (those who are not in the jira-developers group) do not have permission to submit their own issues to integration so cannot do it themselves.

==Replies templates==

<p class="note">
Thanks for providing a patch.<br/>
I have reviewed your code and can confirm that it addresses the reported issue. We would like to include it in core. Moodle values its contributors and tries to give them credit when possible. If you are interested in your name appearing on the https://moodle.org/dev/contributions.php page you can create a git commit that we will then pull into Moodle. You can learn more about Git and how Moodle uses it at <nowiki>[Git for developers|https://docs.moodle.org/dev/Git_for_developers]</nowiki> page. Please let me know if you want to prepare a git branch. Or if you don’t have time to go through the whole process at the moment I can pick your patch myself.
</p>

<p class="note">
Thanks for providing a patch.<br/>
Your code looks almost ready for integration into Moodle. There are just some little things that need to be changed to comply with Moodle standards. Can you please take a look at the review results below and tell me if you are able to modify your branch to address them.
</p>

<p class="note">
I have reviewed your patch, it addresses the problem and complies with Moodle standards. I'm pushing this issue for integration. Following Moodle <nowiki>[Process|https://docs.moodle.org/dev/Process]</nowiki> it will go through integration review and testing before being included in the product. There might be additional questions from an integrator and/or a tester at those stages. It would be appreciated if you read tracker emails and can reply to questions if needed. If everything goes well during the next two stages your issue will be included in the next weekly release and your count on https://moodle.org/dev/contributions.php page will increase.<br/>
Thanks again for your contribution.
</p>

<p class="note">
Thanks for providing a patch.<br/>
Unfortunately this patch does not fully address the reported issue. ... DETAILS...<br/><br/>
Even though the code does solve the issue in the short-term it is very likely to create regressions ..... <br/><br/>
I have spent some time reviewing the patch and I would recommend that you ..... <br/><br/>
Please let me know If you are willing to continue working on this issue and complete the solution.
</p>

=Checklist=

These are points to consider while peer-reviewing issues. Further explanation below.

[] Syntax
[] Whitespace
[] Output
[] Language
[] Databases
[] Testing (instructions and automated tests)
[] Security
[] Performance and Clustering
[] Documentation
[] Git
[] Third party code
[] Sanity check
[] Icons

Acceptable check-marks are Y (for yes), N (for no) or - (for not applicable). All N check-marks should be accompanied by an explanation of the problem that still needs to be addressed.

==Syntax==
To allow the community of Moodle developers to work together, conventions should be followed.

* The code is easy to understand and, where it isn't, comments have been provided.
* Variables are named correctly (all lower case, no camel-case, no underscores).
* Functions are named correctly (all lower case, no camel-case, underscores allowed).
* PHP DocBlocks have been updated and adhere to [[Coding_style#Documentation_and_comments|coding style guide]].
* Where functions are being removed, the [[Deprecation]] process is followed.
* The code doesn't use [[Deprecated_functions_in_2.0|deprecated functions]].
* $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used.

See the [[Coding style]] guide for details.

==Whitespace==
Unnecessary whitespace changes can cause conflicts when committing code.

Ensure that:
* there are no unnecessary blank lines in the new code;
* blank lines do not contain spaces;
* there are no unnecessary changes to whitespace in other areas on the file;

==Output==
Output needs to be controlled by renderers to achieve consistency and correct application of themes.

Ensure that:
* output renders are used to generate output strings, including HTML tags;
* HTML output is valid XHTML;
* no inline styles have been used in HTML output (everything has to be in CSS);
* CSS has been added to the appropriate CSS files (base, specific area, sometimes canvas); and
* the code doesn't use buffered output unless absolutely necessary.
* all visual output has a RTL alternative included

feedback any notices (E_STRICT, etc) seen into the MDL.

==Language==
To achieve appropriate internationalisation of Moodle, language strings must be managed correctly.

Ensure that:
* new language strings are named correctly (all lower case, no camel-case, underscores are permissible in some cases);
* help strings are named and formatted as described in [[Help strings]];
* language strings are used instead of hard-coded strings for text output;
* language strings have not been removed or renamed, had their meaning changed or had their parameters changed in stable branches (permitted only in master); and
* [https://docs.moodle.org/dev/Commit_cheat_sheet#Include_AMOS_script_in_the_commit_if_needed AMOS commands] have been specified when moving or copying language strings.

==Databases==
DB calls are the greatest performance bottleneck in Moodle.

If there is SQL code you can test quickly then do so.

Ensure that:
* there are minimal DB calls (no excessive use of the DB); and
* the code uses SQL compatible with all the supported DB engines (check all selected fields appear in an 'order by' clause).

==Testing instructions and automated tests==
It is the developer's responsibility to test code before integration. Issues should not be sent for peer review without tests so that the peer reviewer can assess their quality and use them to consider the scope of the issue.

Ensure that:
* there are specific testing instructions that state how, as well as what, to test. Please ensure that the testing instructions are in the correct format: [https://docs.moodle.org/dev/Behat Behat gherkin];
* new unit tests have been added when there is a change in functionality; and
* '''unit tests pass''' for related areas where changes have been made.
* '''Behat tests pass''' for related areas where changes have been made, especially when it involved UI changes.

==Security==
The user community relies on Moodle being responsibly secure.

Ensure that:
* user login is checked where an identity is needed;
* sesskey values are checked before all write actions where appropriate (some read actions as well);
* capabilities are checked where roles differ; and
* if the issue itself is a [[Security|security]] issue, the [[Process#Security_issues|security process]] is being followed.
** Ensure that the fix is '''not''' available in a public repository (ie. a personal Github account); stand-alone patches should be provided instead.
** The issue will not be integrated until just before the next minor version release.

==Performance and clustering==
It is easy to write code that works sufficiently well when you are working on either small sets of data or with a small number of active users. Picking performance issues can be quite difficult and can required a complex level of understanding of both the section of code being reviewed, but also other parts that interact with it.

Clustering is when the same code is run on different computers and an end user could send each request to a different computer. This can produce a number of concurrency issues if not thought through. One example is; If you complete an opcache_reset(), no other server except the one you ran it on knows that it happened. So data can get out of sync.

Ensure that:
* Any filesystem, database or cache accesses are done in the most efficient way.
* That any code or function that appear expensive are not in critical paths. eg; They don't load on every page.
* The least possible code is running to complete the task, especially looking for hidden loops. They can appear from calling functions.
* Any code that runs is not specific to a single node. (eg opcache_reset()) The ensures clusters will run correctly.
* If the code could affect performance at all, make sure there is a comment noting what was considered.
** What they did to mitigate performance impact, or why they thought it wasn't an issue.
** Why they made certain trade-offs.

==Documentation==
Work does not stop when code is integrated.

Ensure that:
* Appropriate [[Tracker_issue_labels|labels]] have been added when there has been a function change, particularly
** docs_required (any functional change, usually paired with ui_change),
** dev_docs_required (any change to APIs, usually paired with api_change),
** ui_change (any functional change, usually paired with docs_required, except ui_change remains permanetly),
** api_change (any change to APIs that devs will need to know about, usually paired with dev_docs_required, except api_change remains permanetly),
** unit_test_required and acceptance_test_required, when there are api or ui changes needing improved coverage, and
** qa_test_required (significant functional change, not covered by unit/acceptance ones).
* Also, verify that the components for the issue are correctly set, so maintainers (subscribed by default) will be mailed about issues early in the process.

==Git==
Ensure that:
* the commit matches the [[Coding style#Git_commits|Coding style]]
* the Git history is clean and the work has been rebased to logical commits; and
* the original author of the work provided as a patch has been given credit within the commit (as author of in the commit message if changes were made).

==Third party code==
Does the change contain third party code? If so, ensure that:

* The code is licensed under a [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses| GPL compatible license].
* The instructions for upgrading/importing the library and contained within a readme_moodle.txt file.
* The library is recorded in a thirdparty.xml file, including licensing information.
* Third party code has been scanned to check for url accessible entry points that could be exploited. These should either be disabled, or if required functionality they should be checked for security weaknesses.
* Does not duplicate the functionality of any existing api or third party library in core.
* Any modifications to third party code are recorded in readme_moodle.txt

==Sanity check==
Ensure that:
* the code seems to solve the described problem completely within its reported scope (and further issues have been created to resolve remaining parts or further refactoring);
* the code makes sense in relation to the broader codebase (look at the whole function, not just the altered code); and
* the developer has searched for and fixed other areas that may also have been affected by the same problem.
* if any version numbers have been changed in [[version.php]] files, then the changes follow [[Moodle_versions#How_to_increment_version_numbers_in_core|the rule for updating version numbers in core]].
* there are comments on tracker explaining why current approach was taken and why other options (especially large issues). If not comment asking them to explain

==Icons==
Are new icons being introduced? If so, ensure that:
* the icons abide by our [https://docs.moodle.org/dev/Moodle_icons icon guidelines] with regards to size, design and format
* the icons are do not unnecessarily add new ways of expressing existing concepts
* the icons are in a pix folder that makes sense

==See Also==
* [http://moodle.org/plugins/view.php?plugin=local_codechecker Code checker plugin]

Peer reviewing

2017-06-02T01:35:16Z

Johnok: Add note about decision explanations to sanity check

=Process=

Peer review process helps to prepare the issue for integration. The peer reviewer is another developer who was not involved in the development process on the issue and therefore can take a fresh look and notice something that original developer might have forgotten during development. It is important to check that the bug actually is present and the code fixes it without creating new regressions.

==Completing Peer review as a community member==

Any other developer can review any change. That is why it is called 'peer' review. However, not everyone has the necessary permissions in the tracker to click the buttons 'Start peer review', 'Finish peer review' etc. This should not discourage you from looking at other contributors code and providing comments and feedback. The issue will still need to wait for someone with the right permissions to come along and click the buttons, but they can read your review and then need do no more than double-check some points, which will save a lot of time.

To provide feedback to the developer, leave the issue in "Waiting for Peer Review" (since you don't have permission to do anything else, and also that makes it easy for someone with sufficient permissions to find the issue and move it forwards). Review the code using the checklist below, including any appropriate comments. Once finished, please post a comment clearly stating the outcome of your review. If you think it needs more work then indicate what needs to be changes. If you are happy with the patch, leave a clear comment that you believe this is ready to be made part of Moodle. This can then easily be seen by a HQ developer or component lead and they can quickly take appropriate action.

If a followup review happens to identify something you did not find, you have an opportunity to expand your knowledge and provide better reviews in the future as well as having saved everybody else some time.

Feedback to indicate the issue is ready to progress might look like the following;
<p class="note">
Thanks again for your contribution. I have reviewed the patch:
<br><br>
[Copy and paste the checklist here, and complete it]
<br><br>
I don't have permission to use the peer review buttons on this issue. I hope that someone with sufficient permissions will move the issue forwards soon.
</p>

Feedback to indicate the issue requires further work might look like the following;
<p class="note">
Thanks for providing a patch. I think the following points require further work
<br><br>
[Copy and paste the checklist here, and complete it]
<br><br>
Please indicate If you are willing to continue working on this issue and complete the solution.
</p>

==Peer review for development by HQ or a known common contributor==

When code comes from a HQ developer or external developer who has been contributing significantly to Moodle and is well acquainted with Moodle standards, peer review is limited to checking the code according to the Checklist below.

If everything is fine, the peer reviewer submits the issue for integration.

If some additional work is needed or the author specifically asked not to submit for integration yet, the peer reviewer clicks on “Finish peer review” and the issue state returns to “Development in progress”. Usually the name of the peer reviewer stays on the issue and if a second peer review is requested it is expected that the same Peer reviewer picks it up. If the peer reviewer is not able to do the second review, they should remove their name and comment about it. Otherwise the issue does not appear on “waiting for peer review” dashboard. Please remember that not all jira users have permission to submit for integration.

==Peer review for external developers==

When the code has come from an external developer, the peer reviewer will also help the developer to lead the issue to integration. In this case the peer reviewer should not use “Finish peer review” button.

If the issue needs additional work, the peer reviewer comments about the suggested changes but does not change the status of the issue and it remains as “Peer review in progress”. If the author of the patch does not reply in 4 days, the peer reviewer may select either to complete the patch themselves or reopen the issue. The decision should be based on the amount of work required to complete the solution, for example, changing coding style or commit message, rebasing, backporting, adding testing instructions, etc. should be performed by the peer reviewer. This may require picking the commits into reviewer’s git branch.

It is very important to give the credit to the author of the code by either keeping their authorship on the commit or adding “Thanks to XXXX for providing the patch” to the commit message. If the author of the patch is not in jira-developers group the special user 'moodle.com' should be entered in Assignee field.

There could be situations when the patch is incomplete, does not fix the original issue, creates regressions or otherwise is not correct. As stated above, the peer reviewer should comment about it and wait for the feedback from the author. If there is no feedback, or the author can not work on this issue any more, and the peer reviewer also does not find it easy and important enough to complete, the issue needs to be reopened. Button “Fail peer review” (available to HQ developers only) will reset the issue status to “Reopened”. On this screen peer reviewer should remove assignee, peer reviewer and “patch” label from the issue. This way issue will become available again for anybody who want to work on it. All communication will remain in comments and issue history.

If the issue has passed peer review but the integrator or tester has raised some questions about it, then normally the developer who created the patch would be expected to respond. If they do no respond quickly enough, then the peer reviewer is expected to step in and take responsibility for the change they reviewed.

Once the issue is ready for integration, you can submit it to integration on behalf of the developer. Most external developers (those who are not in the jira-developers group) do not have permission to submit their own issues to integration so cannot do it themselves.

==Replies templates==

<p class="note">
Thanks for providing a patch.<br/>
I have reviewed your code and can confirm that it addresses the reported issue. We would like to include it in core. Moodle values its contributors and tries to give them credit when possible. If you are interested in your name appearing on the https://moodle.org/dev/contributions.php page you can create a git commit that we will then pull into Moodle. You can learn more about Git and how Moodle uses it at <nowiki>[Git for developers|https://docs.moodle.org/dev/Git_for_developers]</nowiki> page. Please let me know if you want to prepare a git branch. Or if you don’t have time to go through the whole process at the moment I can pick your patch myself.
</p>

<p class="note">
Thanks for providing a patch.<br/>
Your code looks almost ready for integration into Moodle. There are just some little things that need to be changed to comply with Moodle standards. Can you please take a look at the review results below and tell me if you are able to modify your branch to address them.
</p>

<p class="note">
I have reviewed your patch, it addresses the problem and complies with Moodle standards. I'm pushing this issue for integration. Following Moodle <nowiki>[Process|https://docs.moodle.org/dev/Process]</nowiki> it will go through integration review and testing before being included in the product. There might be additional questions from an integrator and/or a tester at those stages. It would be appreciated if you read tracker emails and can reply to questions if needed. If everything goes well during the next two stages your issue will be included in the next weekly release and your count on https://moodle.org/dev/contributions.php page will increase.<br/>
Thanks again for your contribution.
</p>

<p class="note">
Thanks for providing a patch.<br/>
Unfortunately this patch does not fully address the reported issue. ... DETAILS...<br/><br/>
Even though the code does solve the issue in the short-term it is very likely to create regressions ..... <br/><br/>
I have spent some time reviewing the patch and I would recommend that you ..... <br/><br/>
Please let me know If you are willing to continue working on this issue and complete the solution.
</p>

=Checklist=

These are points to consider while peer-reviewing issues. Further explanation below.

[] Syntax
[] Whitespace
[] Output
[] Language
[] Databases
[] Testing (instructions and automated tests)
[] Security
[] Performance and Clustering
[] Documentation
[] Git
[] Third party code
[] Sanity check
[] Icons

Acceptable check-marks are Y (for yes), N (for no) or - (for not applicable). All N check-marks should be accompanied by an explanation of the problem that still needs to be addressed.

==Syntax==
To allow the community of Moodle developers to work together, conventions should be followed.

* The code is easy to understand and, where it isn't, comments have been provided.
* Variables are named correctly (all lower case, no camel-case, no underscores).
* Functions are named correctly (all lower case, no camel-case, underscores allowed).
* PHP DocBlocks have been updated and adhere to [[Coding_style#Documentation_and_comments|coding style guide]].
* Where functions are being removed, the [[Deprecation]] process is followed.
* The code doesn't use [[Deprecated_functions_in_2.0|deprecated functions]].
* $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used.

See the [[Coding style]] guide for details.

==Whitespace==
Unnecessary whitespace changes can cause conflicts when committing code.

Ensure that:
* there are no unnecessary blank lines in the new code;
* blank lines do not contain spaces;
* there are no unnecessary changes to whitespace in other areas on the file;

==Output==
Output needs to be controlled by renderers to achieve consistency and correct application of themes.

Ensure that:
* output renders are used to generate output strings, including HTML tags;
* HTML output is valid XHTML;
* no inline styles have been used in HTML output (everything has to be in CSS);
* CSS has been added to the appropriate CSS files (base, specific area, sometimes canvas); and
* the code doesn't use buffered output unless absolutely necessary.
* all visual output has a RTL alternative included

feedback any notices (E_STRICT, etc) seen into the MDL.

==Language==
To achieve appropriate internationalisation of Moodle, language strings must be managed correctly.

Ensure that:
* new language strings are named correctly (all lower case, no camel-case, underscores are permissible in some cases);
* help strings are named and formatted as described in [[Help strings]];
* language strings are used instead of hard-coded strings for text output;
* language strings have not been removed or renamed, had their meaning changed or had their parameters changed in stable branches (permitted only in master); and
* [https://docs.moodle.org/dev/Commit_cheat_sheet#Include_AMOS_script_in_the_commit_if_needed AMOS commands] have been specified when moving or copying language strings.

==Databases==
DB calls are the greatest performance bottleneck in Moodle.

If there is SQL code you can test quickly then do so.

Ensure that:
* there are minimal DB calls (no excessive use of the DB); and
* the code uses SQL compatible with all the supported DB engines (check all selected fields appear in an 'order by' clause).

==Testing instructions and automated tests==
It is the developer's responsibility to test code before integration. Issues should not be sent for peer review without tests so that the peer reviewer can assess their quality and use them to consider the scope of the issue.

Ensure that:
* there are specific testing instructions that state how, as well as what, to test. Please ensure that the testing instructions are in the correct format: [https://docs.moodle.org/dev/Behat Behat gherkin];
* new unit tests have been added when there is a change in functionality; and
* '''unit tests pass''' for related areas where changes have been made.
* '''Behat tests pass''' for related areas where changes have been made, especially when it involved UI changes.

==Security==
The user community relies on Moodle being responsibly secure.

Ensure that:
* user login is checked where an identity is needed;
* sesskey values are checked before all write actions where appropriate (some read actions as well);
* capabilities are checked where roles differ; and
* if the issue itself is a [[Security|security]] issue, the [[Process#Security_issues|security process]] is being followed.
** Ensure that the fix is '''not''' available in a public repository (ie. a personal Github account); stand-alone patches should be provided instead.
** The issue will not be integrated until just before the next minor version release.

==Performance and clustering==
It is easy to write code that works sufficiently well when you are working on either small sets of data or with a small number of active users. Picking performance issues can be quite difficult and can required a complex level of understanding of both the section of code being reviewed, but also other parts that interact with it.

Clustering is when the same code is run on different computers and an end user could send each request to a different computer. This can produce a number of concurrency issues if not thought through. One example is; If you complete an opcache_reset(), no other server except the one you ran it on knows that it happened. So data can get out of sync.

Ensure that:
* Any filesystem, database or cache accesses are done in the most efficient way.
* That any code or function that appear expensive are not in critical paths. eg; They don't load on every page.
* The least possible code is running to complete the task, especially looking for hidden loops. They can appear from calling functions.
* Any code that runs is not specific to a single node. (eg opcache_reset()) The ensures clusters will run correctly.

==Documentation==
Work does not stop when code is integrated.

Ensure that:
* Appropriate [[Tracker_issue_labels|labels]] have been added when there has been a function change, particularly
** docs_required (any functional change, usually paired with ui_change),
** dev_docs_required (any change to APIs, usually paired with api_change),
** ui_change (any functional change, usually paired with docs_required, except ui_change remains permanetly),
** api_change (any change to APIs that devs will need to know about, usually paired with dev_docs_required, except api_change remains permanetly),
** unit_test_required and acceptance_test_required, when there are api or ui changes needing improved coverage, and
** qa_test_required (significant functional change, not covered by unit/acceptance ones).
* Also, verify that the components for the issue are correctly set, so maintainers (subscribed by default) will be mailed about issues early in the process.

==Git==
Ensure that:
* the commit matches the [[Coding style#Git_commits|Coding style]]
* the Git history is clean and the work has been rebased to logical commits; and
* the original author of the work provided as a patch has been given credit within the commit (as author of in the commit message if changes were made).

==Third party code==
Does the change contain third party code? If so, ensure that:

* The code is licensed under a [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses| GPL compatible license].
* The instructions for upgrading/importing the library and contained within a readme_moodle.txt file.
* The library is recorded in a thirdparty.xml file, including licensing information.
* Third party code has been scanned to check for url accessible entry points that could be exploited. These should either be disabled, or if required functionality they should be checked for security weaknesses.
* Does not duplicate the functionality of any existing api or third party library in core.
* Any modifications to third party code are recorded in readme_moodle.txt

==Sanity check==
Ensure that:
* the code seems to solve the described problem completely within its reported scope (and further issues have been created to resolve remaining parts or further refactoring);
* the code makes sense in relation to the broader codebase (look at the whole function, not just the altered code); and
* the developer has searched for and fixed other areas that may also have been affected by the same problem.
* if any version numbers have been changed in [[version.php]] files, then the changes follow [[Moodle_versions#How_to_increment_version_numbers_in_core|the rule for updating version numbers in core]].
* there are comments on tracker explaining why current approach was taken and why other options (especially large issues). If not comment asking them to explain

==Icons==
Are new icons being introduced? If so, ensure that:
* the icons abide by our [https://docs.moodle.org/dev/Moodle_icons icon guidelines] with regards to size, design and format
* the icons are do not unnecessarily add new ways of expressing existing concepts
* the icons are in a pix folder that makes sense

==See Also==
* [http://moodle.org/plugins/view.php?plugin=local_codechecker Code checker plugin]

PHPUnit

2017-05-24T06:32:02Z

Johnok: Document LDAPLIB constants

{{Moodle 2.3}}

=What is PHPUnit=
PHPUnit by Sebastian Bergmann is an advanced unit testing framework for PHP. It is installed as Composer dependency and is not part of Moodle installation. To run PHPUnit tests, you have to manually install it on your development computer or test server.

Read the excellent guide at
* [http://phpunit.de/manual/current/en/index.html PHPUnit Manual]

=Installation of PHPUnit via Composer=

Windows may require additional installation steps.
On Windows go to https://getcomposer.org/download/ and download the Composer-Setup.exe file

* Execute Composer installer

cd /your/moodle/dirroot
php composer.phar install

(If that gives you connection problems try...)

php composer.phar install --prefer-source

Troubleshooting:
* On Windows if you are behind a proxy you will need to setup an environment variable called HTTP_PROXY with a value detailing your HTTP Proxy address and port before composer will correctly download files.
* You may be prompted for github credentials when installing composer dependencies.
** This is used to generate an personal access token to avoid being rate limited by github.
** If you have Two Factor Authentication enabled on your github account, or do not wish to supply your own credentials you will need to generate a token manually:
*** Visit https://github.com/settings/applications and request personal access token
*** Copy this token and add it to your [https://gist.github.com/andrewnicols/c5377ed25a9df1006ce1 ~/.composer/config.json]
** ( See [https://github.com/composer/composer/issues/2280 composer issue #2280] for further details of this bug.)

Detailed instructions:
* [http://getcomposer.org/doc/00-intro.md Composer documentation]

Detailed instructions:
* [[PHPUnit installation in Windows]]
* [[PHPUnit installation in OS X]]

== Uninstalling previous PEAR based version ==

Before using composer, this page used to suggest to install phpunit via PEAR. If you did so, you may wish to uninstall that package now. This should work:

$ pear uninstall phpunit/DbUnit
$ pear uninstall phpunit/PHPUnit

=Initialisation of test environment=

Our PHPUnit integration requires a dedicated database and dataroot. First, add a new dataroot directory and prefix into your config.php, you can find examples in config-dist.php (scroll down to 'Section 9').

$CFG->phpunit_prefix = 'phpu_';
$CFG->phpunit_dataroot = '/home/example/phpu_moodledata';

Some PHPUnit tests require a live internet connection. If your system does not have a direct connection to the Internet, you also need to specify your proxy in config.php - even though you normally specify it by using the admin settings user interface. (If you do not use a proxy, you can skip this step.) Check the settings on the relevant admin settings page, or from the mdl_config table in your database, if you are unsure of the correct values.

// Normal proxy settings
$CFG->proxyhost = 'wwwcache.example.org';
$CFG->proxyport = 80;
$CFG->proxytype = 'HTTP';
$CFG->proxybypass = 'localhost, 127.0.0.1, .example.org';
// Omit the next lines if your proxy doesn't need a username/password:
$CFG->proxyuser = 'systemusername';
$CFG->proxypassword = 'systempassword';

From Moodle 2.8.5 onwards, you can also provide specific database settings for unit testing (if these are not provided, the standard database settings will be used):

<pre>$CFG->phpunit_dbtype = 'pgsql'; // 'pgsql', 'mariadb', 'mysqli', 'mssql', 'sqlsrv' or 'oci'
$CFG->phpunit_dblibrary = 'native'; // 'native' only at the moment
$CFG->phpunit_dbhost = '127.0.0.1'; // eg 'localhost' or 'db.isp.com' or IP
$CFG->phpunit_dbname = 'mytestdb'; // database name, eg moodle
$CFG->phpunit_dbuser = 'postgres'; // your database username
$CFG->phpunit_dbpass = 'some_password'; // your database password</pre>

Then you need to initialise the test environment using following command.

cd /home/example/moodle
php admin/tool/phpunit/cli/init.php

This command has to be repeated after any upgrade, plugin (un)installation or if you have added tests to a plugin you are developing:

'''NOTE:''' make sure that your php cli executable (or the one you want to use) is correctly on your path as the individual init scripts will call it repeatedly. Also, ensure en_AU locale is installed on your server.

== LDAP ==
If you want to run LDAP unit tests you must have a working, configured LDAP environment on your test server. There must be a basic LDAP tree structure in place or tests will fail with "Search: No such object". Build an LDAP tree structure in a new shell prompt:

<pre>
$ ldapadd -H ldap://127.0.0.1 -D "cn=admin,dc=yourcomputer,dc=local" -W
dn:dc=yourcomputer,dc=local
objectClass:dcObject
objectClass:organizationalUnit
dc:yourcomputer
ou:YOURCOMPUTER
</pre>

In config.php tell Moodle where to look for your test LDAP environment:

<pre>
define('TEST_AUTH_LDAP_HOST_URL', 'ldap://127.0.0.1');
define('TEST_AUTH_LDAP_BIND_DN', 'cn=admin,dc=yourcomputer,dc=local');
define('TEST_AUTH_LDAP_BIND_PW', '*');
define('TEST_AUTH_LDAP_DOMAIN', 'dc=yourcomputer,dc=local');
define('TEST_LDAPLIB_HOST_URL', 'ldap://127.0.0.1');
define('TEST_LDAPLIB_BIND_DN', 'cn=admin,dc=yourcomputer,dc=local');
define('TEST_LDAPLIB_BIND_PW', '*');
define('TEST_LDAPLIB_DOMAIN', 'dc=yourcomputer,dc=local');
</pre>

=Test execution=

To execute all test suites from main configuration file execute the <code>vendor/bin/phpunit</code> script from your <code>$CFG->dirroot</code> directory.

cd /home/example/moodle
vendor/bin/phpunit

The rest of examples uses <code>phpunit</code>, please substitute it with <code>vendor/bin/phpunit</code> or create a shortcut in your dirroot.

In IDEs, you may need to specify the path to the PHPUnit configuration file. Use the absolute path to <code>phpunit.xml</code> from your <code>$CFG->dirroot</code>.

There is an alternative script for running of tests via web interface: <code>admin/tool/phpunit/webrunner.php</code>. Use this as the last resort only when you cannot use the command-line interface on your test server. It will most probably break due to permissions problems if you try to execute it both from command-line and from webrunner. This feature is not officially supported.

===How to run only some tests===

==== Running a single test quickly ====

The fastest way to run a single test is:

vendor/bin/phpunit my_test_class_name my/tests/filename.php

This is faster than other methods because it avoids the need to search for the test file, but you should be careful because it may be possible to run tests this way which are not included in the normal run. If you use this method, do at least one full test run (or --group run, as below) to ensure the test can be found.

Please note the path name is optional if the testcase class and file names are standardised as described in [[Writing PHPUnit tests]].

==== Using the @group annotation ====

If you add annotations like

<code php>
/**
* Unit tests for {@link stack_cas_keyval}.
* @group qtype_stack
*/
class qtype_stack_cas_keyval_exception_testcase extends basic_testcase {
</code>

to all the classes in your plugin, then you can run just the tests for your plugin by doing

phpunit --group qtype_stack

Therefore, it is suggested that you annotate all your tests with the Frankenstyle name of your plugin.

==== Using multiple phpunit.xml files ====

It's easy to create alternative phpunit.xml files defining which tests must be run together. For reference, take a look to the default /phpunit.xml available in your base directory once the testing environment has been initialised. After creating the custom file you will be able to run those tests with

vendor/bin/phpunit -c path/to/your/alternative/phpunit/file.xml

Also, for commodity, you can use this command:

php admin/tool/phpunit/cli/util.php --buildcomponentconfigs

It will, automatically, create one valid phpunit.xml file within each component (plugin or subsystem) and other important directories, so later you will be able to execute tests like

vendor/bin/phpunit -c mod/forum[/phpunit.xml] // Note that it's not needed to specify the name of the file (if it is 'phpunit.xml').
vendor/bin/phpunit -c question
vendor/bin/phpunit -c question/type/calculated
vendor/bin/phpunit -c backup
vendor/bin/phpunit -c lib/dml
...

or, also

cd directory/with/phpunit.xml
phpunit

=External test resources=
{{Moodle 2.6}}
By default Moodle phpunit tests contact http://download.moodle.org server when testing curl related functionality. Optionally you may checkout a local copy of the test scripts and access it instead:

# clone https://github.com/moodlehq/moodle-exttests to web directory
# add to your config.php or modify phpunit.xml file <code php>define('TEST_EXTERNAL_FILES_HTTP_URL', 'http://localhost/moodle-exttests');</code>

=Writing new tests=
* read [http://www.phpunit.de/manual/current/en/ official PHPUnit online documentation]
* see [[Writing PHPUnit tests]]

=Conversion of existing SimpleTests=
* see [[SimpleTest conversion]]

=PHPUnit support in IDEs=

* [[Setting up Eclipse]]
* [[Setting up Netbeans]]
* [[Setting up PhpStorm]]

=Common Unit Test Problems=
[[Common unit test problems]]

=Performance=

A typical run of full PHPUnit tests for Moodle 2.7 takes 10-20 minutes depending on the machine. If tests run slowly for you:

* Ensure you are using a database and filesystem running on the same machine that is running the tests (not on a remote server).
* Apply developer-only performance settings to your database: [[Postgres Tuning For Developers]]

[[Category:Unit testing]]

LDAP API

2017-05-24T06:30:17Z

Johnok: Begin a summary of LDAP API

The LDAP API enables it is used by [[LDAP authentication]] module and [https://docs.moodle.org/en/LDAP_enrolment LDAP enrolment]

To use it, require lib/ldaplib.php
==Functions==
===ldap_supported_usertype===
Returns predefined user types
===ldap_getdefaults===
Initializes needed variables for ldap-module
===ldap_isgroupmember===
Checks if user belongs to specific group(s) or is in a subtree
===ldap_connect_moodle===
Tries connect to specified ldap servers
===ldap_find_userdn===
Search specified contexts for username and return the user dn
===ldap_normalise_objectclass===
Normalise the supplied objectclass filter. This normalisation is a rudimentary attempt to format the objectclass filter correctly.
===ldap_get_entries_moodle===
Returns values like ldap_get_entries but is binary compatible and returns all attributes as array. This will return lower case entries.
===ldap_filter_addslashes===
Quote control characters in texts used in LDAP filters - see RFC 4515/2254
===ldap_get_dn_special_chars===
Returns the special characters in order of replacement
===ldap_addslashes===
Quote control characters in AttributeValue parts of a RelativeDistinguishedName used in LDAP distinguished names - See RFC 4514/2253
===ldap_stripslashes===
Unquote control characters in AttributeValue parts of a RelativeDistinguishedName used in LDAP distinguished names - See RFC 4514/2253
===ldap_paged_results_supported===
Check if we can use paged results (see RFC 2696). We need to use LDAP version 3 (or later), otherwise the server cannot use them. If we also pass in a valid LDAP connection handle, we also check whether the server actually supports them.

LDAP authentication

2017-05-24T06:23:17Z

Johnok: More links

The LDAP authentication module enables users to connect to an LDAP server for authentication. The module extends the [[Authentication API]] and is implemented using the [[LDAP API]]

For more information on how to set up your LDAP test environment, go to [[LDAP development setup]].

For more information on how to use the LDAP authentication module, go to [https://docs.moodle.org/en/LDAP_authentication the user docs page on LDAP authentication]

LDAP authentication

2017-05-24T06:19:41Z

Johnok: Intro on LDAP auth for devs

Talk:Callbacks

2017-05-22T01:03:00Z

Johnok: Simplify

Calling these callbacks officially is confusing for any new developer coming into moodle. A callback is a function reference passed as a parameter in a function call. Or from wikipedia "a callback is any executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at a given time." This is not what these are. Sure, we can make the argument that these are "moodle" callbacks. But these really are just API methods. As an open source project we have responsibility to the correct terms to refer to parts of our infrastructure to lower the barrier for entry and understanding of our code. --[[User:John Okely|John Okely]] ([[User talk:John Okely|talk]]) 09:00, 22 May 2017 (AWST)

Talk:Callbacks

2017-05-22T01:00:38Z

Johnok: Initiate discussion on better name

Calling these callbacks officially is confusing for any new developer coming into moodle. A callback is a function reference passed as a parameter in a function call for the called function to call. Or from wikipedia "a callback is any executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at a given time." This is not what these are. Sure, we can make the argument that these are "moodle" callbacks. But these really are just API methods. As an open source project we have responsibility to the correct terms to refer to parts of our infrastructure to lower the barrier for entry and understanding of our code. --[[User:John Okely|John Okely]] ([[User talk:John Okely|talk]]) 09:00, 22 May 2017 (AWST)

Process

2017-05-09T02:43:40Z

Johnok: Add step about UX

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].

===CiBoT===

CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.

===Component leads===

[http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components.

===Integrators===

On Monday and Tuesday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Wednesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===

On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===

After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.

See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===

[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

===Scrum===

At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.

===Planning and development===

The UX team, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying project ahead of development time.

New features are worked on by the "Dev" team. The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints and goes through the standard weekly integration workflow described above.

===Testing===

During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs manual functional testing of Moodle features. The current list of functional tests is listed in the tracker in the [http://tracker.moodle.org/browse/MDLQA-1 MDLQA project]. This list of tests is extended as new features are added, but it is also being reduced as more automated [[Acceptance_testing|acceptance tests]] are developed.

For more details, see [[Testing]].

===Sprints===

At Moodle HQ, development takes place in sprints. The sprints are three-week periods during which developers to focus on a fixed list of issues. Sprints are arranged within each release cycle as shown in the diagram below.

===Events during cycle===

During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]

; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

The User Experience (UX) team should create detailed wireframes and features and goals for the new feature. It should be agreed upon and as final as possible before development starts.

Developers should create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using Git===

Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.

===Peer review===

The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===

The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. See the information about the integration workflow above.

==Fixing a bug==

Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

===Make sure there is a tracker issue===

Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].

===Decide which branches the fix is required on===

Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.

===Develop your change using git===

Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like wip_MDL-12345_31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

If you '''don't see "Request peer review" button''', just comment on the issue with the git repository URL, branch name, diff URL and testing instructions. Component lead or another user with sufficient privileges will send the issue up for peer for you. After your first fix is integrated you will be added to developers group and will be able to send issues for peer review.

===Peer review===

The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit your code for integration===

It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release.

==Security issues==

Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].

* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.

Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.

====How to remove a branch from Github====

To remove a branch from Github, you can use the following command.

git push github :remote_branch

Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.

==Policy issues==

Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.

Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.

==See also==

* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]

Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU

[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Process

2017-05-09T02:41:47Z

Johnok: Update issue triage based on our new team and backlog

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].

===CiBoT===

CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.

===Component leads===

[http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components.

===Integrators===

On Monday and Tuesday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Wednesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===

On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===

After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.

See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===

[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

===Scrum===

At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.

===Planning and development===

The UX team, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying project ahead of development time.

New features are worked on by the "Dev" team. The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints and goes through the standard weekly integration workflow described above.

===Testing===

During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs manual functional testing of Moodle features. The current list of functional tests is listed in the tracker in the [http://tracker.moodle.org/browse/MDLQA-1 MDLQA project]. This list of tests is extended as new features are added, but it is also being reduced as more automated [[Acceptance_testing|acceptance tests]] are developed.

For more details, see [[Testing]].

===Sprints===

At Moodle HQ, development takes place in sprints. The sprints are three-week periods during which developers to focus on a fixed list of issues. Sprints are arranged within each release cycle as shown in the diagram below.

===Events during cycle===

During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]

; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

Developers should create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using Git===

Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.

===Peer review===

The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===

The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. See the information about the integration workflow above.

==Fixing a bug==

Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

===Make sure there is a tracker issue===

Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].

===Decide which branches the fix is required on===

Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.

===Develop your change using git===

Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like wip_MDL-12345_31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

If you '''don't see "Request peer review" button''', just comment on the issue with the git repository URL, branch name, diff URL and testing instructions. Component lead or another user with sufficient privileges will send the issue up for peer for you. After your first fix is integrated you will be added to developers group and will be able to send issues for peer review.

===Peer review===

The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit your code for integration===

It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release.

==Security issues==

Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].

* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.

Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.

====How to remove a branch from Github====

To remove a branch from Github, you can use the following command.

git push github :remote_branch

Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.

==Policy issues==

Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.

Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.

==See also==

* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]

Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU

[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Process

2017-05-09T02:39:25Z

Johnok: Update planning and development now that we have new teams

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].

===CiBoT===

CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.

===Component leads===

[http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components.

===Integrators===

On Monday and Tuesday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Wednesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===

On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===

After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.

See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===

[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on FRONTEND issues (mostly related to user interface) and BACKEND issues (mostly related to APIs) and Martin Dougiamas regularly puts issues on specific backlogs for these teams, as appropriate.

===Scrum===

At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.

===Planning and development===

The UX team, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying project ahead of development time.

New features are worked on by the "Dev" team. The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints and goes through the standard weekly integration workflow described above.

===Testing===

During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs manual functional testing of Moodle features. The current list of functional tests is listed in the tracker in the [http://tracker.moodle.org/browse/MDLQA-1 MDLQA project]. This list of tests is extended as new features are added, but it is also being reduced as more automated [[Acceptance_testing|acceptance tests]] are developed.

For more details, see [[Testing]].

===Sprints===

At Moodle HQ, development takes place in sprints. The sprints are three-week periods during which developers to focus on a fixed list of issues. Sprints are arranged within each release cycle as shown in the diagram below.

===Events during cycle===

During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]

; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

Developers should create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using Git===

Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.

===Peer review===

The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===

The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. See the information about the integration workflow above.

==Fixing a bug==

Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

===Make sure there is a tracker issue===

Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].

===Decide which branches the fix is required on===

Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.

===Develop your change using git===

Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like wip_MDL-12345_31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

If you '''don't see "Request peer review" button''', just comment on the issue with the git repository URL, branch name, diff URL and testing instructions. Component lead or another user with sufficient privileges will send the issue up for peer for you. After your first fix is integrated you will be added to developers group and will be able to send issues for peer review.

===Peer review===

The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit your code for integration===

It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release.

==Security issues==

Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].

* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.

Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.

====How to remove a branch from Github====

To remove a branch from Github, you can use the following command.

git push github :remote_branch

Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.

==Policy issues==

Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.

Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.

==See also==

* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]

Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU

[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Process

2017-05-09T02:36:31Z

Johnok: Update our team and scrum process summary

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].

===CiBoT===

CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.

===Component leads===

[http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components.

===Integrators===

On Monday and Tuesday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Wednesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===

On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===

After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.

See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===

[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on FRONTEND issues (mostly related to user interface) and BACKEND issues (mostly related to APIs) and Martin Dougiamas regularly puts issues on specific backlogs for these teams, as appropriate.

===Scrum===

At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.

===Planning and development===

The FRONTEND and BACKEND teams, employed at Moodle HQ, work on specifications of major new features for approximately three to four weeks following a major release.

The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints and goes through the standard weekly integration workflow described above.

===Testing===

During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs manual functional testing of Moodle features. The current list of functional tests is listed in the tracker in the [http://tracker.moodle.org/browse/MDLQA-1 MDLQA project]. This list of tests is extended as new features are added, but it is also being reduced as more automated [[Acceptance_testing|acceptance tests]] are developed.

For more details, see [[Testing]].

===Sprints===

At Moodle HQ, development takes place in sprints. The sprints are three-week periods during which developers to focus on a fixed list of issues. Sprints are arranged within each release cycle as shown in the diagram below.

===Events during cycle===

During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]

; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

Developers should create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using Git===

Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.

===Peer review===

The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===

The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. See the information about the integration workflow above.

==Fixing a bug==

Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

===Make sure there is a tracker issue===

Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].

===Decide which branches the fix is required on===

Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.

===Develop your change using git===

Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like wip_MDL-12345_31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

===Submit your code for peer review===

Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

If you '''don't see "Request peer review" button''', just comment on the issue with the git repository URL, branch name, diff URL and testing instructions. Component lead or another user with sufficient privileges will send the issue up for peer for you. After your first fix is integrated you will be added to developers group and will be able to send issues for peer review.

===Peer review===

The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit your code for integration===

It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release.

==Security issues==

Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].

* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.

Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.

====How to remove a branch from Github====

To remove a branch from Github, you can use the following command.

git push github :remote_branch

Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.

==Policy issues==

Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.

Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.

==See also==

* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]

Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU

[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Running acceptance test

2017-04-27T07:05:55Z

Johnok: Explain -a a bit better

== Prerequisite ==
Before initializing acceptance test environment for running behat, you should ensure:
# [[Acceptance_testing#Requirements Meet min. system requirements for running tests]]
# [[Acceptance_testing#Installation Have set min. config variable in config.php for behat]]
# [[Acceptance_testing#Installation Downloaded composer dependencies]]

== Overview ==
Acceptance tests (also known as behat), use [http://www.seleniumhq.org/download/ Selenium server] and can be run as:
# '''Single run:''' In single run, only one behat run is executed. So all features are executed in this single run.
# '''Parallel runs:''' (Since Moodle 3.0) Parallel runs allow dev's to execute multiple behat runs together. This was introduced to get acceptance tests results faster. To achieve this:
#* Features are divided between multiple behat runs
#* Symlinks behatrun{x} (x being the run process number), are created pointing to moodle directory, so site for run 1 is accessible via https://localhost/moodle/behatrun1
#* Process number is included as suffix to $CFG->behat_prefix.
#* Process number is suffixed to $CFG->behat_dataroot.

== Step 1: Initialise acceptance test environment ==
Before running acceptance tests, environment needs to be initialised for acceptance testing.

=== Single run ===
For initialising acceptance tests for single run, above command is sufficient.
<code>
php admin/tool/behat/cli/init.php
</code>

=== Parallel runs ===
For initialising acceptance tests for parallel runs, you can use one of the following options
# '''-j or --parallel''' (required) Number of parallel behat run to initialise
# '''-m or --maxruns''' (optional) Max parallel site which should be initialised at one time. If your system is slow, then you can initialise sites in chucks.
# '''--fromrun''' (optional) Initialise site to run specified run from. Used for running acceptance tests on different vms
# '''--torun''' (optional) Initialise site to run specified run till. Used for running acceptance tests on different vms
# '''-o or --optimize-runs''' (optional) This option will split features with specified tags in all parallel runs, so they are executed first when parallel run gets executed.
# '''-a or --add-core-features-to-theme''' (optional) Since Moodle 3.2. Use this option to add all core features to specified theme's (comma separated list of themes)
<code>
// Below command will initialise moodle to run 2 parallel tests.
php admin/tool/behat/cli/init.php --parallel=2
</code>

== Step 2: Running acceptance test environment ==
=== Single run ===
Run either of the following commands. For more options '''vendor/bin/behat --help''' or http://docs.behat.org/guides/6.cli.html
<code>
vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behatrun/behat/behat.yml
</code>
<code>
php admin/tool/behat/cli/run.php
</code>

=== Parallel runs ===
For running parallel runs, use following command
<code>
php admin/tool/behat/cli/run.php
</code>
Following optional options are available for custom run:
# '''--feature''' Only execute specified feature file (Absolute path of feature file).
# '''--suite''' Features for specified theme will be executed.
# '''--replace''' Replace args string with run process number, useful for output and reruns.
# '''--fromrun''' Execute run starting from (Used for parallel runs on different vms)
# '''--torun''' Execute run till (Used for parallel runs on different vms)
# '''-a or --add-core-features-to-theme''' (optional) Since Moodle 3.2. Use this option to add all core features to specified theme's (comma separated list)
# Behat options can be passed for filtering features/scenarios:
#* In case you don't want to run Javascript tests, use the Behat tags option to skip them, '''--tags="~@javascript"'''
#* In case you want to run specific scenario, use the Behat name option to run it, '''--name="Filter user accounts by role and cohort"'''
#* In case you want to run specific feature file, use the Behat feature option to run it, '''--feature="/PATH/TO/MOODLE/admin/tests/behat/filter_users.feature"'''

=== Common options for running tests ===
==== Tests filters ====
With the '''--tags''' or the '''-name''' Behat options you can filter which tests are going to run or which ones are going to be skipped. There are a few tags that you might be interested in:
* '''@javascript''': All the tests that runs in a browser using Javascript; they require Selenium to be running, otherwise an exception will be thrown.
* '''@_file_upload''': All the tests that involves file uploading or any OS feature that is not 100% part of the browser. They should only be executed when Selenium is running in the same machine where the tests are running.
* '''@_alert''': All the tests that involves Javascript dialogs (alerts, confirms...) are using a feature that is OS-dependant and out of the browser scope, so they should be tag appropriately as not all browsers manage them properly.
* '''@_switch_window''': All the tests that are using the '''I switch to "NAME" window''' step should be tagged as not all browsers manage them properly.
* '''@_switch_iframe''': All the tests that are using the '''I switch to "NAME" window''' steps should be tagged as it is an advanced feature and some browsers may have problems dealing with them
* '''@_cross_browser''': All the tests that should run against multiple combinations of browsers + OS in a regular basis. The features that are sensitive to different combinations of OS and browsers should be tagges as @_cross_browser.
* '''@componentname''': Moodle features uses the [https://docs.moodle.org/dev/Frankenstyle Frankenstyle] component name to tag the features according to the Moodle subsystem they belong to.

==== Output formats ====
Since Moodle 3.1 option for output is:
<code>
--format=pretty --out=/path/to/pretty.txt --format=moodle_progress --out=std
</code>
Before Moodle 3.1 option for output was:
<code>
--format='moodle_progress,pretty' --out=',/path/to/pretty.txt'
</code>
Following output formats are supported:
# '''progress''': Prints one character per step.
# '''pretty''': Prints the feature as is.
# '''junit''': Outputs the failures in JUnit compatible files.
# '''moodle_progress''': Prints Moodle branch information and dots for each step.
# '''moodle_list''': List all scenarios.
# '''moodle_stepcount''': List all features with total steps in each feature file. Used for parallel run.
# '''moodle_screenshot''': (since Moodle 3.1) Take screenshot and core dump of each step. With following options you can dump either or both.
## --format-settings '{"formats": "image"}'**: will dump image only
## --format-settings '{"formats": "html"}'**: will dump html only.
## --format-settings '{"formats": "html,image"}'**: will dump both.
## --format-settings '{"formats": "html", "dir_permissions": "0777"}'**
If you want to see the failures immediately (rather than waiting ~3 hours for all the tests to finish) then either use the -v option to output a bit more information, or change the output format using --format. Format 'pretty' ('''-f pretty''') is sufficient for most cases, as it outputs each step outcomes in the command line making easier to see the progress.

== Advance usage ==
=== Rerun failed scenarios ===
With slow systems or parallel run you might see some random failures, to rerun only failed scenarios (to eliminate random failures), use --rerun option
# '''Single run:''' --run="absolute_path_to_empty_file" (Behat will record failed scenarios in this file, and when run again only failed scenarios will be run)
# '''Parallel run:''' --rerun="absolute_path_to_empty_file_{runprocess}.txt --replace="{runprocess}" ({runprocess} will be replaced with the process number for recording fails in the specific run process).
'''Since Moodle 3.1 --rerun option don't accept any value, as it is handled internally by behat'''

=== Running behat with specified theme (Since Moodle 3.2) ===
You can run behat with any theme installed. To execute behat with specified theme use '''--suite={THEME_NAME}''' option, while running behat. By default the features in theme behat folder will be executed for the suite. But if you want to run all core features with the specific theme then initialise acceptance test with -a option. For example, '''-a {THEME_NAME}'''

==== Override behat core context for theme suite ====
To override behat step definitions so as to run behat with specified theme, you should create a contexts within '''/theme/{MYTHEME}/tests/behat/''' with prefix behat_theme_{MYTHEME}_ and suffixed with the context being overridden. For example, if you want to override behat_mod_forum context, then you should create a class /theme/{MYTHEME}/tests/behat/mod_forum/behat_theme_{MYTHEME}_behat_mod_forum.php

==== Blacklist behat context or features to run in theme suite ====
To blacklist contexts/ features to be executed by theme suite you should create a /theme/{MYTHEME}/tests/behat/blacklist.json file with following format. Following will not use step_definitions from behat_grade and behat_navigation while running theme suite. Also, scenarios in auth/tests/behat/login.feature and grade/tests/behat/grade_hidden_items.feature won't be executed with theme suite.
<code>
{
"contexts": [
"behat_grade",
"behat_navigation",
],
"features": [
"auth/tests/behat/login.feature",
"grade/tests/behat/grade_hidden_items.feature",
]
}
</code>
==== Override core behat selectors ====
To override behat selectors in specific theme, you should create a class behat_theme_{MYTHEME}_behat_selectors in /theme/{MYTHEME}/tests/behat/behat_theme_{MYTHEME}_behat_selectors.php extending behat_selectors.

=== Use php built in web server ===
You can use php built-in-web server for executing behat runs. To do so:
# Open a command line interface and '''cd /to/your/moodle/dirroot'''
# '''php -S localhost:8000''' (This is the test site URL that moodle uses by default, if you want to use another one you can override it in config.php with $CFG->behat_wwwroot attribute; more info in https://docs.moodle.org/dev/Acceptance_testing#Advanced_usage or config-dist.php)
# Update $CFG->behat_wwwroot = localhost:8000; in config.php

=== Define custom options for parallel runs ===
You can set following custom config options for parallel runs via $CFG->behat_parallel_run. It's an array of options where 1st array is for 1st run and so on.
<code>
array (
'dbtype' => 'mysqli',
'dblibrary' => 'native',
'dbhost' => 'localhost',
'dbname' => 'moodletest',
'dbuser' => 'moodle',
'dbpass' => 'moodle',
'behat_prefix' => 'mdl_',
'wd_host' => 'http://127.0.0.1:4444/wd/hub',
'behat_wwwroot' => 'http://127.0.0.1/moodle',
'behat_dataroot' => '/home/example/bht_moodledata'
)
</code>

To set different selenium servers for parallel runs, you can use following. NOTE: Running parallel (headless) runs on different selenium servers avoid random focus failures.
<code>
$CFG->behat_parallel_run = array (
array ('wd_host' => 'http://127.0.0.1:4444/wd/hub'),
array ('wd_host' => 'http://127.0.0.1:4445/wd/hub'),
array ('wd_host' => 'http://127.0.0.1:4446/wd/hub'),
);
</code>

=== Running acceptance tests with different browser ===
By default behat will run with Firefox browser through Selenium. By adding the following code to your config.php you can change the selected browser that is run when behat is invoked. You will need to run php admin/tool/behat/cli/init.php for changes to take effect. Then use --profile='chrome'.

<code>
$CFG->behat_profiles = array(
'chrome' => array(
'browser' => 'chrome',
'tags' => '@javascript',
)
);
</code>
[[Acceptance_testing/Browsers|More info about alternative browsers]]

=== Start multiple selenium servers ===
From command line Start selenium servers at different ports (say 4444, 4445, 4446 for 3 parallel runs)
<code>
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4444 &
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4445 &
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4446
</code>

=== Using Docker to start selenium server ===
==== What is Docker ====
Docker is a app container, it's a kind of virtual machine, but only for one app, service, so you can download
a docker image and run a selenium server without worry in how to configure selenium in your machine, one for chrome, others for firefox, you either don't need to install the browsers in your machine
To install docker follow this link; https://docs.docker.com/engine/installation/

==== Selenium docker images ====
There is many docker images available, for many browser, the complete list is in https://hub.docker.com/u/selenium/
for moodle you can use standalone version.
You can download specific selenium version too, for example, for firefox, moodle recommend selenium 2.53.1, see: [https://docs.moodle.org/dev/Acceptance_testing/Browsers/Working_combinations_of_OS%2BBrowser%2Bselenium What version do I need?]

so the command will be:
<code>
docker run -d -p4444:4444 selenium/standalone-firefox:2.53.1-beryllium
</code>
to see all available version click in tags. For firefox you can find at: https://hub.docker.com/r/selenium/standalone-firefox/tags/

==== Change config.php file ====
In config.php file you must change the $CFG->behat_wwwroot= to your network card (NIC) ip address, you can't use
localhost , 127.0.0.1, ... or selenium docker server will fail

== NOTE ==
# Start the Selenium server (in case you want to run tests that involves Javascript)
#* (See http://www.installationpage.com/selenium/how-to-run-selenium-headless-firefox-in-ubuntu/ for running 'headless' Firefox and xvfm in a server environment)
#* Open another command line interface and '''java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar'''

=== Trouble shooting ===
=== New step definitions or features are not executed ===
If you are adding new tests or steps definitions update the tests list
<code>
php admin/tool/behat/cli/util.php --enable
</code>
''' For parallel runs, all options for initialising parallel runs are valid '''

=== Tests are failing ===
If you followed all the steps and you receive an unknown weird error probably your system's Firefox version is not compatible with the Selenium version you are running. Please refer Working combinations to ensure you have correct [[Acceptance_testing/Browsers/Working_combinations_of_OS%2BBrowser%2Bselenium combination]] of them to run acceptance test.

=== Disable acceptance test environment ===
if you want to prevent access to test environment
<code>
php admin/tool/behat/cli/util.php --disable
</code>
'''Note that if you have the HTTP_PROXY environment variable set, which you may have had to do to run composer, then you also need to set NO_PROXY=localhost.'''

== External links ==
* Vagrant profile with Moodle and Behat preconfigured: https://github.com/mackensen/moodle-hat

Core filetypes

2017-04-26T02:12:02Z

Johnok: Example code

lib/classes/filetypes.php defines the filetypes included in core.

get_default_types returns an associative array of extension keys to a value which is an array of type, icon, groups and string (which is a lang string which will be used when displaying the type. The lang string is passed $a->EXT which is the actual extension.

<code>
'php' => array('type' => 'text/plain', 'icon' => 'sourcecode'),
'pic' => array('type' => 'image/pict', 'icon' => 'image', 'groups' => array('image'), 'string' => 'image'),
'pict' => array('type' => 'image/pict', 'icon' => 'image', 'groups' => array('image'), 'string' => 'image'),
'png' => array('type' => 'image/png', 'icon' => 'png', 'groups' => array('image', 'web_image'), 'string' => 'image')
</code>

String example (in lang/en/mimetypes.php)
<code>
$string['image'] = 'Image ({$a->MIMETYPE2})';
</code>

Any groups added should add a language string to lang/en/mimetypes.php with the formate group:<groupname>. This is so that the group can be displayed in a human readable formate in the user's native language.

Core filetypes

2017-04-26T02:10:19Z

Johnok: Add core filetypes wiki page.

Projects for new developers

2017-01-24T04:38:00Z

Johnok: Add Mock DB dml implementation project

{{GSOC}}

==Getting started==

Moodle uses PHP, JavaScript, SQL and a number of other Web languages, so learning those is a good place to start.

When you have some basic PHP programming skills, you may wish to start learning about how the Moodle code is organised. It is recommended that you complete the [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming] course on [http://dev.moodle.org/ dev.moodle.org]. To access this you will need to have an account on moodle.org first.

''If you are looking for projects suggested in the tracker, look for issues with the [https://tracker.moodle.org/issues/?jql=labels%20in%20%28addon_candidate%29 'addon_candidate' label].

''If you are looking to make a quick contribution, look for tracker issues with marked as [https://tracker.moodle.org/issues/?jql=Difficulty%20%3D%20Easy easy].

''Please consider adopting a [https://moodle.org/plugins/browse.php?list=set&id=61 plugin seeking a new maintainer]''. See the [https://moodle.org/mod/forum/discuss.php?d=260354 Plugins adoption programme].

As you become more involved in Moodle development, you might like to learn more about the [[Coding|coding conventions]] used and how changes to Moodle core code are [[Process|processed]].

==Potential projects==

This evolving page lists possible Moodle projects for new developers derived from community suggestions.

''If you have any ideas for new features in Moodle which might be suitable as projects for new developers, please see [[New feature ideas]].''

=== Pusher integration for HTML5 push notifications ===
Moodle supports message output plugins. By adding a plugin for pusher.com and a Javascript service worker to listen for push notifications, we can have realtime HTML5 notifications on all platforms.
:'''Skills required''': Javascript (JQuery, AMD), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1337843 Damyon Wiese]

=== Ability to crop/resize/rotate an image in atto ===

Moodle comes with it's own HTML editor known as 'atto' (see https://docs.moodle.org/dev/Atto). The editor functions similarly to other editors out there, like TinyMCE, but is tailored to Moodle. It comes with multiple plugins that allow users to perform tasks, such as changing the font size, the alignment, adding links etc. One of these plugins allows the user to add an image to the text editor with the ability to specify the size and alignment of the image via text input. The idea of this project is to extend and improve this current plugin so the user can crop/resize/rotate the image via JS - making the whole experience easier and more aesthetically pleasing.

This project details/discussion can be located at MDL-52982.

:'''Skills required''': Javascript (YUI), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/view.php?id=1057750 Mark Nelson]

=== Improve Behat tests in SCORM plugin ===
The Moodle SCORM plugin does not contain very many behat tests and most tests are manual. The Claude Ostyn diagnostic SCO should be used to implement a range of new Behat tests to cover the functionality that the SCORM module provides.

Deliverables:
* Behat tests for all existing SCORM QA tests (where possible)
* Behat tests for all SCORM settings (eg standards mode, mastery score settings etc)
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.
:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Advanced Grading in Forums ===
Finish the work required to add the advanced grading feature to the Moodle forum activity. This builds on some existing work available at MDL-31860

Deliverables:
* Modify the forum grading so that it pushes 2 grade areas (or 3 including ratings) into the gradebook instead of a single grade.
* Improve interface that allows overall forum participation grading.
* Behat tests for all new functionality.
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Add support to end-to-end testing in the Mobile app ===

[https://angular.github.io/protractor/#/ Protractor] is an end-to-end test framework for AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

The basements for this project are done, see MOBILE-1179, the only remaining work is to add more tests to the app and document the set-up process in the Moodle developers wiki.

:'''Skills required: Javascript (AngularJS)
:'''Difficulty level: Medium
:'''Possible mentor: [https://moodle.org/user/profile.php?id=49568 Juan Leyva]

===Clef | Two-Factor Authentication===
Create [https://getclef.com Clef two factor authentication] plugin, so a user can log in using their mobile to reduce login time. This will improve security and reduce the login time for users.

:'''Skills required:''' PHP, Javascript
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1328988 Rajesh Taneja]

=== Multi-step login screen ===
Update the login screen to first ask for a username, and then the password as a two-step process.
See the login process for Google

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1779959 John Okely]

=== 2FA - Two Factor Authentication ===
Add support for Two-Factor Authentication. This would work well when combined with the Multi-step login screen.
Factors requiring consideration include the Mobile app integrations.

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== CLI Helper for Moodle Developers ===
Possibly an addendum to MDK, a set of scripts to help facilitate various common tasks. In particular:
* creation of Persistent Objects including their Class files, the XMLDB code to create their tables, and the XMLDB upgrade scripts required to upgrade (including version bumps)

:'''Skills required:''' PHP, Python?
:'''Difficulty level''': Hard
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== Trait for Mock DB in unit tests ===
In moodle we run every unit test using a real database. This is extremely slow with little benefit. Granted it does catch some cross-database compatibility issues, but we don't need it for every test. We should add a trait that test classes can use that will automatically set up mock $DB to save processing power and unnecessary waiting for DB.

:'''Skills required:''' PHP, PHPUnit
:'''Difficulty level''': Easy
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols] or [https://moodle.org/user/profile.php?id=1779959 John Okely]

=== Mock implementation of DML ===
In moodle we run every unit test using a real database. This is extremely slow with little benefit. Granted it does catch some cross-database compatibility issues, but we don't need it for every test. It is possible to extend moodle_database and mock all the calls to use an in memory/mocked database. The easiest way to do this may be to use first make a Data Access Object implementation, and then use a mock DAO

:'''Skills required:''' PHP, PHPUnit
:'''Difficulty level''': Very Hard
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1779959 John Okely]

==See also==

* [[GSOC]] - describing Moodle's involvement with Google in their Summer of Code program
* [https://tracker.moodle.org/issues/?jql=type%20in%20%28%22New%20Feature%22%2C%20Improvement%29%20AND%20resolution%20%3D%20unresolved%20and%20labels%20in%20%28addon_candidate%29%20ORDER%20BY%20votes%20DESC Popular new feature and improvement requests in Tracker that can be implemented as plugins]
* [[Projects for new developers/Archive|Archive]] of outdated and/or inactive calls for projects
* [https://docs.moodle.org/dev/Moodle_Wishlist a Wishlist] by some Moodle users. Some of the good ideas here may be adopted.

Projects for new developers

2017-01-24T04:34:39Z

Johnok: Fix up trait db unit tests project

{{GSOC}}

==Getting started==

Moodle uses PHP, JavaScript, SQL and a number of other Web languages, so learning those is a good place to start.

When you have some basic PHP programming skills, you may wish to start learning about how the Moodle code is organised. It is recommended that you complete the [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming] course on [http://dev.moodle.org/ dev.moodle.org]. To access this you will need to have an account on moodle.org first.

''If you are looking for projects suggested in the tracker, look for issues with the [https://tracker.moodle.org/issues/?jql=labels%20in%20%28addon_candidate%29 'addon_candidate' label].

''If you are looking to make a quick contribution, look for tracker issues with marked as [https://tracker.moodle.org/issues/?jql=Difficulty%20%3D%20Easy easy].

''Please consider adopting a [https://moodle.org/plugins/browse.php?list=set&id=61 plugin seeking a new maintainer]''. See the [https://moodle.org/mod/forum/discuss.php?d=260354 Plugins adoption programme].

As you become more involved in Moodle development, you might like to learn more about the [[Coding|coding conventions]] used and how changes to Moodle core code are [[Process|processed]].

==Potential projects==

This evolving page lists possible Moodle projects for new developers derived from community suggestions.

''If you have any ideas for new features in Moodle which might be suitable as projects for new developers, please see [[New feature ideas]].''

=== Pusher integration for HTML5 push notifications ===
Moodle supports message output plugins. By adding a plugin for pusher.com and a Javascript service worker to listen for push notifications, we can have realtime HTML5 notifications on all platforms.
:'''Skills required''': Javascript (JQuery, AMD), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1337843 Damyon Wiese]

=== Ability to crop/resize/rotate an image in atto ===

Moodle comes with it's own HTML editor known as 'atto' (see https://docs.moodle.org/dev/Atto). The editor functions similarly to other editors out there, like TinyMCE, but is tailored to Moodle. It comes with multiple plugins that allow users to perform tasks, such as changing the font size, the alignment, adding links etc. One of these plugins allows the user to add an image to the text editor with the ability to specify the size and alignment of the image via text input. The idea of this project is to extend and improve this current plugin so the user can crop/resize/rotate the image via JS - making the whole experience easier and more aesthetically pleasing.

This project details/discussion can be located at MDL-52982.

:'''Skills required''': Javascript (YUI), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/view.php?id=1057750 Mark Nelson]

=== Improve Behat tests in SCORM plugin ===
The Moodle SCORM plugin does not contain very many behat tests and most tests are manual. The Claude Ostyn diagnostic SCO should be used to implement a range of new Behat tests to cover the functionality that the SCORM module provides.

Deliverables:
* Behat tests for all existing SCORM QA tests (where possible)
* Behat tests for all SCORM settings (eg standards mode, mastery score settings etc)
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.
:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Advanced Grading in Forums ===
Finish the work required to add the advanced grading feature to the Moodle forum activity. This builds on some existing work available at MDL-31860

Deliverables:
* Modify the forum grading so that it pushes 2 grade areas (or 3 including ratings) into the gradebook instead of a single grade.
* Improve interface that allows overall forum participation grading.
* Behat tests for all new functionality.
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Add support to end-to-end testing in the Mobile app ===

[https://angular.github.io/protractor/#/ Protractor] is an end-to-end test framework for AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

The basements for this project are done, see MOBILE-1179, the only remaining work is to add more tests to the app and document the set-up process in the Moodle developers wiki.

:'''Skills required: Javascript (AngularJS)
:'''Difficulty level: Medium
:'''Possible mentor: [https://moodle.org/user/profile.php?id=49568 Juan Leyva]

===Clef | Two-Factor Authentication===
Create [https://getclef.com Clef two factor authentication] plugin, so a user can log in using their mobile to reduce login time. This will improve security and reduce the login time for users.

:'''Skills required:''' PHP, Javascript
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1328988 Rajesh Taneja]

=== Multi-step login screen ===
Update the login screen to first ask for a username, and then the password as a two-step process.
See the login process for Google

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1779959 John Okely]

=== 2FA - Two Factor Authentication ===
Add support for Two-Factor Authentication. This would work well when combined with the Multi-step login screen.
Factors requiring consideration include the Mobile app integrations.

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== CLI Helper for Moodle Developers ===
Possibly an addendum to MDK, a set of scripts to help facilitate various common tasks. In particular:
* creation of Persistent Objects including their Class files, the XMLDB code to create their tables, and the XMLDB upgrade scripts required to upgrade (including version bumps)

:'''Skills required:''' PHP, Python?
:'''Difficulty level''': Hard
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== Trait for Mock DB in unit tests ===
In moodle we run every unit test using a real database. This is extremely slow with little benefit. Granted it does catch some cross-database compatibility issues, but we don't need it for every test. We should add a trait that test classes can use that will automatically set up mock $DB to save processing power and unnecessary waiting for DB.

:'''Skills required:''' PHP, PHPUnit
:'''Difficulty level''': Easy
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols] or [https://moodle.org/user/profile.php?id=1779959 John Okely]

==See also==

* [[GSOC]] - describing Moodle's involvement with Google in their Summer of Code program
* [https://tracker.moodle.org/issues/?jql=type%20in%20%28%22New%20Feature%22%2C%20Improvement%29%20AND%20resolution%20%3D%20unresolved%20and%20labels%20in%20%28addon_candidate%29%20ORDER%20BY%20votes%20DESC Popular new feature and improvement requests in Tracker that can be implemented as plugins]
* [[Projects for new developers/Archive|Archive]] of outdated and/or inactive calls for projects
* [https://docs.moodle.org/dev/Moodle_Wishlist a Wishlist] by some Moodle users. Some of the good ideas here may be adopted.

Projects for new developers

2017-01-24T04:34:12Z

Johnok: Add Mock DB trait project

{{GSOC}}

==Getting started==

Moodle uses PHP, JavaScript, SQL and a number of other Web languages, so learning those is a good place to start.

When you have some basic PHP programming skills, you may wish to start learning about how the Moodle code is organised. It is recommended that you complete the [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming] course on [http://dev.moodle.org/ dev.moodle.org]. To access this you will need to have an account on moodle.org first.

''If you are looking for projects suggested in the tracker, look for issues with the [https://tracker.moodle.org/issues/?jql=labels%20in%20%28addon_candidate%29 'addon_candidate' label].

''If you are looking to make a quick contribution, look for tracker issues with marked as [https://tracker.moodle.org/issues/?jql=Difficulty%20%3D%20Easy easy].

''Please consider adopting a [https://moodle.org/plugins/browse.php?list=set&id=61 plugin seeking a new maintainer]''. See the [https://moodle.org/mod/forum/discuss.php?d=260354 Plugins adoption programme].

As you become more involved in Moodle development, you might like to learn more about the [[Coding|coding conventions]] used and how changes to Moodle core code are [[Process|processed]].

==Potential projects==

This evolving page lists possible Moodle projects for new developers derived from community suggestions.

''If you have any ideas for new features in Moodle which might be suitable as projects for new developers, please see [[New feature ideas]].''

=== Pusher integration for HTML5 push notifications ===
Moodle supports message output plugins. By adding a plugin for pusher.com and a Javascript service worker to listen for push notifications, we can have realtime HTML5 notifications on all platforms.
:'''Skills required''': Javascript (JQuery, AMD), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1337843 Damyon Wiese]

=== Ability to crop/resize/rotate an image in atto ===

Moodle comes with it's own HTML editor known as 'atto' (see https://docs.moodle.org/dev/Atto). The editor functions similarly to other editors out there, like TinyMCE, but is tailored to Moodle. It comes with multiple plugins that allow users to perform tasks, such as changing the font size, the alignment, adding links etc. One of these plugins allows the user to add an image to the text editor with the ability to specify the size and alignment of the image via text input. The idea of this project is to extend and improve this current plugin so the user can crop/resize/rotate the image via JS - making the whole experience easier and more aesthetically pleasing.

This project details/discussion can be located at MDL-52982.

:'''Skills required''': Javascript (YUI), PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/view.php?id=1057750 Mark Nelson]

=== Improve Behat tests in SCORM plugin ===
The Moodle SCORM plugin does not contain very many behat tests and most tests are manual. The Claude Ostyn diagnostic SCO should be used to implement a range of new Behat tests to cover the functionality that the SCORM module provides.

Deliverables:
* Behat tests for all existing SCORM QA tests (where possible)
* Behat tests for all SCORM settings (eg standards mode, mastery score settings etc)
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.
:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Advanced Grading in Forums ===
Finish the work required to add the advanced grading feature to the Moodle forum activity. This builds on some existing work available at MDL-31860

Deliverables:
* Modify the forum grading so that it pushes 2 grade areas (or 3 including ratings) into the gradebook instead of a single grade.
* Improve interface that allows overall forum participation grading.
* Behat tests for all new functionality.
* The code should pass 100% of the Moodle codechecking tools to ensure the code meets with Moodle Guidelines.

Extra requirement for prospective students:
* We require prospective students to make an attempt at fixing at least 1 issue in the Moodle tracker before their proposal can be considered - on top of this you must also attempt to convert one existing QA test into a Behat test. This MUST be completed before your application can be considered valid.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

=== Add support to end-to-end testing in the Mobile app ===

[https://angular.github.io/protractor/#/ Protractor] is an end-to-end test framework for AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

The basements for this project are done, see MOBILE-1179, the only remaining work is to add more tests to the app and document the set-up process in the Moodle developers wiki.

:'''Skills required: Javascript (AngularJS)
:'''Difficulty level: Medium
:'''Possible mentor: [https://moodle.org/user/profile.php?id=49568 Juan Leyva]

===Clef | Two-Factor Authentication===
Create [https://getclef.com Clef two factor authentication] plugin, so a user can log in using their mobile to reduce login time. This will improve security and reduce the login time for users.

:'''Skills required:''' PHP, Javascript
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1328988 Rajesh Taneja]

=== Multi-step login screen ===
Update the login screen to first ask for a username, and then the password as a two-step process.
See the login process for Google

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=1779959 John Okely]

=== 2FA - Two Factor Authentication ===
Add support for Two-Factor Authentication. This would work well when combined with the Multi-step login screen.
Factors requiring consideration include the Mobile app integrations.

:'''Skills required:''' PHP, JavaScript, Mustache
:'''Difficulty level''': Medium
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== CLI Helper for Moodle Developers ===
Possibly an addendum to MDK, a set of scripts to help facilitate various common tasks. In particular:
* creation of Persistent Objects including their Class files, the XMLDB code to create their tables, and the XMLDB upgrade scripts required to upgrade (including version bumps)

:'''Skills required:''' PHP, Python?
:'''Difficulty level''': Hard
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols]

=== Trait for Mock DB in unit tests ===
In moodle we run every unit test using a real database. This is extremely slow with little benefit. Granted it does catch some cross-database compatibility issues, but we don't need it for every test. We should add a trait that test classes can use that will automatically set up mock $DB to save processing power and unnecessary waiting for DB.

:'''Skills required:''' PHP, Python?
:'''Difficulty level''': Hard
:'''Possible mentor''': [https://moodle.org/user/profile.php?id=268794 Andrew Nicols] or [https://moodle.org/user/profile.php?id=1779959 John Okely]

==See also==

* [[GSOC]] - describing Moodle's involvement with Google in their Summer of Code program
* [https://tracker.moodle.org/issues/?jql=type%20in%20%28%22New%20Feature%22%2C%20Improvement%29%20AND%20resolution%20%3D%20unresolved%20and%20labels%20in%20%28addon_candidate%29%20ORDER%20BY%20votes%20DESC Popular new feature and improvement requests in Tracker that can be implemented as plugins]
* [[Projects for new developers/Archive|Archive]] of outdated and/or inactive calls for projects
* [https://docs.moodle.org/dev/Moodle_Wishlist a Wishlist] by some Moodle users. Some of the good ideas here may be adopted.

LTI Content Item

2016-11-30T02:07:12Z

Johnok: Completed project

{{Infobox Project
|name = LTI Content-Item message
|state = Complete
|tracker = MDL-49609
|discussion = [https://moodle.org/mod/forum/discuss.php?d=293571 Support for LTI Content-Item message]
|assignee = [[User:Stephen Vickers|Stephen Vickers]], [[User:Jun Pataleta|Jun Pataleta]]
}}
==Project goal==
The goal of this project is to add support for the LTI Content-Item message as per the specification available from [http://www.imsglobal.org/lti/].

==Introduction==
This message type provides an improved workflow for teachers adding links to their courses, such that the configuration of the link by the tool provider can be included in the process. This avoids the current two-step process of creating the link and then launching it to access any configuration options the tool provider has to offer. It also means that students will not be presented with unconfigured links in their courses, because the link will not be created until after the configuration has occurred.

==See also==

* [http://www.imsglobal.org/specs/lticiv1p0-intro Introduction to LTI Content-Item Message 1.0 | IMS Global Learning Consortium]

Moodle libraries credits

2016-11-14T07:29:40Z

Johnok: Add LTI Tool Provider Library for PHP

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

Copyright (c) 2013, Donovan Schönknecht

License: BSD 2-Clause

https://github.com/tpyo/amazon-s3-php-class/releases

==CAS==

''auth/cas/CAS''

phpCAS library to support CAS authentication plugin

Copyright Jasig

License: Apache License 2.0

https://wiki.jasig.org/display/CASC/phpCAS

==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

(This library is not currently used in Moodle)

==FPDF Class==

''lib/fpdf''

Class to generate PDF files

Version: 1.54

Copyright Olivier PLATHEY

License: Freeware

http://www.setasign.com/products/fpdi/downloads

==GeoIP==

''lib/geoip''

Library for precessing of GeoIP data files

Version: 1.6

Copyright MaxMind

License: LGPL

http://www.maxmind.com/app/php

==Google APIs==

"lib/google"

Library Google APIs Client Library for PHP

Version: 1.1.7

License: Apache License Version 2.0

https://github.com/google/google-api-php-client

==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

==Horde==

''lib/horde''

Library used by the inbound e-mail handling system.

Version: 5.2.7

Copyright © Horde LLC

License: LGPL

http://www.horde.org/

==html2text==

''lib/html2text''

PHP script to convert HTML into an approximate text equivalent

Version: 4.0.1

Copyright © 2005-7 Jon Abernathy

License: GNU GPL

https://github.com/mtibben/html2text.git

==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)

(This library is not currently used in Moodle)

==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

(This library is not currently used in Moodle)

==jQuery==

''lib/jquery''

jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.

Version: 1.12.3

Copyright: 2016 The jQuery Foundation

License: MIT

https://jquery.com

==jQuery migrate==

''lib/jquery/jquery-migrate-1.4.0.js''

Library used migrate older jQuery code to jQuery 3.0.

Version: 1.4.0

Copyright: 2016 The jQuery Foundation and other contributors

License: MIT

https://github.com/jquery/jquery-migrate

==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

(This library is not currently used in Moodle)

==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

(This library is not currently used in Moodle)

==less.php==

The less.php is a PHP port of the official LESS processor used by moodle themes.

''lib/lessphp''

Version: 1.7.0.10

License: Apache 2.0

http://lessphp.typesettercms.com/

Copyright: Matt Agar and Martin Jantošovič
==MathJax==

"Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default."

JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.

Version 2.6

© Copyright 2015 The MathJax Consortium.

License: Apache V2.0

https://github.com/mathjax/MathJax

==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

==Mustache.js==

"lib/amd/src/mustache.js"

JS library for displaying mustache templates.

Version: 2.2.1

Copyright (c) 2009 Chris Wanstrath (Ruby)

Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)

Copyright (c) 2010-2015 The mustache.js community

License: MIT

https://github.com/janl/mustache.js/releases

==Mustache==

"lib/mustache"

PHP library for displaying mustache templates.

Version: 2.10.0

Copyright (c) 2010-2015 Justin Hileman

License: MIT

https://github.com/bobthecow/mustache.php/releases

==mp3player==

''lib/mp3player''

Flash movie to play streaming MP3s

Copyright © 2005 Andrew Walker

License: GNU GPL

(This library is not currently used in Moodle)

==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/

(This library is not currently used in Moodle)

== password_compat ==

''lib/password_compat''

Provides forward compatibility with the password_* functions that ship with PHP 5.5.

Copyright © 2012 Anthony Ferrara

License: MIT License

https://github.com/ircmaxell/password_compat

==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

(This library is not currently used in Moodle)

==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

(This library is not currently used in Moodle)

==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

(This library is not currently used in Moodle)

==PHPExcel==

''lib/phpexcel/PHPExcel.php''

Library to read, write and create spreadsheet documents in PHP.

Version 1.8.1

Copyright © 2006 - 2015 PHPExcel
License: LGPL

https://github.com/PHPOffice/PHPExcel

==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 5.2.14

Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')
License: LGPL

http://phpmailer.sourceforge.net
https://github.com/PHPMailer/PHPMailer/releases

==PHP Markdown==

''lib/markdown.php''

Functions to convert from the Markdown text format into clean XHTML.

Version: 1.6.0 (with modifications)

PHP Markdown Lib Copyright © 2004-2015 Michel Fortin https://michelf.ca/
All rights reserved.

Based on Markdown
Copyright © 2003-2005 John Gruber https://daringfireball.net/
All rights reserved.

License: BSD

http://www.michelf.com/projects/php-markdown/

==RequireJS==

''/lib/requirejs/''

RequireJS is a JavaScript file and module loader.

Version 2.1.22

License: new BSD or MIT

http://requirejs.org/

==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

(This library is not currently used in Moodle)

==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'')

(This library is not currently used in Moodle)

==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

(This library is not currently used in Moodle)

==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/

==Mustache.js==

"lib/amd/src/mustache.js"

JS library for displaying mustache templates.

Version: 2.2.1

Copyright (c) 2009 Chris Wanstrath (Ruby)

Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)

Copyright (c) 2010-2015 The mustache.js community

License: MIT

https://github.com/janl/mustache.js/releases

==LTI Tool Provider Library for PHP==

"lib/ltiprovider/"

PHP library for communicating with learning tools as per the LTI specification.

Version: 3.0.2

© 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)

License: Apache 2

https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP

[[Category:Credits]]

Moodle 3.2 release notes

2016-11-14T06:40:46Z

Johnok: Add docs link for loginpage_idp_list

[[Releases]] > {{FULLPAGENAME}}

Release date: 28 November 2016 (not yet released)

{{Work in progress}}

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

==Server requirements==

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

* Moodle upgrade: Moodle 2.7 or later (if upgrading from earlier versions, you must upgrade to 2.7.14 as a first step)
* PHP version: minimum PHP 5.6.5 (important! minimum PHP version has changed since Moodle 3.1). PHP 7.0 is supported but has some [https://docs.moodle.org/dev/Moodle_and_PHP7#Can_I_use_PHP7_yet.3F engine limitations]. PHP 7.1 will be supported when released.

=== 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 ===
Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

Desktop:
* Chrome
* Firefox
* Safari
* Edge
* Internet Explorer

Mobile:
* MobileSafari
* Google Chrome

For the best experience and optimum security, we recommend that you keep your browser up to date. https://whatbrowser.org

Note: Legacy browsers with known compatibility issues with Moodle 3.2:
* Internet Explorer 10 and below
* Safari 7 and below

==Major features==

Coming soon.

=== For developers ===

* MDL-55071, MDL-55074 - New "Boost" Bootstrap 4 theme, block and navigation changes
* MDL-55727 - Create AMD modal module
* MDL-49599 - Deprecate old boxnet v1 API
* MDL-53306 - Add hook to be executed before user login in authentication plugins
* MDL-55048 - Upgrade grunt and npm dependencies (and add travis checks on node version variants)
* MDL-47162 - Add course id to message eventdata
* MDL-50937 - Update to JQuery 3.1
* MDL-48114 - Add Meta-Information to composer.json
* MDL-54987 - Introduce a new chart API and library ([https://docs.moodle.org/dev/Charts_API documentation])
* MDL-52127 - Linting for Javascript with ESLint
* MDL-55058 - Linting for CSS with stylelint
* MDL-55072 - Upgrades to Behat so it can work with different themes
* MDL-55141 - Add debugging option when running scheduled tasks from CLI
* MDL-31243 - Refactor similar SQL generation code from get_users_by_capability & get_enrolled_uses to make get_with_capability_sql
* MDL-54941 - Add filesize as a new field returned in all the Web Services returning file information
* MDL-55091 - Upgrade phpunit to 5.x
* MDL-56082 - Expose external authentication methods (loginpage_idp_list) in login block ([https://docs.moodle.org/dev/Authentication_plugins#loginpage_idp_list.28.29 documentation])

==See also==
*[[Moodle 3.1 release notes]]

[[Category:Release notes]]
[[Category:Moodle 3.2]]

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

Authentication plugins

2016-11-14T06:39:37Z

Johnok: Document loginpage_idp_list

==Introduction==

This page first gives an '''overview''' of the ''authentication process'' and then explains how ''authentication modules'' can be '''created''' using hooks to take over from the native authentication in Moodle.
=== Overview of Moodle authentication process ===
[[File:1.9.11_login_element.png|203px||thumb|right|The login UI element in Moodle 1.9]]The authentication use case in Moodle starts when a user clicks on the Login link in the UI or if they try to access a protected page. There are two broad classes of authentication plugins, the regular type where moodle handles the password and ones where the password is handled by a 3rd party page eg SAML, OpenID etc.

For the regular plugins the following happens (skipping some minor details and rarer scenarios):

# The default login page (<tt>/login/index.php</tt>) is displayed. OR, if a system administrator has set the Alternate Login URL on the "Manage authentication" page, that URL will be displayed.
# A user enters their credentials and submits the form.
# The handler code in <tt>/login/index.php</tt> runs:
## Gets a list of enabled authentication plugins.
## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.
## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).
## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <code>$user</code> object. (Details of this code follow this main outline.)
## Determines whether authentication was successful (by checking whether <code>$user</code> is a valid object) and, if not, sends them back to the login page with an error message. Otherwise, it figures out where to send the user based on their original page request, whether their password is expired, etc., and redirects them there.

For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):
# Access a protected page but isn't logged in, so moodle calls <tt>pre_loginpage_hook()</tt> on each enabled plugin, which may redirect to the 3rd party login page
# Or if they go directly to the login page moodle calls <tt>loginpage_hook()</tt> on each enabled plugin, which may redirect to the 3rd party login page
# The user enters their credentials and authenticates on the 3rd party page
# The remote authentication service redirects back to moodle with an assertion, such as a single use token or encrypted response in a query param
# The auth plugin now validates the token or decrypts the assertion, does any other checking as required and then logs the user in using <tt>complete_user_login($user)</tt>. If this happens inside <tt>pre_loginpage_hook()</tt> then the user continues on their way, or if inside <tt>loginpage_hook()</tt> or another custom page then the plugin should redirect to the wantsurl.

Note that in this scenario above <tt>user_login($username, $password)</tt> is never called and should probably return false.

==History==
Authentication plugins exist from 1.9
==Example==
[http://moodle.org/plugins/view.php?plugin=auth_googleoauth2 Google / Facebook / Messenger Oauth2 Authentication plugin]

==Template==
Please see Moodle '''none''' authentication plugin (auth/none), it's the perfect plugin template to start with.

==Naming convention==
==File structure==
# Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.
# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.
# Create the file <tt>/auth/sentry/auth.php</tt>. Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>. (You will need to <code>require_once</code> the authlib file.)
# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.
# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''
# If you don't like seeing <nowiki>[[auth_sentrytitle]]</nowiki> as the name of your plugin in the Moodle UI, you'll need to create language files for your plugin. Do this by creating the directory <tt>/auth/sentry/lang</tt>, and under it, a directory for each language that your installation needs to support. (Example: <tt>/auth/sentry/lang/en</tt>.) Within each of these language directories, create a file called <tt>auth_sentry.php</tt>. That file should set the desired value for <code>$string['auth_sentrytitle'] for that language (use $string['pluginname'] for Moodle2)</code>. You can also set the plugin description by setting <code>$string['auth_sentrydescription']</code>, and you can also assign other translatable strings that your plugin uses, in these files. '''Note:''' A folder named like '''en''' may not work for everyone. Please refer to the lang folder under your moodle installation directory to get an idea about the language/locale codes used in your moodle installation. For example, the lang folder in own users system contained folders named '''en''' and '''zh-cn'''. He emulated the same in the lang folder of the auth plugin and the plugin picked up the title and description strings immediately. ([[Places_to_search_for_lang_strings|More info on how Moodle handles language]]).
# If you want to configure your plugin through the Moodle UI, implement <tt>config_form()</tt> and <tt>process_config()</tt> in the plugin class. You might find it convenient to use the 'db' plugin as a model for this. The plugin's config settings can then be managed through the Manage authentication page by clicking on the Settings link for that plugin, and the values will be stored in the <tt>mdl_config_plugins</tt> table in the database.

==Interfacing to API's==

=== <tt>authenticate_user_login()</tt>===
That's the main outline, but a lot of interesting stuff happens in <tt>authenticate_user_login()</tt>:

# It gets a list of enabled authentication plugins.
# It looks up the username in the mdl_user table to see if they are allowed to log in, and which authentication plugin handles their login requests. (This will be the plugin that handled their first-ever login request.)
# It creates a user object, which will contain the data from <tt>mdl_user</tt> if the username is known; if not, it will be an empty object.
# It does the following with the authentication plugin (note that for a username unknown to Moodle, it will do these steps for each authenticated plugin until one succeeds or it has tried them all):
## Calls the <tt>user_login()</tt> function provided by that plugin, which returns a boolean value based on whether the credentials authenticate or not. If the result is false (not authenticated), skips the rest of the steps below and continues to the next plugin.
## If the plugin authenticates against an external system (not Moodle's user database), its <tt>update_user_record()</tt> function is called to get the user's name, contact info, etc.
## Creates the Moodle user record if it doesn't already exist.
## Calls the plugin's <tt>sync_roles()</tt> function.
## Notifies each enabled authentication plugin that the user successfully authenticated, by calling each one's <tt>user_authenticated_hook()</tt> function.
# It returns the user object if everything was successful, or false if no plugin was able to successfully authenticate the credentials.

=== <tt>user_login($username, $password)</tt>===
This must be rewritten by plugin to return boolean value, returns true if the username and password work and false if they are wrong or don't exist.

=== <tt>can_change_password()</tt>===
Returns true if this authentication plugin can change users' password.

; '''Return type''' : boolean
; '''Default return value''' : false

=== <tt>change_password_url()</tt>===
Returns the URL for changing the users' passwords, or empty if the default URL can be used.

=== <tt>can_edit_profile()</tt>===
Returns true if this authentication plugin can edit the users' profile.

; '''Return type''' : boolean
; '''Default return value''' : true

=== <tt>edit_profile_url()</tt>===
Returns the URL for editing users' profile, or empty if the defaults URL can be used.

=== <tt>is_internal()</tt>===
Returns true if this authentication plugin is "internal". Internal plugins use password hashes from Moodle user table for authentication.

; '''Return type''' : boolean
; '''Default return value''' : true

=== <tt>prevent_local_passwords()</tt>===
Indicates if password hashes should be stored in local moodle database. This function automatically returns the opposite boolean of what is_internal() returns. Returning true means MD5 password hashes will be stored in the user table. Returning false means flag 'not_cached' will be stored there instead.

; '''Return type''' : boolean
; '''Default return value''' : !$this->is_internal()

=== <tt>is_synchronised_with_external()</tt>===
Indicates if moodle should automatically update internal user records with data from external sources using the information from get_userinfo() method. This function automatically returns the opposite boolean of what is_internal() returns.

; '''Return type''' : boolean
; '''Default return value''' : !$this->is_internal()

=== <tt>user_update_password($user, $newpassword)</tt>===
Update the user's password.

=== <tt>user_update($olduser, $newuser)</tt>===
Called when the user record is updated. It will modify the user information in external database.

=== <tt>user_delete($olduser)</tt>===
User delete requested. Internal user record had been deleted.

=== <tt>can_reset_password()</tt>===
Returns true if plugin allows resetting of internal password.

; '''Return type''' : boolean
; '''Default return value''' : false

=== <tt>can_signup()</tt>===
Returns true if plugin allows resetting of internal password.

; '''Return type''' : boolean
; '''Default return value''' : false

=== <tt>user_signup($user, $notify=true)</tt>===
Sign up a new user ready for confirmation, password is passed in plaintext.

=== <tt>can_confirm()</tt>===
Returns true if plugin allows confirming of new users.

; '''Return type''' : boolean
; '''Default return value''' : false

=== <tt>user_confirm($username, $confirmsecret)</tt>===
Confirm the new user as registered.

=== <tt>user_exists($username)</tt>===
Checks if user exists in external db.

=== <tt>password_expire($username)</tt>===
Returns number of days to user password expires.

=== <tt>sync_roles()</tt>===
Sync roles for this user - usually creator

=== <tt>get_userinfo($username)</tt>===
Read user information from external database and returns it as array.

=== <tt>config_form($config, $err, $user_fields)</tt>===
Prints a form for configuring this authentication plugin. It's called from admin/auth.php, and outputs a full page with a form for configuring this plugin.

=== <tt>validate_form($form, $err)</tt>===
Validate form data.

=== <tt>process_config($config)</tt>===
Processes and stores configuration data for this authentication plugin.

=== <tt>loginpage_hook()</tt>===
Hook for overriding behaviour of login page.

=== <tt>pre_loginpage_hook()</tt>===
Hook for overriding behaviour of prior to redirecting to the login page, eg redirecting to an external login url for SAML or OpenID authentication. If you implement this you should also implement loginpage_hook as the user may go directly to the login page.

=== <tt>user_authenticated_hook($user, $username, $password)</tt>===
Post authentication hook. This method is called from authenticate_user_login() for all enabled auth plugins.

=== <tt>prelogout_hook()</tt>===
Pre logout hook.

=== <tt>postlogout_hook()</tt>===
This method replace the prelogout_hook method to avoid authentication plugins redirects before the user logout event being triggered.
At the moment the only authentication plugin using this method is CAS (SSO).

=== <tt>logoutpage_hook()</tt>===
Hook for overriding behaviour of logout page.

=== <tt>can_be_manually_set()</tt> ===
This function was introduced in the base class and returns false by default. If overriden by an authentication plugin to return true, the authentication plugin will be able to be manually set for users. For example, when bulk uploading users you will be able to select it as the authentication method they use.

=== <tt> loginpage_idp_list() </tt> ===
Override this method and return a list of Identification Providers (IDPs) that your authentication plugin supports. An array of associative arrays containing url, icon and name for the IDP. These will be displayed on the login page and in the login block.

==See also==

* [[Authentication API]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=102070 Overview of entire authentication code flow] forum discussion
* Using Moodle [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]
* Moodle Docs [[:en:Manage authentication|Manage authentication]]
* [[:en:Authentication FAQ|Authentication FAQ]]

[[Category:Authentication]]
[[Category:Plugins]]

[[fr:Méthodes_d'authentification]]

LTI Improvements 3.2 Project

2016-11-12T03:06:09Z

Johnok: Progress at end of project

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* <strike>Upgrade enrol_lti to support LTI v2.0</strike>
* <strike>Ensure enrol_lti member syncronisation task works as expected</strike>
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* <strike>Run the LTI Test suite against Moodle (consumer + provider)</strike>
* Fix auto-closing LTI config window
* Improve interface for managing course tools (teacher's interface)
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item is released
* MDL-53832 Provider LTI 2 is released
* MDL-55825 Memberships is released

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-11-12T02:42:09Z

Johnok:

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* <strike>Upgrade enrol_lti to support LTI v2.0</strike>
* <strike>Ensure enrol_lti member syncronisation task works as expected</strike>
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* <strike>Run the LTI Test suite against Moodle (consumer + provider)</strike>
* Fix auto-closing LTI config window
* Improve interface for managing course tools (teacher's interface)
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item is released
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Currently in integration review.
* MDL-55825 Memberships patch has been created and will be reviewed
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-11-12T02:31:55Z

Johnok: Update after end of project

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* <strike>Upgrade enrol_lti to support LTI v2.0</strike>
* <strike>Ensure enrol_lti member syncronisation task works as expected</strike>
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* <strike>Run the LTI Test suite against Moodle (consumer + provider)</strike>
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item is released
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Currently in integration review.
* MDL-55825 Memberships patch has been created and will be reviewed
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-10-12T07:02:33Z

Johnok: Progress update 12/10/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item is released
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Currently in integration review.
* MDL-55825 Memberships patch has been created and will be reviewed
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-30T05:55:39Z

Johnok: Progress update 30/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item is released
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Waiting for integration review.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-30T05:55:14Z

Johnok: Overview update 30/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* <strike>Content Item support (consumer)</strike>
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. Addressing some integration review points
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Waiting for integration review.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-23T08:22:30Z

Johnok: Progress update 23/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. Addressing some integration review points
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Patch completed. Waiting for integration review.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-13T08:51:42Z

Johnok: Progress update 13/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. Addressing some integration review points
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Need to unit test and
** Proxies & Tool Profiles, launch requests (including LTI1 style) are working. Data persistence logic finished. Additional logic to cover multiple shared tools with library has been added
** All that remains is cross reviewing of some code and increasing unit test coverage.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-08T07:51:05Z

Johnok: Progress update 0809/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. Peer reviewed and addressing concerns.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Need to unit test and
** Proxies & Tool Profiles, launch requests (including LTI1 style) are working. Data persistence logic finished.
** We are currently finishing implementing the library to achieve all LTI2 requirements and matching functionality from old library
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-07T01:43:15Z

Johnok: Progress update 7/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. In peer review after UX review and new language strings
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
** Proxies & Tool Profiles, launch requests (including LTI1 style) are working. Data persistence logic finished.
** We are currently finishing implementing the library to achieve all LTI2 requirements and matching functionality from old library
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-02T06:40:10Z

Johnok: Fix formatting

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* <strike>Offer cartridges in LTI provider</strike>
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. In peer review. Just waiting for language string approval.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
** Proxies are working.
** Launch requests are working.
** LTI1 launches are working
** Finishing implementing the library to achieve all LTI2 requirements
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-01T09:30:53Z

Johnok: Progress update 01/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* -Offer cartridges in LTI provider-
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges is released
* MDL-49609 Content-Item patch is completed. In peer review. Just waiting for language string approval.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
** Proxies are working.
** Launch requests are working.
** LTI1 launches are working
** Finishing implementing the library to achieve all LTI2 requirements
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-09-01T09:29:25Z

Johnok: Update improvements 1/09/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* -Offer cartridges in LTI provider-
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges patch is completed. Waiting for testing.
* MDL-49609 Content-Item patch is completed. In peer review.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
** Proxies are working.
** Launch requests are working.
** LTI1 launches are being added.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-16T08:15:07Z

Johnok: Progress update 16/08/2106

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges patch is completed. Waiting for testing.
* MDL-49609 Content-Item patch is completed. In peer review.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
** Proxies are working.
** Launch requests are working.
** LTI1 launches are being added.
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch is being finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-12T08:07:46Z

Johnok: Progress update 12/08/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges patch is completed, waiting for integration review
* MDL-49609 Content-Item patch finished. Waiting for peer review.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Proxies are working. Launch requests are working. More LTI 2 features will be added next.
* MDL-54548 Membership synchronisation is being looked at in conjunction with LTI2
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch will be finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-10T07:06:41Z

Johnok: Progress update 10/08/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges patch is completed, waiting for integration review
* MDL-49609 Content-Item patch finished. Waiting for peer review.
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Proxies are working. More LTI 2 features will be added next.
* MDL-54548 Membership synchronisation is being looked at in conjunction with LTI2
* MDL-51480 Outcomes 2 patch for the provider has been created. The patch will be finished, with refactoring and testing added if needed.

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-08T03:21:13Z

Johnok: Update progress 08/08/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* MDL-54680 Cartridges patch is completed, waiting for integration review
* MDL-49609 A Content-Item patch was started by Stephen Vickers. The patch has been altered and refactored. Working on automated testing now
* MDL-53832 A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2. Proxies are working. More LTI 2 features will be added next.
* MDL-55457 A bug was found in moodle's consumer that means moodle will not work with the new LTI2 provider or similar tools. It will be fixed in stables ASAP so moodle 3.2 provided tools will work out of the box with older versions of moodle.
* MDL-54548 Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-08T03:17:39Z

Johnok: Add Prototype info to table

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
|prototype = http://prototype.moodle.net/lti/
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for integration review
* A Content-Item patch was started by Stephen Vickers. The patch has been altered and refactored. Working on automated testing now
* A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
* Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-08T03:14:59Z

Johnok: Add discussion

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=335775
|assignee = [[User:John Okely]]
}}

= Summary =
The Learning Tools Interoperability (LTI) provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standards, and as such are missing important functionality, therefore they need usability improvements.

'''Below are a range of issues that have been identified and are being worked on for Moodle 3.2.'''

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for integration review
* A Content-Item patch was started by Stephen Vickers. The patch has been altered and refactored. Working on automated testing now
* A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
* Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-08-04T05:27:58Z

Johnok: Progress update

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=xxx
|assignee = [[User:John Okely]]
}}

= Summary =
The LTI provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standard, are missing important functionality and need usability improvements. A range of issues have been identified and are being worked on for Moodle 3.2.

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for integration review
* A Content-Item patch was started by Stephen Vickers. The patch has been altered and refactored. Working on automated testing now
* A patch has been created using the new LTI library provided by IMS to bring the provider up to LTI 2.
* Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

Tree

2016-08-03T05:56:58Z

Johnok: Fix recommended CSS

{{Moodle 3.1}}The javascript Tree is designed to allow you to create an interactive tree that is accessible, intuitively usable, and consistent with the rest of Moodle's hierarchical interfaces. It is currently used in the Navigation block and Settings block.

The tree is originally based off the [http://oaa-accessibility.org/examplep/treeview1/ tree view example] by the Open Ajax Alliance Accessibility Group. and is designed to comply as much as possible with the [http://www.w3.org/WAI/GL/wiki/Using_ARIA_trees ARIA specification for accessible trees]. For detailed additional information you can read those links.

[[File:TreeExampleNavigation.png|thumb|center|450px|An example use of the tree module]]

== Using the Tree module ==

To create an aria accessible tree, you must instantiate a child AMD module of the core/tree using Require JS.

<code javascript>
define(['jquery', 'core/tree'], function($, Tree) {
return {
init: function() {
new Tree("css/jquery selector of the tree container");
}
};
});
</code>

To define a node in your structure, add the "treeitem" role. If the node has children, it must have a child html element with the role "group" to contain it's children.

<code xml>
<div role="treeitem">This is an item which has children
<div role="group">
<div role="treeitem">A child</div>
<div role="treeitem">Another child</div>
</div>
</div>
</code>

In the CSS for your page or module, you will need to target the aria-expanded attribute of group items to hide and show them as tree.js does not assume knowledge of how you want expanding and collapsing to work. For most cases, this will be sufficient:

<code css>
[aria-expanded="false"] > [role="group"] {
display: none;
}
</code>

Tree.js will handle the accessible controls for navigating the tree as well as expanding and collapsing nodes. The controls are as follows:
* Up: Select the previous visible tree item.
* Down: Select next visible tree item.
* Left: Collapse the currently selected parent node if it is expanded. Move to the previous parent node (if possible) when the current parent node is collapsed.
* Right: Expand the currently selected parent node and move to the first child list item.
* Enter: Toggle the expanded or collapsed state of the selected parent node. If it is a link, follow the link
* Home: Select the root parent node of the tree.
* End: Select the last visible node of the tree.
* Tab: Navigate away from tree.
* Space: Expand and collapse node
* * (asterisk on the numpad): Expand all group nodes.
* Clicking on a parent node will toggle its expanded or collapsed state.

== Code ==
* Code location: lib/amd/src/tree.js
* Examples:
** blocks/navigation/amd/src/navblock.js
** blocks/settings/amd/src/settingsblock.js

== See also ==

* [[Javascript Modules]]
* [[Useful core Javascript modules]]

[[Category:Javascript]]

LTI Improvements 3.2 Project

2016-07-29T08:43:02Z

Johnok: Content item is up

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=xxx
|assignee = [[User:John Okely]]
}}

= Summary =
The LTI provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standard, are missing important functionality and need usability improvements. A range of issues have been identified and are being worked on for Moodle 3.2.

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for peer review
* A Content-Item patch was started by Stephen Vickers. We are working on completing the patch.
* Upgrading enrol_lti to support LTI v2.0 has a proof of concept for offering proxies. We are currently looking into using a new library offered by IMS, seeing if it's appropriate for what we need.
* Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. You can configure a tool type when you add it using Content-item

LTI Improvements 3.2 Project

2016-07-28T04:05:13Z

Johnok: Add Prototype info

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=xxx
|assignee = [[User:John Okely]]
}}

= Summary =
The LTI provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standard, are missing important functionality and need usability improvements. A range of issues have been identified and are being worked on for Moodle 3.2.

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for peer review
* A Content-Item patch was started by Stephen Vickers. We are working on completing the patch.
* Upgrading enrol_lti to support LTI v2.0 has a proof of concept for offering proxies. We are currently looking into using a new library offered by IMS, seeing if it's appropriate for what we need.
* Membership synchronisation is being looked at in conjunction with LTI2

==Prototype==
The [http://prototype.moodle.net/lti/ work in progress prototype] is available to view on the prototype site.
You can add tools via tool proxy, and via cartridge. Content-Item will be added soon.

LTI Improvements 3.2 Project

2016-07-27T03:19:51Z

Johnok: Update progress 27/07/2016

{{Infobox Project
|name = Improvements to LTI for 3.2
|state = Developing
|tracker = MDL-54679
|discussion = https://moodle.org/mod/forum/discuss.php?d=xxx
|assignee = [[User:John Okely]]
}}

= Summary =
The LTI provider was added to Moodle 3.1 - but unfortunately our LTI provider and consumer do not support the same standard, are missing important functionality and need usability improvements. A range of issues have been identified and are being worked on for Moodle 3.2.

== Improvements ==
The targeted improvements for 3.2 are:
* Offer cartridges in LTI provider
* <strike>Support standard icon element when importing LTI cartridges</strike>
* Upgrade enrol_lti to support LTI v2.0
* Ensure enrol_lti member syncronisation task works as expected
* Content Item support
* Add support for LTI Outcomes Management 2 services
* Caliper Analytics
* Run the LTI Test suite against Moodle (consumer + provider) and create issues for any failures (in this Epic)
* Fix auto-closing LTI config window
* Improve interface for managing course tools
* Add support for services via LTI1 (LTI1.2 spec)
* Improve accessibility of new LTI admin screen

To see the most recent set of issues and status of the project see https://tracker.moodle.org/browse/MDL-54679

==Progress==
* Cartridges patch is completed, waiting for peer review
* A Content-Item patch was started by Stephen Vickers. We are working on completing the patch.
* Upgrading enrol_lti to support LTI v2.0 has a proof of concept for offering proxies. We are currently looking into using a new library offered by IMS, seeing if it's appropriate for what we need.
* Membership synchronisation is being looked at in conjunction with LTI2

User:John Okely

2016-07-14T04:00:16Z

Johnok: Created page with "Developer at Moodle HQ"

Developer at Moodle HQ

Tree

2016-05-19T05:58:31Z

Johnok: Fix escaping

{{Moodle 3.1}}The javascript Tree is designed to allow you to create an interactive tree that is accessible, intuitively usable, and consistent with the rest of Moodle's hierarchical interfaces. It is currently used in the Navigation block and Settings block.

The tree is originally based off the [http://oaa-accessibility.org/examplep/treeview1/ tree view example] by the Open Ajax Alliance Accessibility Group. and is designed to comply as much as possible with the [http://www.w3.org/WAI/GL/wiki/Using_ARIA_trees ARIA specification for accessible trees]. For detailed additional information you can read those links.

[[File:TreeExampleNavigation.png|thumb|center|450px|An example use of the tree module]]

== Using the Tree module ==

To create an aria accessible tree, you must instantiate a child AMD module of the core/tree using Require JS.

<code javascript>
define(['jquery', 'core/tree'], function($, Tree) {
return {
init: function() {
new Tree("css/jquery selector of the tree container");
}
};
});
</code>

To define a node in your structure, add the "treeitem" role. If the node has children, it must have a child html element with the role "group" to contain it's children.

<code xml>
<div role="treeitem">This is an item which has children
<div role="group">
<div role="treeitem">A child</div>
<div role="treeitem">Another child</div>
</div>
</div>
</code>

In the CSS for your page or module, you will need to target the aria-expanded attribute of group items to hide and show them as tree.js does not assume knowledge of how you want expanding and collapsing to work. For most cases, this will be sufficient:

<code css>
[role="group"] {
display: none;
}
[role="group"][aria-expanded="true"] {
display: inline-block;
}
</code>

Tree.js will handle the accessible controls for navigating the tree as well as expanding and collapsing nodes. The controls are as follows:
* Up: Select the previous visible tree item.
* Down: Select next visible tree item.
* Left: Collapse the currently selected parent node if it is expanded. Move to the previous parent node (if possible) when the current parent node is collapsed.
* Right: Expand the currently selected parent node and move to the first child list item.
* Enter: Toggle the expanded or collapsed state of the selected parent node. If it is a link, follow the link
* Home: Select the root parent node of the tree.
* End: Select the last visible node of the tree.
* Tab: Navigate away from tree.
* Space: Expand and collapse node
* * (asterisk on the numpad): Expand all group nodes.
* Clicking on a parent node will toggle its expanded or collapsed state.

== Code ==
* Code location: lib/amd/src/tree.js
* Examples:
** blocks/navigation/amd/src/navblock.js
** blocks/settings/amd/src/settingsblock.js

== See also ==

* [[Javascript Modules]]
* [[Useful core Javascript modules]]

[[Category:Javascript]]