Note: You are currently viewing documentation for Moodle 3.9. Up-to-date documentation for the latest stable version of Moodle may be available here: Tracker module.

Tracker module: Difference between revisions

From MoodleDocs
m (lien vers la doc française)
 
(7 intermediate revisions by one other user not shown)
Line 24: Line 24:
* Ticket dependancy chaining
* Ticket dependancy chaining
* Messaging threads (globally disablable) attached to tickets
* 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===
===Priority related features===
Line 29: Line 33:
* Managing ticket priority (controls are active when choosing priority as ordering criteria)
* Managing ticket priority (controls are active when choosing priority as ordering criteria)
* Asking for priority raise from the owner of the ticket
* 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 functions===
Line 47: Line 89:
==Screens==
==Screens==
===Common user screens===
===Common user screens===
* [[Tracker_module/Bug recollection form|Bug recollection form]]
* [[Tracker_module/Bug recollection form | Ticket recollection form]]
* Viewing bug list
* Viewing ticket list
** Exploring bug list (non manager mode)
** Exploring ticket list (non manager mode)
** Searching a bug
** Searching a ticket
** Viewing a bug description
** Viewing a ticket description
* User profile, stats and shortcuts
* User profile, stats and shortcuts
** My preferences : choosing on which events to be notified
** My preferences : choosing on which events to be notified
** My watches : managing which bug entries I receive notifications from
** My watches : managing which entries I receive notifications from
** My searches : managing stored search queries for my own
** My searches : managing stored search queries for my own


===Resolver screens===
===Resolver screens===
* Viewing bug list
* Viewing ticket list
** Exploring bug list (manager mode)
** Exploring ticket list (manager mode)
** Editing a bug entry
** Exploring tickets assigned to *me*
** Editing a ticket entry


===Administrator screens===
===Administrator screens===
Line 72: Line 115:


[[Category:Contributed code]]
[[Category:Contributed code]]
[[fr:Module Tracker]]
[[fr:Tracker]]

Latest revision as of 13:44, 13 October 2012

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, transfered).
  • 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