#CSIG-SW-Lab-Ticker

-Configuring the system using the provided config.php file

-Changing the display interface and including other datafields

This project is based around the ticker.php web page. This page provides a display for the work done by the php files.

Config Options

The config.php file allows various settings within the program to be changed.

-Ticket Status

-Ticket Type

-Polling Time

-Max Tickets

-Sort Method

-Sort Direction

-Department Exclusions

Ticket Status

Ticket status to be included are provided as a pipe seperated string of values. The order in which they are listed controls the order in which they are displayed on-screen.
The available options to include are:

• Open
• In Progress
• Closed
• On Hold

WARNING: The "Closed" option is very slow due to the volume of requests produced and it can cause the site to appear unresponsive.
Its use is not recommended when the Max Ticket variable is not set as it essentially DoS's the site with thousands of http requests.

Example

/* Display tickets that are listed as In Progress or Open */ define( "__TICKET_STATUS" , "In Progress|Open" );

Ticket Types

Ticket types to be included are provided as a pipe seperated string of values.
The available options to include are:

• Issue
• Task
• Bug
• Lead
• Feedback

Example

/* Display all ticket types */
define( "__TICKET_TYPE" , "Issue|Task|Bug|Lead|Feedback" );

Polling Time

This variable dictates how often the back-end polls for new tickets or changes to ticket statuses. It is provided as a number in seconds.
A change to the polling time requires the page to be refreshed for the effects to be propagated to the end user.

Example

/* Check for updates every 15 seconds */
define( "__REFRESH_TIME" , 15);

Max Tickets

This variable controls how many tickets should be displayed on the screen at once. It is usually set as a positive integer. To show all tickets, a value of -1 may be set.

Example

/* Display all tickets in list */
define( "__MAX_TICKETS" , -1);

Sort Method

This controls the order in which the tickets are shown on screen. It is provided as a string. It dictates whether it is to be sorted by ID or Creation Date.
Other sort methods may be added by editing the sortBy() method in ticker.class.php to accept other __SORT_METHOD variables and set $a() and $b() accordingly.
The available options are:

• CREATION_DATE
• ID

Example

/* Display tickets sorted by Creation Date, with the oldest first */
define( "__SORT_METHOD" , "CREATION_DATE");

Sort Direction

This controls whether tickets are displayed in ascending or descending order.
The available options are:

• ASC
• DESC

Example

/* Display ticket listing with the oldest first */
define( "__SORT_DIRECTION" , "ASC");

Department Exclusions

This controls which departments to exclude tickets from and is provided as pipe seperated string.
There are 22 departments that tickets are pulled from and each may be excluded by providing the department name in this string.

• Other
• Hardware
• Operating Systems
• Issue
• Installation
• BIOS
• Silicon / Processors
• Re-Work
• Networking
• Lab Access Request
• Fault
• Requisition
• Security
• Shipping
• Traffic Generators
• Administration
• WGC
• Hardware [WGC]
• Software [WGC]
• Networking [WGC]
• Shipping [WGC]
• Silicon / Processors [WGC]

Example

/* Do not display tickets from the following departments */
define( "__DEPARTMENT_EXCLUSIONS", "WGC|Hardware [WGC]|Software [WGC]");

Managing the Display Format

The ticker program is designed to allow support for a number of different display interfaces. Each display can be added by creating a new subdirectory in the views folder.
The default format can be specified as the false return value of the ternary logic operator checking $_GET['template'] in the config file.
This means that the template can also be set by appending a get parameter to the url in the format ticker.php?template=old-basic

• Create New Display Format
• Include Other Datafields

Creating A Display

A display can be added by creating a new folder in views which contains at least the following 5 files.

• header.txt
• footer.txt
• index.txt
• indexsimple.txt
• js.txt

Header.txt

The header file must contain the required HTML code up to and including the <body> tag at a minimum. It is also required to have an include for the javascript file.
Click here to see an example header.txt file used in the basic display view.

Footer.txt

The footer file must contain the required HTML code from the </body> tag onwards at a minimum.
Click here to see an example footer.txt file used in the basic display view.

Index.txt

The index file contains the template for the viewable webpage. It contains markup for the inclusion of both the header.txt and the footer.txt.
This is done by placing @<file-name-without-extension>@ at the points in the file where the code should be included.

It also contains the template for each data row of the display. The data will be filled into the placeholders in the form: [<identifier>].
The placeholders included by default are:

• [ticketid]
• [user]
• [subject]
• [status]
• [dept]
• [creation]
• [type]

There is also one idenfier that is created based on status and is used to place tickets into different CSS classes for colour-coding. It is:

• [class]

If further datafields are required, they can be added as explained here.
Click here to see an example index.txt file used in the basic display view.

Indexsimple.txt

The purpose of this file is to return all the updated values of the tickets to the page so changes can be propagated to the viewer.
For that reason, it just consists of all the attributes of each ticket in a string that is seperated by a specific mark-up.
These attributes are seperated in the javascript and passed to the addRow() function or used in the updateRow() function.

Click here to see an example indexsimple.txt file used in the basic display view.

Including Other Datafields

The Kayako API offers access to many fields of a ticket query. For this reason, not all fields are included by default. To include additional fields, changes must be in many parts of the program.

• index.txt
• indexsimple.txt
• ticker.class.php
• js.txt

Index.txt

Data is filled into the locations occupied by certain placeholders in the form: [<identifier>].
To include other datafields, the html contained within #ticketentry# must be edited to allow for more data to be displayed. This is done using additional placeholders like above.
The relevant CSS must also be adjusted.

Indexsimple.txt

Indexsimple must also be adjusted so it returns more datafields to the page.
Again, this is managed by placeholders like those in index.txt.

ticker.class.php

The callback_ticketlist() of this class must be changed so that the preg_replace function calls now act on the new placeholders that have been added to index and indexsimple.

js.txt

The javascript must be edited to take extra datafields during the string split operations on indexsimple in updateTable().
The addRow() function must also be adapted to match the new HTML/CSS of index.txt and also to include the extra parameters now being passed to it from the additional updateTable() splits.