Hello Everyone!
TLDR: I'm building an API for OS Ticket and was wondering if anyone would be interested in it.
I've been a OSTicket (open source version) since about version 1.1 (a pretty long time). I've been happy with it and it has run along with barely any issues. I've upgraded to 1.8.1 when it came out and love it. My whole school uses it as the main facilities/IT ticketing system. I've never actually developed anything on it, but have used some plugins.
One of my new projects now is to implement AI into the whole school. It's a daunting task that I expect will take quite a long time, as AI is really new and changing. However, one of the goals that I have in order to start is to make an AI for our Operations team (Facilities/Security/IT) that we can ask questions. In order to do this, I wanted to make the tickets available to the AI through some sort of API's (which would be accessible by an MCP server as tools)
I looked into the API system in OSTicket, but I found it really hard to extend. Essentially, the API routes are defined in api/http.php like so:
$dispatcher = patterns('',
url_post("^/tickets\.(?P<format>xml|json|email)$", array('api.tickets.php:TicketApiController','create')),
url('^/tasks/', patterns('',
url_post("^cron$", array('api.cron.php:CronApiController', 'execute'))
))
);
// Send api signal so backend can register endpoints
Signal::send('api', $dispatcher);
This means that in order to add endpoints I would need to add more patterns to the API's that I would like to have. I couldn't figure out how to tie this in through plugins, as it seems to be tightly coupled, to the point that the only way to add more API's would be to change a lot of the code. Even then, since OS Ticket is not using any kind of framework, so it would simply take too long to add the API's that I needed. While researching the code, I was also figuring out how the database structure is set up, and what tables link to what and how. The code uses a few functions to establish model relationships in each of the classes, so this was easier than I though.
This led me to the idea that, using a good framework, I could just build my own models based on the database and then set up an API system that way. My original thought was to make it read-only, as I really didn't want to write to the DB without fully grasping the validation information. But since all I needed for the AI was to read things, it made the most sense.
So I picked Laravel, which is a PHP framework that I'm most familiar with and has pretty robust API support. I then built models that would mirror the database models and created the relationships through Laravel's Eloquent system. It actually worked pretty well. I can call the api at https://api.tickets.example.com/api/tickets/list and get this:
{
"data": [
{
"id": 1,
"number": "####",
"from": {
"id": 1,
"name": "osTicket Support",
"email": "####"
},
"status": "Closed",
"locked": false,
"department": "IT Support",
"sla": "Default SLA",
"staff": null,
"team": "No Team",
"topic": "Computer Problem",
"answers": [
{
"Issue Summary": "osTicket Installed!",
"Priority Level": "Normal"
}
],
"subject": "osTicket Installed!",
"classroom": "No Classroom",
"priority": "normal",
"threads": [
{
"id": 1,
"last-message": "2014-03-12 12:06:37",
"created": "2014-03-12 12:06:37",
"messages": [
{
"id": 1,
"poster": "osTicket Support",
"title": "osTicket Installed!",
"body": "<p> Welcome! </p>",
"created": "2014-03-12 12:06:37",
"updated": "0000-00-00 00:00:00"
},
{
"id": 2,
"poster": "SYSTEM",
"title": "Ticket Marked Overdue",
"body": "Ticket flagged as overdue by the system.",
"created": "2014-03-24 11:01:11",
"updated": "0000-00-00 00:00:00"
},
{
"id": 21,
"poster": "John Smithn",
"title": "Ticket Closed",
"body": "Ticket closed without response by John Smith",
"created": "2014-03-25 08:31:57",
"updated": "0000-00-00 00:00:00"
}
]
}
]
},
...More tickets
]
}
I added quite a few endpoints and protected them with API tokens so that only configure clients can log in. I haven't added a users system since I'm still working on the backend, but adding one is pretty trivial using Laravel's scaffolding.
My question is if anyone would be interested in this project? I'm going to be publishing to GitHub soon and I usually add all my projects as private but, if anyone is interested, I wouldn't mind releasing it to the OS Ticket community through a public repo. The code is pretty extensible, so adding more API's to create/update/delete things would be pretty simple to do. I also haven't mirrored all the models as I haven't quite deciphered them yet.
Thank you for reading this novel :-)
