The Moodle Tracker is our database for recording and managing all Moodle development issues - bugs, improvements and feature requests.
For an intro guide to the tracker, see Tracker introduction.
To do anything more than browsing and searching in the tracker, you'll need to create an account and then login.
Tracker groups and permissions
There are a number of groups used to define the potential of users in Tracker. Here are some important ones.
|Name||Jira group||Potential||How to become one|
|Users||jira-users||Users can create new issues, comment on issues, vote for issues, link issues, attach files, create sub-tasks and watch issues.||Anyone who creates a tracker account becomes a member of the Users group.|
|Moodle Security||moodle-security||Trusted developers and administrators who need to work on security issues that are hidden from normal users. See Moodle security procedures.||This is generally limited to developers at Moodle HQ and Partner organisations. People wishing join the Moodle Security group should email email@example.com with the reasons for your request.|
|Developers||jira-developers||Developers can edit issues and assign issues to themselves. They are also able to request peer reviews. They cannot submit code directly for integration review, but an HQ staff member or component lead can do this after a satisfactory peer review. See Process.||People wishing to join the Developers group should be able to demonstrate a history of contributing patches to issues.|
When a developer's first patch is integrated, tested and the issue is closed, they are added to the group and set as issue assignee.
If that doesn't happen automatically, please send an email to firstname.lastname@example.org with your tracker username and links to issues where you have contributed patches.
|Integration requesters||pull-requesters||Developers can send issues for integration review. See Process.||This role is reserved for Moodle HQ developers and component leads.|
|Integration testers||pull-testers||Users that can tests issues under integration and pass/fail them. See Process.||Usually reserved for HQ developers and external testers.|
You can browse a project without being logged in to Tracker, however you will be to unable edit or comment on bugs.
When creating an issue
There are a few more projects, but these are the main ones.
|Tracker is used for multiple projects.|
|Summary||A brief, concise description of the problem.||When the issue is about applying an existing solution to another, usually older, branch (namely "backport"), please use the summary of the existing solution plus its issue number (i.e. "Fix forum alignment (backport of MDL-99999)").|
|Description||A full and complete description of the issue including:|
|Component/s||The area(s) in Moodle which is affected by the issue.||Select |
When editing an issue
Once an issue has been created, the following additional fields are able to be changed/set by editing the issue. Not all users can edit all fields.
|Reporter||The person who logs the bug.|
This field is automatically filled by Tracker.
|Assignee||The person who will fix the issue. The assignee should be set when there is a definite intention to complete the issue.|
|Peer reviewer||The person who will check the fix at the code level. See Peer-review.|
|Integrator||The person who will integrate the code into the Moodle codebase. See Integration-review.|
|Tester||The person who will test the solution at a functional level, according to the test instructions provided. See Testing.|
|Environment||The operating system, server and/or browser specifications if applicable to this bug.||Note that the database is specified separately in the database field below.|
|Database||If applicable to the bug, identify the database type.|
|Testing instructions||The steps that a tester should follow to achieve the expected behaviour after the issue has been resolved.|
|Workaround||A way to achieve the desired functionality by other means.|
|Attachment||Patch files, Screenshots, example backups and other related files|
|URL||If possible, provide a URL address that demonstrates an example of this bug.|
|Epic Name||A short name given to an issue of type Epic so that linked issues can be grouped by this name. It should only be a few words at most.||Only applies to issues of type Epic.|
|Epic Link||A link to an Epic issue. This can be added by providing the issue ID or Epic name. It is a way of organising related issues as part of a project.||Only applies to issues that need to be collected together for a project.|
|Labels||See Tracker issue labels.|
|Pull...||Links to a code solution in a Git repository.|
|Documentation link||URL of related documentation.||When changes require documentation to be updated, this field should be filled.|
When closing an issue
|Resolution||Issues that may/must have the Fixed versions field filled:||This field is only displayed when resolving or closing a bug.|