How to add a configuration option to osTicket

So you wrote a mod or a plugin and want to add some configuration options directly to into the osTicket Admin panel. This is a short tutorial on how to add a setting to osTicket, and then have your mod (or plugin) check that setting.

First off realize that modding osTicket can result in the breaking of your site, and you should really perform a backup of both the site and your database prior to making changes.

Next is to decide what you want your setting to be; where you want to put it in the admin panel; and what you want to label it.  Personally I wrote a mod a while back that adds a client side open ticket list and think it would be great to be able to toggle this feature on and off, and control how many open tickets the mod displays.  You do not have to have this mod installed to follow this tutorial, but I figured a real world example might be easier so this tutorial will assume that mod is already installed. To that end I've decided on two settings:

  • "Display Open Tickets to Clients" which will be a check box., and have the help text of " Allow clients to view a safe summary of open tickets on the landing page"
  • "Display # open ticket to Clients:" which will be a text field, and have a help text of " (Limit the number of open tickets to display to clients – default 10)"

I've decided to put both of these settings in Admin panel -> Settings -> Tickets, as the last two options before the "Attachments" section.  So lets start editting with adding these fields there.

Let's open and edit: /include/class.config.php
Scroll down to line 304.
Just after the closing } add:

    function clientDisplayOpen() {
        return $this->get('client_display_open');

    function clientDisplayNum() {
        return $this->get('client_display_num');

This will let us use those functions to get the config variables values later.

Next scroll down to line 903.
After the line that reads:

This will make sure that our fields get updated when we hit save.

Now lets open and edit: /include/staff/
Scroll down to line 138.
Place your cursor after the </tr> and hit enter.
We are going to add a new tr here to display the settings on the page.
            <td>Display Open Tickets to Clients:</td>
                <input type="checkbox" name="client_display_open" <?php
                echo $config['client_display_open']?'checked="checked"':''; ?>>
                Allow clients to view a safe summary of open tickets on the landing page
            <td>Display # open ticket to Clients:</td>
                    if($config['client_display_num'] == '0' || $config['client_display_num'] == null) {
                        $client_display_num = '10';
                    } else {
                        $client_display_num = $config['client_display_num'];
                    } ?>
                <input type="text" name="client_display_num" size=4 value="<?php echo $client_display_num ?>">
                <em>(Limit the number of open tickets to display to clients - default 10)</em>

Let's go over this a little.
$config['client_display_open'] is the variable that holds if our check box is checked.
$config['client_display_num'] is the variable that holds the # of tickets to display.  Additionally it defaults to 10 if its not set, or is set to 0. This is redundant as its also checked in the display_help_topics.php also. 

Note: if you have a LOT of tickets open on a regular basis you may want to consider hard coding in a default for maximum also so that way staff cannot set it to say 500 and have it display 500 open tickets to the client.

Lastly we need to change the display logic a little to determine if we should be displaying the open ticket list.
lets open and edit: /index.php

replace last 9 lines with:
    if($cfg && $cfg->isKnowledgebaseEnabled()){ $displayfaq = '1'; }
    else { $displayfaq = '0'; }
    if ($ost->getConfig()->clientDisplayOpen()) { $displayopen = '1'; }
    else { $displayopen = '0'; }
    if ($displayopen == '1' && $displayfaq == '1') { ?>
        <p>Be sure to browse both our <a href="kb/index.php">Frequently Asked Questions (FAQs)</a>, and the open tickets below before opening a ticket.  Thank you.
        <div id="openticks"><?php include('display_open_topics.php'); ?></div>
    <?php }
    else {
        if($displayfaq == '1') { ?>
            <p>Be sure to browse our <a href="kb/index.php">Frequently Asked Questions (FAQs)</a> before opening a ticket.  Thank you.
        <?php }
        if($displayopen == '1') { ?>
            <div id="openticks"><?php include('display_open_topics.php'); ?></div>
        <?php }   
    } ?></div><?php require(CLIENTINC_DIR.''); ?>

What this does is based on how displayfaq and displayopen are set it shows different things. The important part here if you're going to do this for something else is how we reference the setting specifically: $ost->getConfig()->clientDisplayOpen().

Lastly to be complete we need to edit the display_open_topics.php.  This file is not part of the standard osTicket distribution (yet?) and is included in the mod archive I mentioned earlier.  Currently its hard coded to display 10 records.  Locate lines 21-22 which should look like this:

// The maximum amount of open tickets that you want to display.
$limit = '10';

Replace them with the following:
// The maximum amount of open tickets that you want to display.
$limit = $ost->getConfig()->clientDisplayNum();

// if limit is 0 or null set to default [10].
if($limit == '0' || $limit == null) {
    $limit ='10';

What this does is check for the setting in the database and if it doesn't exist or is 0 for some reason sets the number to 10.  This is a little redundant because we also check to make sure that if its 0 or null that it gets set to 10 in /include/staff/

Now if you log into your osTicket installation and go to Admin panel -> Settings -> Settings -> Tickets you should see something like this:
new config options

Using the osTicket API

One of the [I feel] less documented features of osTicket is the ticket API.  This API has been built into osTicket for quite some time and allows you to write your own html forms and push the data to osTicket to open tickets.  This means that you could write a contact block for your web page and have it submit to osTicket directly, or if you have another piece of software that can run a script you can write your own custom script to open tickets from that software.  Example a network monitoring system (like NOCOL/SNIPS) could open a ticket when a device stops responding.

Before you can start using the API you will need to do some configuring in osTicket.  Log into your osTicket installation with your admin account. and go to Admin panel -> Manage -> API Key.

api key start

On the right click on "Add New API Key".

osticket add api key

There are several things that you need to enter here.  First is the IP address of the source where the request will originate from.  This can be the server IP address assigned to your server that hosts the software. Next you will want to check "Can Create Tickets (XML/JSON/EMAIL)".  Then under "Admin Notes" put a note so that in the future you can go in and see what this API key was made for.  Something like: "API Key for automating X software opening tickets." where X is the name of the software your using.  Feel free to customize this to be what will relay to you the reason for this API key.  Next click "Add Key".

api key is setup

Take note of the "THISISAFAKEAPIKEYHERE!" (which of course will be a real API key for your installation).  You will need this for your script.

Next download the osTicket API example. The only thing in this archive is a file called: ost-api-example.php.   This is an example of how to use the API using PHP.  Obviously you will need to edit this file to suit your implementation of osTicket.  The two really important parts are on lines 18 and 19. 

'url'=>'http://your.domain.tld/api/tickets.json', // URL to site.tld/api/tickets.json 'key'=>'PUTyourAPIkeyHERE' // API Key goes here Edit line 18 to have your URL.
Edit line 19 by changing "PUTyourAPIkeyHERE" to your API key (aka the "THISISAFAKEAPIKEYHERE!" from earlier).

If you have any required custom fields you will want to add them to the $data = array (lines 39 through line 49).  There are examples of both a list and text field included (Agency and Site).

Next try to run the script.  You can do this by putting the script on a web server and browsing to it. [note: the webserver will need to have the IP address that you put in the API key!]

Upcoming osTicket Feature: User Accounts — includes commit notes and Dev Q&A

There has been a lot of talk recently about some of the new features and the direction that osTicket is heading in. In the past I've mentioned that osTicket will have individual user accounts for clients. Today I get to share a little more about this coming feature! Jared (aka greezybacon) posted the following commit notes over on github a short time ago:

This feature adds the framework for client authentication. Now, clients can register for accounts and login with a username and password to the client portal. The feature include several sub-features


  • Client login (via new sign-in page)
  • Client registration
    • Email address verification for self-service registration
    • When viewing a ticket, users are encouraged to register for an account or sign-in to view other tickets
    • Registration can be disabled, which will use the legacy ticket access link page
    • Registration can be closed so that only staff members can register client accounts
  • Login can be required for clients to create new tickets
  • New tickets via the web portal can be disabled (if registration is disabled and sign-in is required)
  • Ticket links in emails now give access to exactly one ticket (show related tickets is retired)
  • Clients have a time zone preference, and all times are shown in the client's preferred time zone
  • System time zone is pre-selected for both new clients and new staff
  • Client login supports password reset via email (with configurable template)
  • Client sign-in page supports a configurable header and title
  • Client registration page and email templates are translatable and configurable
  • Staff login page supports a configurable banner
  • New staff accounts can be accessed without a temporary password (reuses the password reset feature)
  • New "Access" settings page with consolidated settings for authentication and access settings

Review Requested for

  • Template and view file naming conventions
  • Content phrasing, especially with respect to the new content
  • Look and feel as well as workflow
  • Intuitiveness
  • Misleading links, pages, etc.
  • Missing prompts, labels, headers, etc.
  • Migration of existing data and settings after upgrade from <= 1.8.2
  • Lint and code quality


This of course immediately prompted an impromptu Q&A session.  Here are the questions and answers (They were re-formated to make more sense):

Q: Out of curiosity how will this new system handle existing accounts? (ie in case of upgraded installations)  Since these users will obv not have a password. Will they be forced to use the "forgot password link?"

Jared: Upon upgrade, there will be no existing accounts. We’ve chosen to separate the idea of users and user accounts. For instance, anyone who sends an email into the system should not necessarily have an account created with user preference, organization information, account access email sent out, etc. User’s accessing the system via email links will have the option to register for an account in the system, once the setting is enabled in the admin panel (Settings -> Access -> Client Registration Mode (set to ‘public’). New installs will ship with the setting configured as ‘public’ and upgrades will set the setting to ‘private’ (only staff can register client accounts). Once a client registers, verifies the email address, and logs in, they will have access to all their tickets, can manage their profile, etc.

Client registration will use an email verification method similar to the forgot my password since email addresses are still required for client accounts.


Q: Will there be a staff ui for reseting the account password immediately?

Jared: Peter is working in parallel on a user directory feature which will allow staff members to create, delete and manage client accounts (including resetting passwords).


Q: Will there be the traditional "ask question:provided answer" to prove who the person is before sending password reset links? Like the ones that financial institutions use. (examples: Where was your favorite place to visit as a kid?  What is your mothers maiden name? etc.)

Jared: Currently, reset is done by email address verification. I’m not opposed to the Q and A option, but I personally don’t like them and generally forget the answers to the questions before I’m able to use them. I would vote for a SMS message reset instead, if we required another form of authentication.

Please join the conversation over on the forums here:
Upcoming osTicket Feature: User Accounts — includes commit notes and Dev Q&A

FOR SALE: 2007 Suzuki s83 Boulevard w/ 4451 miles — $4500

Now that Spring is here it's time to try to sell my motorcycle again. I'm not aware of this bike having any issues at all. It was registered (2014) and inspected (2013), and currently being stored in my garage. I started her up and took for a short spin today. If you are interested in buying her you know how to contact me!

The pictures below are from when I bought it, after the pictures is the bike product information.

Here are the specs:

Type: Cruiser

Displacement (cc): 1360 Engine Type: V Twin Cylinders: 2 Engine Stroke: 4-Stroke Valve Configuration: SOHC Carburetion Type: Carburetor

Transmission Type: Manual Number of Speeds: 5 Primary Drive System: Shaft

Front Brakes: Hydraulic Disc Rear Brakes: Hydraulic Disc

Front Tire(s): 110/90 R19 62H Rear Tire(s): 170/80 R15 77H

Wheelbase (in / mm): 63.5 / 1620 Dry Weight (lbs / kg): 535 / 243 Fuel Capacity (gal / L): 3.4 / 13 Seat Height (in / mm): 29.1 / 740 Number of Seats: 2

Nada Guides lists this bike at average retail: $4,715

How to manually update a client/user phone number in osTicket 1.8.1.x

I'm not sure why anyone would WANT to do this, but on the off chance someone thinks that they need to and wants to try it here is how you can manually add or update an existing client/user phone number in osTicket at the SQL level.

  • First Look up user id in ost_user

SELECT id FROM ost_user where name='THE NAME';lets pretend it returns '15'.

  • Next look up the client phone field (by default this is 3, but we should check just in case.)

SELECT * FROM ost_form_field WHERE label = 'Phone Number';let's pretend that it returns an id = 3.

  • Look for it in ost_form_entry_values

SELECT * FROM ost_form_entry_values where entry_id = 15 and (field_id = 3 OR field_id = 10);You may get two records back. That look something like this:
where XXXXX is a phone number.

To add a missing number
INSERT INTO ost_form_entry_values VALUES(15,Y,'phonenumber','');where Y is 3 or 10 (the missing one)

To update an existing number
UPDATE ost_form_entry_values SET value='NEWphoneNUM' WHERE entry_id=15 AND field_id='Y';where Y is 3 or 10 (the one you want to update)

osTicket coming very soon

Over on github at the osTicket-1.8 project this a new v1.8.1.2 tag was added.  This tag means that version will be released shortly.  Here are the release notes:



  • Better detection of email loops (#584, #684)
  • Any valid email address can be used throughout the system (#673)


  • Fix selection of the auto-response email for a department (#666)
  • Allow usernames to have Unicode characters continued (6986e6f)
  • Don't require current password when resetting (#671)
  • Fix incorrect matchup of collaborators to users (#676)
  • Fix over-stripping of some HTML element sections (#686)
  • Fix upgrade crash from some osTicket 1.6 installations (#687)
  • Fix attachments from new ticket by staff to be associated with the response (#688)

Geeky Stuff

  • Persistent database connections are supported (#693)
  • Regression testing now tests for JS syntax errors (#669)



osTicket released

As of a few days ago you can now download from the page.

Here is a list of the enhancements, bug fixes, and Security updates:


  • Add signature to activity notice for staff replies
  • Show company name in the copyright footer (#586)
  • Departments can have a department if there are no members (#618)
  • Signature is displayed below the staff response box (#609)


  • Fix footnotes generated in html2text for same link text but different URLs (5e2f58d)
  • Fix processing of emails for existing users (#588)
  • Avoid adding an aliased system email address as a collaborator (#604, #627)
  • Show current staff / user names where possible (#608)
  • Fix display of forgot my password link (#611)
  • Export the value of custom fields (not the ID number) (#610)
  • Fix saving the backend with file metadata (#595)
  • Use the database as a failsafe attachment backend (#594)
  • Avoid a crash when sending some mails (#589)
  • Preserve image float css attribute in ticket thread (#612)
  • Fix appending canned responses if HTML ticket thread is disabled (#621)
  • Fix migrating attachments when upgrading from osTicket 1.6 (#614)
  • Fix SQL error for some variable names on custom fields (#620)
  • Fix stripping of leading zeros from phone numbers (#622)
  • Strip <?xml ... > processing instructions from html email (#628)
  • Fix crash during PDF generation for some PHP installations (#631)
  • Disable error_reporting for releases (#630)
  • Add git version to the deployment script (#630)
  • Email templates ship with the ticket number in the subject line (#644)
  • FAQ last-modified time can be something other than midnight (#647)
  • Fix creeping widget sizes in create-user dialog (#648)
  • If Auto-claim tickets is disabled, reopen tickets unassigned (#651)
  • Usernames can have Unicode characters (#650)
  • If inline images are stripped from the email, they are not considered attachments (#649, bcbebd0, 35a23be)
  • Fix incorrect Content-Id headers generated for inline images (23ce0a0, e37ec74)
  • New SLA's default to have alerts enabled (#654)
  • Fix creating ticket by staff without required contact-information fields (#656)
  • Fix crash for some custom field configurations (#659)
  • Fix crash viewing ticket in the client portal if no departments are public (#658)
  • New installs have the

    group enabled (c7130c5)

  • Always show the ticket thread when following an email link (17725ca)
  • Allow manual update of SLA to a transient SLA (#663)

Security and Performance

  • Staff can only see closed tickets if they have access via group or primary department (#623, #655)
  • Fix incorrect honoring of ban list and over limit settings (#660)
  • Keep existing session after login (c4bfb69)
  • Fix password reset system (dfaca0d, #664)


Debian – apt-get update GPG error

I have been running a Debian server here at work for a several years now mostly as a web server, but also as a way for me to have quick access to some of the old cli tools like whois, dig, etc.  While running updates I ran across this error:

Fetched 199 B in 1s (122 B/s)
Reading package lists... Done
W: GPG error: stable Release: The following signatures couldn't be 
verified because the public key is not available: NO_PUBKEY 57801F6F5B9EFD43


You can fix this by simply re-add the key by running the follow command at the command line:

wget -O - | sudo apt-key add -