MoodleDocs - User contributions [en]

Web services

2020-10-30T17:47:58Z

Trott: /* How it works */

=== How it works ===
This example will give you an idea of how our web services infrastructure works.
#The client sends a username and password to the web service login script.
#The script returns a token for that user account.
#The client calls a particular web service function on a protocol server including the token .
#The protocol server uses the token to check that the user can call the function.
#The protocol server calls the matching external function, located under the \component\external namespace (previously in a externallib.php file inside the relevant module).
#The external function checks that the current user has_capability to do this operation.
#The external function calls the matching Moodle core function (in lib.php usually).
#The core function can return a result to the external function.
#The external function will return a result to the protocol server.
#The protocol server returns the result to the client.

== Developer documentation==
The full API can be found on any Moodle sites under ''' Administration block > Plugins > Web services > API Documentation'''.

'''Note:''' Additional services are available for uploading and downloading files which are not in the API Documentation - they are accessed in a different way. See [[Web services files handling]]

* [[How to contribute a web service function to core]]
* [[Adding a web service to a plugin| Adding a web service to your plugin]]
* Code example: [https://gist.github.com/timhunt/51987ad386faca61fe013904c242e9b4 Adding a web service, using APIs] by (Tim Hunt)
* [[Creating a web service client | Implement a web service client]]
* [[Web services files handling]]
* [[Web_services_Roadmap | Web service Listing & Roadmap]]

== Specification and brainstorming ==
* [[External services security | External services security]]
* [[External services description | External services description]]

== See also ==
* [[Web_service_API_functions|Web service API functions]]
* [[:en:Web_services_FAQ|Web services FAQ]]
* [[:en:How_to_create_and_enable_a_web_service|How to create and enable a web service]]
* [[:en:Enable mobile web services|How to enable the mobile web service]]
* [[:en:Web_services|Web services user documentation]]
* [http://www.slideshare.net/juanleyva/mastering-moodle-web-services-development Mastering Moodle Web Services development] - Last session of the Hackfest in the MoodleMoot UK 2016

[[Category:Web_Services]]

Moodle architecture

2018-08-22T18:27:07Z

Trott: /* What is Moodle? */ fix typo

The aim of this document is to quickly give an overview of how the Moodle works at a technical level. Hopefully this will be helpful to Administrators and Developers. However, to actually do Moodle development you will have to study the code in much more detail than is provided here. See the [[Developer_documentation|developer documentation]].

==What is Moodle?==

Moodle is a Learning Management System, Course Management System, or Virtual Learning Environment, depending on which term you prefer. Its goal is to give teachers and students the tools they need to teach and learn. Moodle comes from a background of [[:en:Pedagogy|Social Constructionist pedagogy]], however, it can be used to support any style of teaching and learning.

There are other types of software systems that are important for educational institutions, for example ePortfolios, Student Information Systems and Content repositories. Generally, Moodle does not try to re-invent these areas of functionality. Instead, it tries to be the best LMS possible, and then interoperate gracefully with other systems that provide the other areas of functionality. It is, however, perfectly possible to use Moodle as a stand-alone system, without integrating it with anything else.

Moodle is a web application written in PHP. Moodle is open source. Copyright is owned by individual contributors, not assigned to a single entity, although the company Moodle Pty Ltd in Perth Australia, owned by Moodle's founder Martin Dougiamas, manages the project.

==Overview of a Moodle installation==

A Moodle installation comprises the Moodle code executing in a PHP-capable web server; a database managed by MySQL, PostgreSQL, Microsoft SQL Server, MariaDB, or Oracle; and a file store for uploaded and generated files (the moodledata folder).

All three parts can run on a single server; or they can be separated with many load-balanced web-servers, a database cluster, and a file-server; or anywhere between those extremes.

Moodle is designed to be simple to install on any server that meets these basic requirements. Moodle self-installs once the code has been copied to the web server and a blank database created (see [[:en:Installing Moodle]]). Similarly, Moodle can always self-upgrade from one version to the next (see [[:en:Upgrading]]).

==Moodle as a modular system==

Like many successful open source systems, Moodle is structured as an application core, surrounded by numerous plugins to provide specific functionality. Moodle is designed to be highly extensible and customizable without modifying the core libraries, as doing so would create problems when upgrading Moodle to a newer version. So when customizing or extending your own Moodle install, always do so through the plugin architecture.

Plugins in Moodle are of specific types. That is, an authentication plugin and an activity module will communicate with Moodle core using different APIs, tailored to the type of functionality the plugin provides. Functionality common to all plugins (installation, upgrade, permissions, configuration, ...) are, however, handled consistently across all plugin types.

The standard Moodle distribution includes Moodle core and a number of plugins of each type, so that a new Moodle installation can immediately be used to start teaching and learning. After installation a Moodle site can be adapted for a particular purpose by changing the default configuration option, and by installing add-ons or removing standard plugins. Most add-ons that have been shared publicly are listed in the [http://moodle.org/plugins/index.php Moodle Plugins Directory].

Physically, a Moodle plugin is just a folder of PHP scripts (and CSS, JavaScript, etc. if necessary). Moodle core communicates with the plugin by looking for particular entry points, often defined in the file <tt>lib.php</tt> within the plugin.

* See [[Communication Between Components]] on how different Moodle components and plugins communicate with each other.

==An overview of Moodle core==

Moodle core provides all the infrastructure necessary to build a Learning Management System. It implements the key concepts that all the different plugins will need to work with. These include:

'''Courses and activities:'''
A Moodle course is a sequence of activities and resources grouped into sections. Courses themselves are organized into a hierarchical set of categories within a Moodle site.

'''Users:'''
In moodle, users are anyone who uses the moodle system. In order to participate in course users need to be enrolled into course with a given role, such as:

*Students
*Teachers

'''Course enrolment''':

*Enrolment gives user the possibility to participate in course as a student or teacher.

'''User functionality in moodle:'''

*User roles in moodle: Roles assigned to users give them a set of capabilities in given context. For example: Teacher, Student and Forum moderator are examples of roles.
*User's capabilities in moodle: A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.
*Context: A context is a "space" in the Moodle, such as courses, activity modules, blocks etc.
*Permissions: A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.

'''Added facilities provided by moodle:'''

*Creation and editing of user profiles: In moodle, the moment an user creates his account, a profile is created for that user. The user needs to fill in his initial details for completing his profile. The user generally always have the permission to edit his own profile anytime on moodle.
*Groups and cohorts: Cohorts, or site-wide groups, enable all members of a cohort to be enrolled in a course in one action, either manually or synchronised automatically.
*Enrolments and access control: Users are generally enrolled into some courses and according to their permission settings and the groups to which they belong, they have limited access on moodle.

'''A bit more about moodle:'''

*Activity and course completion: The activity completion system allows activities such as Quizzes, SCORM modules, etc. to be marked complete when specified conditions are met.
*Navigation, settings and configuration: The Navigation block provide easy access to view various sections of the Moodle site and includes:
**My home - a personalised home page displaying links to the courses a user is associated with and activity information (such as unread forum posts and upcoming assignments)
**Site pages - links to site pages and resources from the front page of Moodle
**My profile - quick links allowing a user to view their profile, forums posts, blogs and messages as well as manage their private files
**My courses - lists (by course shortname) and links to courses the user is associated with. Click the course's shortname to view the front page of the course or use the arrows to navigate quickly to a specific section, resource or activity.

'''JavaScript library:'''
*Moodle has adopted the Yahoo User Interface library. There is also a nice system for loading the additional JavaScript files required by each page.

'''Upgrading moodle:'''
Moodle can be upgraded in four simple steps:

#Make sure that your server can run the latest Moodle version
#You should always be prepared to "roll back" if there's an issue with your data or some custom code you've added. So before committing, create a test install and always make backups.
#At this stage you can replace the Moodle code on your server with the version you downloaded and check for the plugins.
#Perform the upgrade by triggering the upgrade from the admin page.

(More information about upgrading can be found here : [[:en:Upgrade overview|Upgrade overview]])

'''Logs and statistics in moodle:'''
*Statistics in moodle: The statistics graphs and tables show how many hits there have been on various parts of your site during various time frames. They do not show how many distinct users there have been. They are processed daily at a time you specify. You must enable statistics before you will see anything.
*Log in moodle: Logs in Moodle are activity reports. Logs are available at site level and course level.

==The most important plugin types==

Please see the page [[Plugin types]] for the full list. A selection of the most common ones is highlighted here.

===Activities and resources===

Activities and resources are the most basic individual components that make up a course and are the main tools for teaching and learning. Some examples of resources are: pages, links and IMS content packages. Examples of activities include: forums, wikis, quizzes, and assignments.

Activities are by far the largest type of plugin in terms of amount of code. A forum or wiki system could be a software project in its own right. Both activities and resources are installed in the <tt>mod</tt> folder.

===Blocks===

Blocks are small bits of interface functionality that can be added to (normally the sides of) pages. Many blocks provide additional views of data stored and modified elsewhere. Blocks live in the <tt>blocks</tt> folder.

===Themes===

The overall visual style of a Moodle site, a particular course, or all courses in a category, can be changed by selecting a different theme at these different levels. Themes are the standard way of making aesthetic changes to your Moodle application, decoupling presentation from content and functionality.

Themes live in the <tt>theme</tt> folder, and published themes are listed in the [http://moodle.org/mod/data/view.php?id=6552 Themes database].

===Language packs===

Moodle is internationalised. That is, you can get language packs for many different languages. Language packs are normally downloaded and installed via the Moodle administration screens, but they can also be downloaded manually from [http://download.moodle.org/langpack/ Moodle.org: language packs].

Administrators can also manually change any of the standard user interface strings if the terms used in the installed language pack are not appropriate.

===Course formats===

control how the structure of the course, a sequence of activities grouped into sections, is presented to the users. Course formats live in the <tt>course/format</tt> folder.

===Authentication plugins===

control how users log in. Moodle can manage usernames and passwords itself, or use those stored in LDAP or another database. Alternatively, Moodle can use a number of single-sign-on schemes. Authentication plugins live in the <tt>auth</tt> folder.

===Enrolment plugins===

control which users are enrolled in which courses. Again this can be by synchronising with another system, perhaps a student information system, or it can be tracked internally by Moodle. Enrolment plugins live in the <tt>enrol</tt> folder. (Moodle was created by an Australian, so enrol is the correct spelling ;-).)

===Repository plugins===

Ways for users to get content (files) into Moodle, either by uploading from their hard drive, or by getting the file from another location on the Internet, perhaps Drop Box, Google Docs, or Flickr. Repository plugins live in the <tt>repository</tt> folder.

==How Moodle code is organised==

Moodle mostly follows a [http://martinfowler.com/eaaCatalog/transactionScript.html transaction script] approach. That is, suppose you are looking at a Forum. The URL will be <tt>.../mod/forum/view.php?id=1234</tt>. and <tt>mod/forum/view.php</tt> the PHP script that generates that page. One could argue that transaction script is not an appropriate pattern for an application as complex as Moodle. However, it is a very natural architecture for a PHP application, and Moodle is an aggregate of many different plugins, rather than a single complex application.

Behind that basic transaction script approach, a lot of the core functionality has been refactored out into libraries (mostly in the <tt>lib</tt> folder). This provides elements of a [http://martinfowler.com/eaaCatalog/domainModel.html domain model]. The Moodle project started before PHP could handle object-oriented code, however, so don't expect an object-oriented domain model except in some of the more recent parts of the Moodle code.

There are two layers used to separate presentation from the business logic. The outer layer is the theme (see above) which controls the more visual aspects of the Moodle interface. Then there are renderer classes which generate the HTML to be output from the data supplied by the transaction scripts and the domain model. Unfortunately, neither PHP, nor the Moodle architecture, enforces a clear separation of the UI layer. It is possible for sloppy developers to make a mess, and this has happened in the past. The code in the standard Moodle distribution is gradually being cleaned up.

==The Moodle database==

The Moodle database comprises many tables (more than 250) because the whole database is an aggregate of the core tables and the tables belonging to each plugin. Fortunately, this large structure is understandable, because the tables for one particular plugin typically only link to each other and a few core tables. See [[Database_schema_introduction|Database schema introduction]] for more information.

The Moodle database structure is defined in <tt>install.xml</tt> files inside the <tt>db</tt> folder in each plugin. For example <tt>mod/forum/db/install.xml</tt> contains the database definition for the forum module. <tt>lib/db/install.xml</tt> defines the tables used by Moodle core. The <tt>install.xml</tt> files contain comments that should explain the purpose of each table and column. These comments can be turned into human-readable documentation by going to Site administration -> Development -> XMLDB editor in your Moodle installation, and clicking on the [Doc] link.

==See also==

* [[:en:Administrator documentation]]
* [[Developer_documentation|Developer documentation]]
* [[Database_schema_introduction|Database schema introduction]]
* [http://moodle.org/mod/data/view.php?id=6009 Modules and plugins] and [http://moodle.org/mod/data/view.php?id=6552 themes] databases
* [http://moodle.org/mod/forum/discuss.php?d=64465 Forum thread with a vigorous argument about whether an architecture document is a good idea, which eventually lead to this page being rewritten]
* [http://www.aosabook.org/en/moodle.html The chapter of The Architecture of Open Source Applications about Moodle]

[[Category:Coding guidelines]]

Process

2018-08-22T18:19:20Z

Trott: /* Scrum */ fix typo

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

[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page 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. Note that, apart from that, every component also has some [[Component Leads|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.

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

Coverage with automated tests ([[PHPUnit]] or [[Behat|Behat_integration]]) is mandatory for new features.

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 (read the [[Testing instructions guide|instructions guide]]) 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 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===

Once your fix is done, it should be submitted for a peer review.

The following information is necessary for this:
* Information about your public git repository
** repository URL
** branch name(s)
** diff URL
* [[Testing instructions guide|Testing instructions]] for how to verify your fix is correct.

If you have never contributed to Moodle and don't see a button "Request peer review", just comment on the issue with the above information. The component lead or another user with sufficient privileges will then send the issue up for peer review 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 yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker

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