osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go
get it now
We're designing the beginnings of a plugin architecture for osTicket 1.8. It won't quite make osTicket 1.8.0, but it will definitely be part of osTIcket 1.8.1 later this year. Since I'm overhauling a few components of the system to make them more extensible, I'm interested in hearing your input on what parts of osTicket should be made more pluggable. What types of plugins do you think osTicket should support?
osTicket 1.8.1 will ship with two "classes" of plugins. The first is pluggable authentication, which will enable plugins to extend the authentication mechanism of osTicket beyond the built-in username/password information stored in the staff table. Things like LDAP, Kerberos, Active Directory, RADIUS, Google, and HTTP pass-thru authentication, etc., will all be installable and configurable via plugins.
The second is pluggable attachment storage, which will re-enable storage of attachments on the file system, or perhaps more creative solutions, like using Amazon S3. I'm also interested in writing a archive and retention plugin which will simply integrate with the cron system to retire (delete) or offload attachments by moving them to another storage backend (like from the database to S3).
Another idea I have is to allow a plugin to define email templates and interact with the ticket lifecycle in order to send new ticket alerts or auto-responses, such as the often-requested ticket-closed email.
Yet another idea is to allow plugins to create something like a "widget", which can be configured in the staff or admin panel and shown in the staff or client panels. Some ideas of using the widgets might be like a "message-of-the-day" widget or a clock widget to facilitate time tracking.
Of course, the greatest concerns in the plugin architecture is internationalization and API integration that won't obsolete plugins at the next version of osTicket.
I'm working through the early details of the plugin architecture, and I hope to create something that can retire "mods" and create a new marketplace per se with community plugins available to be installed alongside the stock osTicket. I'd really like to hear your feedback about what things osTicket should be able to do via plugins.
Cheers,
Jared
Comments
First, I definitely agree with Authentication (LDAP, AD, RADIUS, etc.) and all the other features mentioned above at your post Jared ;)
For us here the following plugins/mods are the most important ones:
- CC/BCC
- (better) Time Tracking
- (better) Reporting
- (better) KnowledgeBase/FAQ system (fyi: we are using DokuWiki here at the moment)
The other plugins/mods mention here would also be nice to have, but they are not as necessary as the ones above.
@ntozier: Asset Management [equipment]
Do you search for something like ITDB http://www.sivann.gr/software/itdb/ or a similiar system or what exactly do you mean by Asset Management?
Btw: Despite ITDB we still searching for an easy (php/web based) device/equipment rental system to check availability and book devices/equipment and so on, but that's offtopic so please ignore ;)
EDIT/UPDATE:
Forgot to say, that an option to gather informations (e.g. Room, Phone-Number, etc.) from LDAP/AD to autofill client details would be really nice :) ;)
btw osTicket has a better FAQ/KB system just recently and there are plans to improve it further in the future.
I am setting up Ozticket on my website as a strategic move from comm100 that I have used for many years . I am using ozticket 7.2 and I find I need the following :
Time tracking and reporting
Time Scheduling ( to age and monitor Ticket / Staff performance by time as in "Auto update " and " Auto Follow-up " based on time)
More flexiblity with the SLA setup
Ability to add additional Drop-downs
Merge Tickets
Batch Assign ( and Delete )
Next / Prev ticket buttons
Duplicate ticket warning
Reporting similar to "Scottro's Reporting mod " ( which is a very close replication for comm100's )
then, as ntozier indicates,
DB Cleanup tools
Followup / Customer Rating system
Here I need to say it would be nice if we could settle down to some ( limited ? ) structure / coding standardization as the way forward. I am finding that the majority of the wishlist above are catered for in the mods but for lower versions with the corresponding files obsoleted in 7,2 .
Example is the infamous "viewticket.inc.php" that is used in many mods.
Further reflection, what would be really great is to do as zencart does,
a) a link from the scp / admin panel to the ozticket homepage / forum / mods section
b) a "Developers Tool Kit" section to find specific code
c) a " install SQL Patches" section for SQL mods
d) a Section in the ozticket forum where all the mods are packed for ease of installation, each mod has its own section with upgrades, comments, developer etc
In addition to what have already been said.
My idea of plugin could be to add a project management on the top of tickets so that we can manage projects, plan it with tickets and get a full history of a project tasks, maybe with a gantt view for planning and a gantt view with the time really spent.
It could go along with a calendar and duedates could be seen in that calendar (so as in Trello.com).
The calendar could be using caldav.
Another one could be to make the client-side customizable in scp admin section so that we can easily without doing any change in the code, add page links.
Create several function hooks or notifications, for example onTicketOpen, onTicketClose, etc., and a plugin management panel. This way plugin structure can be standardized and it'll be much easier to extend the OST.
I can take a stab at it myself, but I don't think that I'll have enough time to finish it by the next release date.
Firt of all, I vote for a multi-language support.
As far as suggestions go, for us small service providers, it would be great if there was a way to group customers as "companies." Perhaps offering each company a branded login page/web address on the front end and then per-company reporting on the back end.
Open the settings, press the "Add new user..." button, pick an icon, add a name, Bingo. Its like having several versions of Incognito simultaneously.. you can login to google on each, have your own bookmarks synced down etc.. handy.
Then just pick the user-icon in the top left (it will appear when a second user is added), to switch between em.
All the details: https://support.google.com/chrome/answer/2364824?hl=en
If the db was just a "datastore" instead of an integral part of how it works, then it really wouldn't matter what system was implemented. Having options (like, a dozen different plugins for the database) might entice more players to the game. MegaCorp might not like being tied to Maria for instance.
I would like caching plugins as well, APC/Memcached/File-based/etc, even json dumps of configs instead of having to regenerate them for each view.. could cache stats and such too.. really reduce the db-load, entire client pages should be in memory, rather than being generated, APC opcode saves stat calls a lot, and its very fast, but it really shouldn't be dynamic at all if there is no changing data on the client homepage! (I know, but you simply expire the cache if you enable the kb)
(See my Mod_Memcached mod for examples of pregenerating pages/pieces, but it could/should be extended to all non-dynamic pages, without having to manually modify the parent page.. http://www.osticket.com/forum/discussion/75438/mod-memcached)
I've built a location detector module as well.. it converts faxes into tickets (via email), takes the number they sent it from, determines how close that area code is to our warehouse and prioritizes the ticket based on that. within 15km, gets emergency priority, as some customers actually fax an order then come over and expect to be able to pick up the goods.. not sure if anyone would be interested, let me know, but mainly, the mailfetch class got hacked up a bit and a few new classes added to parse the subject.. not sure how you would expose that for plugins.. perhaps you could just add to the "filters" and specify a "Class" to instantiate before the end of the mailfetch or something..
Its possible to modify the menu's.. in code.. would be fun if you could "re-arrange them" in the admin interface, a plugin for that would be cool, even its its just to add items.. I like our sales-guys to be 100% in osTicket, so finding our product information has our own jQuery auto-complete search-box and links to our sites within reach at all times. Plugging into it wasn't that hard, but continually rebasing hacks for each new version is tiresome and they would be better implemented as "plugins", even custom, private plugins would be cool!
Of course pluggable "skins" might be desirable for some people.
Somebody mentioned project management. That gets a nod from me.
On the "general modification" front (for v1.8.x) , it'd be useful for the SLA feature to include a setting not only for closure but also for initial response time (not the canned response, but one that indicates an actual person has read and begun to understood the ticket).
It would be good to be able to include other data as columns in the default ticket list display (e.g. including custom fields and company name) and have the option to sort/group accordingly. A printable view would be good. This is all heading, of course, to others' suggestions w.r.t. reports.
It would be useful to limit some staff' members' access, either to read-only and or to a specific product type/group.
Regards,
Aidan
I've though about another feature which could be added by plugins : A knowledge base FAQ revision history.
I'm not sure everybody needs this, so it's the reason why it could be a plugin.
Another one : ticket planned re-opening. So a ticket "sleep". They are closed for a given duration.
Best regards
I was working on a ticket-generator plugin, for testing my dev install, and it struck me that with chunked data in the database, there really was no way of scanning attachments for virii.. but the fs-storage would allow that, so ba-da-bing, a new plugin-idea!
I'll push it to my repo when its "functional", and you guys can have a look.
1) Time tracking, rhe ability to enter time spent everytime we update the ticket. I've never been able to make the mod work quite right.
2) LDAP autentication, for clients
3) Most of my tickets come via email, so source, topic, dept and assigned tech are never right. A popup to come up on first open to force us to fill those out would be great.
Not impossible, just requires code modification.. If you are using mail-fetching rather than piping, I modified class.mailfetch.php to test for an admin-defined array of addresses, then ran my custom code over the message before allowing osTicket to proceed.. also helps for logging when we receive "troublesome" messages.. or those "one in a million" guys who seem to send "breaks everything" messages.. which we can run through a wpad.dat parsers.. ;-)
I find after :
//email to ticket
function createTicket($mid) {
global $ost;
if(!($mailinfo = $this->getHeaderInfo($mid)))
return false;
To be a useful starting point.. ;-)
customer to scp staff
Like 100 tickets done in last month, 5 were overdue, ...
do notice that this is not ment to be detailed, just a nice overview so people can see if the helpdesk is under heavy load or just normal/calm, ...