Navigation:  Release Notes > Release Nots 750 >

Ticketing

Previous pageReturn to chapter overviewNext page

Ticketing information field

An option has been added to display the ticket information field read only. In that case only the information text entered when creating the ticket is visible in the information field.

You can configure this in the process / general settings:

Once the option is enabled, this applies to all tickets related to that process, also the past ones.

Apply ticketing pool color scheme

You can link a color scheme to a Ticketing pool

The current color scheme of the pool is now also applied in the headers of the ticket.

Provide option to set type of note

It is possible to add an action log from the workflow by using the step type “update ticket”. You can configure the type of log that is entered, allowing to add a public or private note. For example, a text entered in an action step is made available in the progress of ticketing as a user message.

Title/Head tag for ticketing page changed

In order to distinguish ticketing pages better within a browser, the header of the ticketing page can be modified. By default the setting is: Ticket: #TICKETNR#. This can be adjusted by adding a translation with category "Ticketing.TicketDetail" and name "WindowTitle". The value of the translation must at least contain the #TICKETID#, if not the default translation is used regardless the entered value.

Message recipient selection

When adding a message, you can choose who receives the message:

 

Private notes:

-No one (default)
-Assignee
-Custom (SSP person select)

Add as public:

-Requestor (default)
-Requested for
-Alternate contact

Send as question:

-Requestor (default)
-Requested For
-Alternate contact

Views

In the ticket views, you can see the last updated time of the view:

Workflow steps in ticketing

Within ticketing it is now possible to complete and submit workflow action and approval steps. When editing a ticket and the associated workflow has an action step active, the ticketing detail page will show the name of this step under the header “workflow actions”. In case the action step has formfields defined, you can click on the step name and a popup will open. Within this popup, the form can be submitted. All of this happens within the ticketing environment.

A special situation occurs in case no formfields have been defined and only custom Step actions have been activated in the action step. In such a situation, users within ticketing will see the custom step actions within the “workflow actions” box and use them from there.

Planned delivery date

When closing a ticket, the planned delivery date is no longer set to an empty value.

When a running ticket is stopped, the system checks if the closed status is not active, if so, the planned delivery date is not set to empty.

When the status closed is selected, the planned delivery date is calculated if possible, if not an empty value is set.

 

 

Multiplier step messages

When having a multiplier step active, the main process page isn’t showing any active step. You need to go into one of the multiplier paths to see the active steps. This caused the messages box to be displayed on the main page, although the steps within the multiplier path had the option to ide the message tab enabled. This has been fixed.

Additional Task fields

Additional fields are available in tasks. The fields status and priority have been added. The current status field is renamed to Due Status. The new status field is configured through a datastore list, ticketing-taskstatus.

The priority field is a new field and is displayed on the task details page. Also this list is defined with a datastore list, ticketing-taskpriority.

The views of tasks are changed in order to show the following fields in the mentioned order:

Id, Status, Description, Priority, Assigned Group, Assigned Person, Due Status, delivery date.

Tasks are making use of existing code tables and get their own "TYPE", or re-use a type already used for ticketing. When a code is used for multiple types, you can set the type to for example IM,RFC.

In search screen the list of types available is filtered based on the types used in process DEFINITIONS. Search tasks checks the types used in task.

In process general settings there is an additional setting to select the type for tasks.

Ticketing status

It is now possible to assign a semantic value to a status code. This gives the possibility to have multiple statuses linked to for example the Closed state. Within the datastore containing the status codes, an additional column is added with label “SemanticValue”. Within this column any of these values should be stored per status:

Updated-Default. The default and only Updated status.
Closed-Default. The default closed status, used in case the system closes a ticket
Closed. Another closed status, when selected the ticketing module assumes the ticket to be closed.
InProgress-Default. The default and only In progress status.
WaitingForCustomer-Default. The default and only Waiting for customer status.
WaitingForVendor-Default. The default and only Waiting for Vendor status.

Please note that the settings page still has these options:

These settings will be ignored once 1 SymanticValue has been set.

 

Additional columns in search tasks

Additional columns have been added in the tasks search results list

When searching for tickets, search filter lists can be filtered by using a type

In case multiple ticketing user groups exist, users should only see their own status lists or priority lists. By selecting a type prior to the search action, the lists will be filtered to allow this:

Show date when an attachment was added to the ticketing detail screen.

Attachments now show the date when they were added and if the attachment will be included in the solution email.

Detail screen has been redesigned

The ticketing details screen has been redesigned. The objective was to make the page provide the most relevant information first.

The following changes have been made:

1.Code tables will no longer be displayed on the main form and have been moved to the right, and are now called ‘Ticket properties’.
a.
b.Changes made to any of the codes shown on the right are stored immediately after changing.
2.Label texts have been updated to reduce text length
3.Requested For Alternate fields are now shown in an additional popup
a.
4.Attachments are now displayed on the top
5.Expand buttons are available on all sections of the screen
a.When using such an expand button, the content is displayed in a larger window, for example progress lines:
b.
6.A new closure screen is implemented:
a.When selecting (any of) the closed status, a popup form is opened that contains all fields relevant to the closure of a ticket:
b.
c.The solution field has been removed from the mail form when not provided. Only in case the solution field has been filled, it will be displayed read-only on the main page.
d.Attachments can be selected. Within the workflow it is possible to refer to the selected attachments in for example the closure email to the user.
7.The Requestor and Requested For field can now be updated when allowed in the user’s profile.
a.

 

8.Custom fields can be displayed next to each other
a.
b.Definition:
c.
9.Custom field types ‘Date’ and ‘Date and Time’ have been added.

Several small bug fixes and enhancements

-Avoid deletion of email templates used in ticketing (previously only email templates used in processes were disabled for deletion).
-Possibility to add a private message in a ticket when you are assigned only read rights to the ticket (defined by the pool).
-Corrected the mouse over text of a workgroup.
-Pool added on search screen.
-When clicking next to an overlay popup, the popup is no longer closed.
-Attachments added by users now show a green switch behind their name in ticketing to indicate that users are able to see the attachment.