The osTicket dev team proudly presents the next major release of osTicket, v1.8, codename “Rumors”.

The initial release introduces two core feature additions that fundamentally change, for the better, the way that you and your users approach your osTicket help desk. This guide walks through the facets of the features and gives you an idea of how to understand and get the most out of the new features.

Feedback is welcome and encouraged. Please track on our GitHub page at https://github.com/osTicket/osTicket-1.8. We’d like to keep our software defect issues in one place if at all possible to ensure all fixes for any identified bugs make their way into the mainline product.

Rich Text HTML Ticket Thread

As an option, enabled by default, osTicket can now process HTML email and allows for rich text markup in most long-answer boxes across the system, including staff replies and internal notes posted to the ticket thread. To keep the feature consistent throughout, canned responses and email templates also sport an HTML theme now.

Auto-Save

The rich text editor used for rich text content editing throughout the software, will, in most instances, auto save your work to the osTicket server. When the draft is made current on the server, a “Draft Saved” notice will appear just above and on the right side of the text editor. If the page is refreshed for any reason — if you are logged out, for instance, — your draft will be automatically reloaded and displayed.

Should you want to discard your draft, you can use the trashcan icon shown with the “Draft Saved” notice, or use the [Reset] button shown alongside the [Save] button. The draft will be discarded. If editing content, such as an existing canned response, the page will refresh and show the content from the most recent time it was saved.

Rich Text Signatures and Notes

Signatures can also contain rich text markup now. All markup available in the ticket thread is available in your signature line. Images are not allowed to be uploaded and included inline in signature boxes; however, any image that is already in the system — perhaps attached to a FAQ article or canned response or a help desk logo — is available to be added and resized in the signature. However, you are encouraged to attach your company logos to the HTML email templates. Placing your logos there will allow you to create a much more consistent layout and theme across your user communication.

Admin notes fields also allow rich text markup. However, neither signature nor admin notes fields are shown with the markup toolbar. Simply double-click inside the rich text field or select a portion of the text, and a markup bar will appear by your mouse cursor.

HTML Email

HTML emails are now the default and the templates used to format outgoing emails are always managed a rich text. To provide greatest compatibility, emails are sent in both HTML and plain text. Should your clients’ email software only support plain text emails, a plain text version of the email will always be included in the email.

If you decide to disable HTML ticket thread, HTML emails will also be disabled. In this case, only the plain text version, derived from the HTML template, is included in the email. All HTML images that would ordinarily be included and shown inline in the HTML document are included as separate attachments.

As a caveat, if the HTML ticket thread is disabled, incoming mail is also parsed differently. The plain text version of the email is preferred if available, and if not, a plain text version of the email is generated from the HTML version. This plain text version is the only one kept on record. All other rich text markup in the email is discarded.

Inline Images

Images included in HTML emails which were declared inline are now shown inline in the ticket thread. The images shown have a hover effect and will show the filename and offer a download link for the image. External images are also displayed; however, normally, a placeholder image is shown in the ticket thread, and a button is added to the header of the ticket thread entry, labelled “Display Images”. Once clicked, the placeholders are replaced with the actual external images.

If the HTML ticket thread is disabled, inline attachments are still accepted according to the allowed attachments setting, however, no attachments are shown inline.

Default Templates

Initial data for templates is now stored outside of the database. That means you can create a new email template group without cloning an existing template. The data in the templates shipped with the system will be used as the initial data for the templates. Soon, translations of the templates will be available (with help from the community), and the translated templates will be made available by selecting the language of choice from the drop-down list when creating a new template group.

Enabling or Disabling HTML

As alluded to earlier, the rich text feature can be disabled for the ticket thread. Visit the Admin Panel -> Settings -> Tickets, and verify the setting of “Enable HTML Ticket Thread€”.

Custom Forms and Fields

The data collected from your users when they fill out the ticket form is now customizable. You can now ask any information relevant to your business practice, and can customize the type of input show from the user. Currently, short and long answer fields, drop-down lists, checkboxes, date and time, and phone number fields are available. Each field is configurable and can be setup according to your liking. Fields can also be marked as required, whose input is required to submit the ticket, and internal, whose input is not visible to the end user.

Custom Lists

Perhaps the greatest facet to the feature is to define an arbitrary list which can be utilized in the custom form. Perhaps you have a list of locations and would like the user to select the relevant location for the ticket when submitting the request. Now you can create your list of location — even give abbreviations for the items — and display the selection list in the custom form as a drop-down box or even as a Bootstrap typeahead field.

For forms shown as drop-downs, the list can be sorted either alphabetically, reverse alphabetically, or can be manually sorted however you require.

Forms by Help Topic

In addition to customizing the common ticket form, extra forms can be defined and associated with help topics. Although not required, if you have extra data that is useful for various help topics, your custom form will be presented to the user or staff when creating a ticket under the associated help topic. Any validation or requirement settings on the form will be applied as usual.

Client Data

Clients in the system now have arbitrary fields associatable. Where previously only name, email and phone number were available, now you can define any number of fields to keep data on file for your users. Some fields can be marked as internal, which will keep their data private from the end user. As with any other custom form, you can use free text note fields (complete with rich text markup) or drop-down lists.

Custom Data in Templates

Email templates and thank-you pages also have access to the custom data associated with your tickets and clients. Use the value given in the `name` field of the custom form designer in the token. For instance, if you have defined a location field with a name of `location`, you can use %{ticket.location} in email templates, and the location currently selected will be replaced.

To access arbitrary fields on the client / end user, use %{ticket.user.field}, where `field` is the value from the `name` column in the custom form designer for your common client form.

Better Name Processing

Custom forms also allows for more detailed name processing and display in templates. Previously, only the full name of the user was made available. Now, several variations of the name are made available. For instance, several variations can be added to %{ticket.name} including the following.

The same variations are available to staff member names used in both internal and external email communications. If no variation is given, the default specified in the Admin Panel in Settings -> System Preferences is used to define the default name formatting.

Translatable Data

The goal of osTicket 1.8 is to make the system completely translatable so that later versions of 1.8 and 1.9 can ship with and support languages other than US. English. Currently, all the data that is created in the system when it is first installed or upgraded (help topics, departments, groups, pages, templates, custom forms, etc.) is located outside the main install script. That means that it is translatable without providing multiple install scripts. This is a subtle but major step forward towards making osTicket a truly international support system.

Thanks in advance to all the members of the community who can help make the initial data and user interface available in other languages. Please visit and b

Deploying osTicket 1.8

We encourage our avid users and testers to deploy osTicket from git rather than downloading the nightly builds or periodic releases from the osticket.com page. To do this, first checkout the osTicket-1.8 repo into a folder on your server (usually in your home folder)

git clone https://github.com/osTicket/osTicket-1.8

And deploy the code into somewhere in your server’s www root folder, for instance

cd osTicket-1.8
php setup/cli/manage.php deploy --setup /var/www/htdocs/osticket/

Then you can configure your server if necessary to serve that folder, and visit the page and install osTicket as usual. Go ahead and even delete setup/ folder out of the deployment location when you’re finished. Then, later, you can fetch updates and deploy them (from the folder where you cloned the git repo into)

git pull
php setup/cli/manage.php deploy -v /var/www/htdocs/osticket/

Use --help to see a complete list of features and options of the deploy script.

Alternatively, the version can be downloaded from on the download page