Tracker module

Module overview | ]

This module provides a light but full featured ticket tracker within a Moodle environment. This tracker could be used by administrators to collect issues from Moodle end users, or may be as a real bug tracking tool for project oriented activities.

Recently has the semantics of the string being reviewed to allow a more general scope use of the tracker, whenever the need of "service ticketting" appears.

The internal tracker module of Moodle have following features :

Tracker configuration | ]

• Setting up ticket form elements
• File attachment fields available

Ticket management | ]

• Collecting tickets
• Assigning tickets to assignees
• Status workflow (posted, opened, working, testing, resolved, blocked, abandonned, transferred).
• Suscribing to ticket's notifications
• Notifying changes to suscribers
• Complete personal management of notifications and subscriptions
• Summary of capabilities and owned tickets
• Separating concluded tickets (resolved, abandonned, transferred) from working tickets (posted, working, blocked)
• Ticket dependancy chaining
• Messaging threads (globally disablable) attached to tickets

Default assignee | ]

A user that is known as "resolver" can be assigned "as default" to all incoming tickets.

Priority related features | ]

• Managing ticket priority (controls are active when choosing priority as ordering criteria)
• Asking for priority raise from the owner of the ticket

State change tracking | ]

the tracker records and displays history of events that were attached to the ticket.

Subtracker binding | ]

As this ticket has no internal ticket classification in sub tracks, the usual setup is to use several instances bound into a super/sub-tracker structure. Each tracker can have subtrackers to which some incoming ticket can be rerouted.

It is thus sinple to provide a global input tracker a manager will use to collect "everything" and then dispatch each ticket.question to the appropriate instance.

Ticket events | ]

• POSTED: Ticket has been posted by originator and not yet viewed by anyone.
• OPEN: Someone has opened the ticket.
• RESOLVING: Some assigned user or ticket manager starts working on the track.
• WAITING: Something blocks (external request) the work on this ticket.
• TESTING: Solution is proposed, but needs to be tested by originator
• RESOLVED: Issue is solved. This should be the final state in short life-cycle.
• ABANDONNED: Issue is abandonned as no more relevant.
• TRANSFERED: Query has been trasnfered to another tracker
• PUBLISHED: In case resolution only affects a qualification environmet, published tells the solution has been published to production instance.
• VALIDATED: Solution is finally checked as operative in production (definitive) environment. This should be the final state in long life-cycle.

Short Life-Cycle | ]

This is to apply in "single step work process", when first publication of the solution is enough to get things approved.

POSTED > OPEN > RESOLVING > TESTING > RESOLVED

Long Life-Cycle | ]

This is to apply in "dual step work process", that is approval is first agreed on a pre-production worplace, then published for effective production

POSTED > OPEN > RESOLVING > TESTING > RESOLVED > PUBLISHED > VALIDATED

Moodle Network functions | ]

• Moodle Network across cascading from a tracker to a remote tracker (local cascade works either within the same Moodle instance).

Local Roles Management | ]

Tracker has its own internal user profiles, that will merely separate population into:

• Administrators: will be allowed to change the form structure and all settigns of the tracker instance
• Resolvers: are allowed to change the ticket status and thus closing or resolving tickets. They also can assign tickets to developers.
• Developers: usually people that will handle the ticket and search for a solution.
• Requirers: any user able to post a ticket.

Internal tracker roles are bound to Moodle roles through tracker specific capabilities. See the tracker capabilities documentation beneath for more information.

Screens | ]

Common user screens | ]

• Ticket recollection form
• Viewing ticket list
  • Exploring ticket list (non manager mode)
  • Searching a ticket
  • Viewing a ticket description
• User profile, stats and shortcuts
  • My preferences : choosing on which events to be notified
  • My watches : managing which entries I receive notifications from
  • My searches : managing stored search queries for my own

Resolver screens | ]

• Viewing ticket list
  • Exploring ticket list (manager mode)
  • Exploring tickets assigned to *me*
  • Editing a ticket entry

Administrator screens | ]

• Activity summary
• Managing bug tracking form elements
• Configuring tracker local or remote cascade

Capabilities | ]

Capabilities for Tracker module

Source: docs.moodle.org/503/en/Tracker module — MoodleDocs (GPL) · Imported 2026-11-10.