OSTicket Plugin Development Unofficial Blog

This is an unofficial blog describing adventures in the OSTicket Plugin development.  Since OSTicket Plugin system is undocumented, most of the information here was collected via reverse engineering and trial and error.  If there are any mistakes or something is not clear, please let me know in comments.

This guide is based on the OSTicket version 1.9.2 official release that can be downloaded from here:

http://www.osticket.com/download

The official OSTicket plugin repository is located here:

https://github.com/osTicket/core-plugins

The result of this guide is a conversion of the Equipment Management mod to plugin format:

https://github.com/poctob/OSTEquipmentPlugin

Please feel fee to ask any questions in comments.

So on we go…

Part 1.  Getting Started

OSTicket plugins live in the <INSTALL_ROOT>/include/plugins directory.

Each plugin should be placed into its separate folder, for example <INSTALL_ROOT>/include/plugins/myplugin.

There are two files that are necessary for the OSTicket to find your plugin: plugin.php and config.php.

plugin.php

This file contains general description of the plugin.  Here is a sample file:

<?php

/**
 * Description of plugin
 *
 * @author
 */

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__file__).'/include');
return array(
 'id' => 'xpresstek:equipment', # notrans
 'version' => '0.1',
 'name' => 'Equipment Manager',
 'author' => 'XpressTek',
 'description' => 'Provides equipment asset management capability.',
 'url' => 'http://www.xpresstek.net/osticket/plugins/equipment',
 'plugin' => 'equipment.php:EquipmentPlugin'
);

?>

The

 return array(...);

statement is one that we are interested in, most of the items in the array are self explanatory. One interesting thing that we need to change is the:

'plugin' => 'equipment.php:EquipmentPlugin'

line. This is what tells OSTicket the entry point to our plugin. The syntax is ‘file name:class name’, so in this case our class is EquipmentPlugin and it is defined in equipment.php.

Part 2.  Plugin Configuration Page

Admin backend has a capability to show configuration options for your plugin.  These options are defined in:

config.php

Here is a sample file:

<?php

require_once(INCLUDE_DIR.'/class.plugin.php');
require_once(INCLUDE_DIR.'/class.forms.php');

class EquipmentConfig extends PluginConfig{
 function getOptions() {
 return array(
'equipment_backend_enable' => new BooleanField(array(
 'id' => 'equipment_backend_enable',
 'label' => 'Enable Backend',
 'configuration' => array(
 'desc' => 'Staff backend interface')
 )),
 'equipment_frontend_enable' => new BooleanField(array(
 'id' => 'equipment_frontend_enable',
 'label' => 'Enable Frontend',
 'configuration' => array(
 'desc' => 'Client facing interface')
 )),

 );
 }

 function pre_save(&$config, &$errors) {
 global $msg;

if (!$errors)
 $msg = 'Configuration updated successfully';

return true;
 }
}
?>

This class extends PluginConfig which is located in <INSTALL_ROOT>/include/class.plugin.php.

Function

getOptions()

returns an array with the plugin configuration options.  The array entry:

'equipment_frontend_enable' => new BooleanField(array(</pre>
'id' => 'equipment_frontend_enable',
 'label' => 'Enable Frontend',
 'configuration' => array(
 'desc' => 'Client facing interface')

defines a configuration variable named equipment_frontend_enable, this variable will be represented by a checkbox with id equipment_frontend_enable, and label Enable Frontend.  A checkbox will have a description title Client facing interface.  The following is a list of class fields that are available, they are defined in <INSTALL_ROOT>/include/class.forms.php:

  • TextboxField – text box
  • TextareaField – text area
  • ThreadEntryField – rich text area, used for discussion threads
  • DatetimeField – JQuery datepicker
  • PhoneField – text box optimized for phone numbers
  • BooleanField – checkbox
  • ChoiceField – drop-down select field
  • SectionBreakField – horizontal section break
function pre_save(&$config, &$errors)

This function will be called when configuration is submitted by user. Any server-side validation or additional business logic for configuration processing should go here.

To Part 3, Plugin Class ->