This article relates to the following four project option tabs available on the admin side of a form:

General List Options

Tickets per page: The number of tickets to be displayed in the list of issues. The default is 20.

Ticket colours: Tickets are usually highlighted in a specific colour, based on the status.

However, it is possible to configure issues to be highlighted in an alternative colour based on a more specific condition.

For example, you may have a field in the form, which allows users to select a priority level, e.g. High, Medium, Low. In this case, even if the status of an issue is set to 'Pending' and the colour for the 'Pending status' is orange, you may like to highlight it in red if the priority level is set to 'High'. This essentially allows you to implement a ‘RAG’ (Red, Amber, Green) system within the list view.

For set-up steps and more examples, see our guide here.

Ticket age: Choose whether a ticket's age-related to its time from creation, or from the last modification.

The option chosen will appear on the front end of tickets, as shown below.

Primary Field: The primary field can be used in the Open Items component.

The selection made in the primary field on the admin side of a form is what will pull through when 'primary field' has been included in the component:

Tickets List Columns

It is possible to define which fields should act as sortable column headers in the list of issues.

The ID of the ticket, the number of notes added to the ticket and the number of files attached to the ticket are always displayed in the list and are in a fixed position.

It is possible to include/exclude the following as column headers:

• Submitter
• Assigned To (if handlers are being used)
• Status (if statuses are being used)
• Date created
• Date last modified

In addition, all of the fields within your form can be chosen to be included/excluded as column headers.

How this appears on the front end in the ticket list, so customise this based on what you need end users to see here:

Searchable Fields

It is possible to define which fields should act as filters in the list of issues. The following can be included/excluded as filters:

• Submitter
• Assigned To (if handlers are being used)
• Status (if statuses are being used)
• Traffic light (if SLAs are being used)
• Date created
• Date last modified

In addition, all of the select fields within your form, i.e. checkboxes, radio buttons and select fields, can be chosen to be included/excluded as filters.

Below shows how a user can access the advanced search area on the front end of a form and use the filters to perform a search:

Default Search Filter

It is possible to configure a default search filter for the list of tickets. 

If a default search filter set is defined, the list of issues will be pre-filtered accordingly for all users.

This can be changed by form administrators at any time from the admin side.

An example of where this may be useful is if you have a 'Closed' status.

By default, you may wish to exclude issues which are set to 'Closed'.

End users can clear the default search filter in the ticket list, whereby all issues they have permission to view will then be returned.

The default search filter area just allows administrators to control what users first see when opening the ticket list, to best optimise it for their work needs or the majority.

As shown below, the default view for this project is not to exclude 'Closed' status as set by an administrator on the admin side of the form.

This means on the front end when a user accesses the form, it will show only tickets in all other statuses by default.

The user can of course change the view using the advanced search if they so wish.

Recommended next article:
Custom messages