Page History

Install plugin Trouble ticket system

To install the plugin copy the jar file to the WEB-INF/lib directory inside your JIRA web application.
The plugin has been tested and confirmed to work for JIRA versions 3.12.x and 3.13.x

To use dynamic picker fields (LINK) you need to create text files on the server that contain field values on separate rows for each separate field you want use. The files need to have read and write provileges for the user JIRA is running as. If you want to use something other than flat files for the data source for the dynamic picker fields you need to code your own class implementing the DynamicPickerService interface and configure the service to use the class in the atlassian-plugin.xml.

Create screens

TTS needs these different screens:

• TTS screen
• TTS screen - Resolve
• TTS screen - Close
• TTS screen - Opening

At this point we can make a copy of JIRA default screen and name it TTS Screen. Then remove all the fields except Summary, Issue type, Priority, Assignee, Reporter and Description. Then copy that screen configure and name them as above.

We'll configure them later when custom fields have been created.

Administration -> Screens

Create issue types

For TTS we commonly need at least two issue types: "Scheduled" and "Unscheduled". Create these two issue types and Issue type scheme "TTS" to hold them

Administration -> Issue types

Create workflow

Create new status Opening

We'll need this status for the first workflow step so that we can create issue quickly and assign an ID without having to fill all the information.

Administration -> Statuses

Create workflow TTS

TTS workflow steps and transitions:

To create this workflow we need to:

• delete all transitions from the steps we don't need
• delete these steps
• create new step Opening, linked to status Opening
• transition Create is not shown on the list:
  • click Open and then transition Create, point it to Opening

Administration -> Workflows

Set workflow transition screens

• TTS Screen - Resolve: Resolve ticket, Update ticket (resolved -> resolved)
• TTS Screen - Close: Close ticket, Update ticket (closed -> closed)
• TTS Screen: other transitions

Configure other screens

Most of the screens are set in workflow. However, we need to set screens for actions not handled in workflow.

Create screen scheme TTS Screen Scheme. Setup:

Administration -> Sreen schemes

Create custom fields

TTS uses several custom fields. They use JIRA default field types (text field, checkboxes) or special TTS field types.

Custom fields can be configured as globals (Available context) if the JIRA used only or mainly for TTS. If TTS is one project among others, it is best to setup the fields for just that project.

When creating the custom fields you can add them all to screens with TTS prefix. We can order the fields later and remove those that are not valid for all of the screens.

Fields using default types

These fields could be created and placed on screens without TTS plugin installed. However, their values can be used in some of the validators and post functions of the TTS plugin.

TTS special types

These fields have special capabilities and they come with TTS plugin(s).

Functional fields (not manually editable)

Some of the fields are used to hide other fields or to align them horizontally. This way we can keep JIRA edits in minimum and distribute TTS as a plugin.

Create Issue type screen scheme

With issue type screen scheme we connect screens to issues. TTS basic setup doesn't need different screen for each issue type, but option is available.

You can order the fields on in any order you choose. However, here is an example of how to layout the screen:

• Create two tabs: Main and Knowledge management

Tab Main:

Tab Knowledge management:

Order horizontally

To put some of the fields on the same row, you first need to find out the field id of each field. You can do that on page Administration - Custom fields by selecting Configure and picking the id from the url. Then edit the options of the ordering field (eg. HF 1):
The Horizontal Fields custom field options take two parameters source and target. The source parameter accepts a comma separated list of html element ids. We have used the elements with the id %fieldId%FieldArea (for example customfield_10000FieldArea or assigneeFieldArea). The target parameter accepts a single html element id.

Hide fields

In Edit mode (normally every transition screen is thought of being in the Edit mode) TTS should hide some of the fields and in View mode its should hide other fields. The Field Hider custom field options take two parameters view and edit. Both of the parameters accept a comma separated list of html elemement ids same as the source parameter of the Horizontal Fields custom field options.

Screen differences

• TTS Screen - Opening: only fields Summary, Issue type
• TTS Screen - Resolve: as in TTS Screen + Customer info (on tab Customer), Fixer, Service info (SLA) (on tab Supplier), Supplier info (on tab Supplier)
• TTS Screen - Close: as in Resolve + Final ticket report

Complete screen

As shown in transition Resolve

Validators

Validators are connected to workflow transitions.

Administration - Workflows

All transitions

Required Fields Validator

Mark the fields you want to be required for this transition. Fields required like this are not shown as such in the user interface but if a user tries to perform the transition and the field has not been filled, the user will be notified of the unfilled required fields.

Problem Start/End Validator

Select the corresponding fields for Problem Start/End, Maintenance Window Start/End and Outages. Select if it's required that outage end or problem end is input.

Post fuctions

All transitions

Autofill problem start and end

Select the fields that correspond to the fields Manually editable Problem Start, Manually editable Problem End, Calculated Problem Start, Calculated Problem End, Outages.

Calculate total outage

Select the fields that correspond to the Outages field and the Total outage field.

Transitions Open ticket and Update Ticket (from Open to Open)

Auto-populate Next Action Due Date

Select the issue type for which you want to populate Next action due date from maintence window start if left empty. Then select the fields which correspond to the next action due date and maintenance window start.

Build the project

To use TTS in a project, you have to set TTS version for:

• Issue type scheme
• Issue type screen scheme
• Workflow scheme
• Permission scheme (recommended)
• Notification scheme (optional)

Permissions

Permission management of a TTS project is basically same than in any other JIRA project. Only thing you absolutely should do is disabling Edit permission. TTS workflow has a transition "Update ticket" we use for that. Using workflow transition enables post functions and more flexible event handling.

Review and test

Create test issues of both types using all alternative workflow paths.

External visualization

Easy setup to handle external listings uses these components:

• JIRA listener catches events triggered in workflow transitions
• Listener calls an url with Ticket ID as a parameter
• SOAP client in this url connects JIRA and reads ticket information
• This client saves the information so it can see what have changed from the last time
• If the some conditions are met, client will:
  • Display ticket information
  • Send email messages
  • Create RSS feed
  • etc.

Example: NORDUnet TTS visualization