Олег Давидович: 1 версия импортирована

2024-10-18T06:46:04Z

1 версия импортирована

← Предыдущая версия	Версия от 06:46, 18 октября 2024
(нет различий)

1>Tim@horizoneducationnetwork.org: clean up, typos fixed: transfered → transferred

2021-09-22T15:17:02Z

clean up, typos fixed: transfered → transferred

Новая страница

==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===
* [[Tracker module/Bug recollection form|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==

[[Tracker module/Capabilities|Capabilities for Tracker module]]

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

Tracker module - История изменений

Олег Давидович: 1 версия импортирована

1>Tim@horizoneducationnetwork.org: clean up, typos fixed: transfered → transferred