Table of Contents
Some of the plugins are not available in Akeeba Ticket System Core.
Some features of Akeeba Ticket System require an integration with Joomla. As is usual, this is done through plugins.
We also use plugins to implement utility tasks which will can be set to run on a schedule.
The plugins can be found in the Joomla! plugins manager (, Manage area, Plugins link). The plugins are placed in different groups, depending on the kind of functionality they perform. This chapter is organised by plugin group.
Unlike plug–ins in the other groups, the ATS plugins are only loaded by and used in Akeeba Ticket System to implement task automation features.
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Automatically close old tickets
This plugin allows you to automatically close tickets with a status other than Open or Closed which have not received a reply from either the client or the support staff for a specific amount of time. It makes the autoclose CRON command available.
The idea behind this plugin is that some clients will see the reply from the support staff which addresses their issue but will neither reply nor close their ticket. Over time your support ticket system will show too many tickets as pending a reply from the client which makes it really hard for you to understand how many support cases are really open, making it potentially difficult to schedule your support staff. This plugin automatically closes stale tickets which are most likely resolved or for which the client has otherwise lost interest.
The plugin can send an automatic post on the ticket when closing it depending on the options below.
Eligible tickets older than this many days (but newer than the "Silent close period") will be set to Closed status, posting a notification that the ticket is closed because it's inactive. If you don't want to use this feature set it to a really long time e.g. 10950 (that's 30 years in days).
Eligible tickets older than this many days will be set to Closed status, without posting a notification. This must be a bigger number than the previous setting. Otherwise all tickets will be closed silently. If you don't want to use this feature set it to a really long time e.g. 10950 (that's 30 years in days).
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Automatic replies
This plugin allows you to send automatic replies to tickets, either instantly (when they are filed) or on a schedule. It makes the autoreply CRON command available when set up to do so.
You can set up the automatic replies and the rules under which they are sent in the Auto-replies page of the component.
Should automatic replies be processed immediately after a new ticket is created?
Be careful with this option. If an Auto-reply rule results in a reply being sent it will appear to be sent at the same time as the new ticket is submitted. This may confuse clients and they might even ignore the automatic reply, confusing it with the new ticket confirmation they received at the same time.
When enabled, it makes the autoreply CRON command available to the CLI CRON script and the CRON URL of ATS. This command processes all Auto-Reply rules for all currently Open tickets and sends the corresponding emails.
When you are using the auto-reply feature in Akeeba Ticket System you need one or more Joomla users to appear as the senders of the reply text. This is where you specify their usernames, one per line.
The users must already exist in your Joomla! site. If you have not created them already, go to Users, User Manager in the back-end of your site and create one or more users. These users DO NOT have to have Support Staff permissions in any ATS category. In fact, you never need to log in with these users or even have valid email addresses for them.
As an example, you can make a new user with the full name Automatic Reply, username auto_reply_bot and email address [email protected].
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Delete Manager Notes on ticket close / unpublish
This plugin allows you to delete the manager notes from tickets when they get closed or unpublished. It makes the deletnotes CRON command available when set up to do so.
This might be a requirement for EU GDPR compliance. If you collect personally identifiable or confidential information in Manager Notes -- such as social security numbers, login credentials etc -- you have to delete them when you no longer need them to fulfil the request of your client. Obviously, when a ticket is closed or unpublished we can reasonably assume that the request of the client has been fulfilled therefore there is no legal basis for keeping this information in the ticket system. This plugin can automatically delete that information either immediately at ticket close / unpublish or after the fact for all closed / unpublished tickets.
The options for this plugin are:
Automatically deletes the Manager Notes as soon as a ticket's status is set to Closed or when the ticket itself is unpublished.
When enabled, it makes the deletenotes CRON command available to the CLI CRON script and the CRON URL of ATS. This command will delete the Manager Notes from all tickets which are already closed or unpublished, in batches of 100 tickets.
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Fetch Email
This plugin is responsible for receiving email and creating ticket replies or new tickets. This feature is documented in its own documentation section.
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Remove Obsolete Attachments
This plugin allows you to automatically delete attachments a certain amount of time after they are sent. It makes the removeattachments CRON command available when set up to do so.
When enabled only attachments which are old enough and belong to already closed tickets will be removed. Otherwise all attachments, even from open tickets, will be removed if they are old enough.
Attachments older than this many days will be deleted.
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System — Web Push Notifications
This plugin sends browser push notifications alongside the email notifications that Akeeba Ticket System already sends for ticket events. When a ticket event triggers an email (new ticket, new reply, edited post, manager note, ticket assignment), users who have subscribed to Web Push will also receive a browser notification on each device where they have subscribed.
The subscription is global per user and device. Once a user subscribes on a browser, they will receive push notifications for all ATS emails they would normally receive. There is no per-ticket subscription. The same filtering and security rules that apply to email notifications (assigned manager only, notify/exclude staff, post author exclusion, ticket visibility) also apply to push notifications — the plugin hooks into the same event that fires once per email recipient.
Web Push requires HTTPS. It will not work on sites served over plain HTTP. Additionally, the user's browser must support the Web Push standard. Most modern browsers (Chrome, Edge, Firefox, Opera) support it. Safari has limited support.
Users can subscribe to push notifications in two places:
Ticket reply area. A subscribe button appears below the reply button on every ticket page, both in the front-end and the back-end.
User profile. A "Web Push Notifications" section is added to the user profile edit page (, My Profile, or the administrator profile page).
When a user clicks the subscribe button, their browser will ask for permission to show notifications. If the user grants permission, the subscription is saved and the button changes to an unsubscribe button. Users can unsubscribe at any time by clicking the unsubscribe button.
Each browser and device requires its own subscription. Subscribing on Chrome on a desktop computer does not automatically subscribe Firefox on the same computer or Chrome on a mobile phone.
When enabled, the plugin writes detailed debug log entries to a separate log file (plg_ats_webpush.php) in Joomla's log directory. This is useful for troubleshooting notification delivery issues. You should disable this option in production to avoid unnecessary log file growth.
VAPID keys. The plugin uses VAPID (Voluntary Application Server Identification) keys for authentication with push services. These are automatically generated on first use and stored in the component's parameters. Do not change or delete the VAPID keys; doing so will invalidate all existing push subscriptions.
Subscription storage. Push subscriptions are stored in Joomla's #__user_profiles table under the key com_ats.webPushSubscription. No additional database tables are required.
Notification grouping. Notifications for the same ticket are grouped using a tag (ats-ticket-{id}). This means a new notification for the same ticket will replace the previous one on the user's device, preventing notification clutter.
Click action. Clicking on a push notification opens the ticket in the browser.
This plugin is NOT available in Akeeba Ticket System Core.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System – WebHooks
This plugin POSTs a JSON payload to one or more external URLs (“consumers”) whenever a ticket, post, or attachment is created, updated, or deleted. It lets systems outside Joomla react to activity in your ticket system in real time.
Akeeba Ticket System already lets third party code react to interesting events through the Joomla plugin system. This is only useful when that code runs inside Joomla. There are, however, many legitimate use cases for notifying an external service: an automation workflow that pages the on-call engineer when a critical client reports an outage; a machine translation service that detects the language of an incoming post and appends a translation; a classifier that detects leaked credentials in a public ticket and redacts them; and so on.
WebHooks make this possible by reaching out of Joomla, over HTTP, the moment something happens.
A WebHook is rarely useful on its own. It is an asynchronous trigger — much like the email notifications Akeeba Ticket System sends, but immediate and machine-parseable. It is not meant to be the only visibility and interaction channel. WebHooks are best paired with the Joomla API application integration, which the consumer uses to fetch additional information and to act back on Akeeba Ticket System (updating a ticket, replacing a post body, and so on). The payloads below deliberately omit bulk and binary data (for example, attachment file contents); fetch those through the API by their id.
WebHook delivery is fire-and-forget and best-effort. Each consumer is given only a few seconds (the configurable timeout) to respond, there is no retry, and a slow or failing consumer is simply logged and skipped.
This means a consumer that needs to perform a lengthy processing step — calling a classifier, sending a push notification or text message, contacting another API, and so on — MUST respond immediately and enqueue the received information, then act on it asynchronously in a separate queue-processing loop. If your consumer does the heavy lifting inline it will hit the timeout and the notification will be recorded as failed.
How long to wait for each consumer to respond before giving up. Defaults to 2 seconds. Keep this low; see the warning above.
When enabled, each delivery and failure is recorded in the plg_ats_webhooks.php log file in Joomla's log directory. Use this to troubleshoot consumers; leave it off in production.
The list of external endpoints to notify. For each consumer you provide a Title (for your own reference), a WebHook URL (the absolute https or http URL the payload is POSTed to), the Events it should be notified about, and optional Extra HTTP headers sent with each request. New consumers have all events selected by default. The extra headers are entered one per line, for example Authorization: Bearer mySuperSecretToken.
Every WebHook is an HTTP POST with a Content-Type: application/json body of the following shape:
{ "event": "ticket_new", "timestamp": "2026-06-22T12:34:56+00:00", "site": "https://www.example.com/", "data": { ... }}The event is one of the eight event names below, timestamp is the UTC dispatch time in ISO-8601 / RFC-3339 format, site is the base URL of your site, and data contains the affected entity's fields. ATS also sends any optional extra HTTP headers you configured for that consumer, in addition to the JSON body.
The top-level payload fields are:
eventType: string. Mandatory: yes. Contains the event type. The value is always one of: ticket_new, ticket_update, ticket_delete, post_new, post_update, post_delete, attachment_new, or attachment_delete.
timestampType: string. Mandatory: yes. The UTC time when ATS dispatched the WebHook, formatted as ISO-8601 / RFC-3339, for example 2026-06-22T12:34:56+00:00.
siteType: string. Mandatory: yes. The public base URL of your site, normally taken from the com_ats siteurl option and otherwise from Joomla's root URL. It may be an empty string if ATS cannot determine a site URL in the current execution context.
dataType: object. Mandatory: yes. Contains the entity-specific fields for the ticket, post, or attachment which triggered the event.
The following examples show the actual JSON structure sent to consumers.
ticket_new / ticket_update / ticket_deleteA ticket was created, modified, or deleted.
{ "event": "ticket_new", "timestamp": "2026-06-22T12:34:56+00:00", "site": "https://www.example.com/", "data": { "id": 314, "catid": 12, "status": "O", "title": "Cannot log in after password reset", "alias": "cannot-log-in-after-password-reset", "public": 1, "priority": 5, "origin": "web", "assigned_to": 0, "created": "2026-06-22 12:34:55", "created_by": 875, "modified": "2026-06-22 12:34:55", "modified_by": 875, "enabled": 1 }}The ticket data object contains these fields:
idType: integer. Mandatory: yes. Internal ATS ticket id.
catidType: integer. Mandatory: yes. Joomla category id the ticket belongs to.
statusType: string. Mandatory: yes. Ticket status code. Built-in values are O (open), P (pending), and C (closed). Custom statuses are numeric strings from 1 to 99.
titleType: string. Mandatory: yes. Human-readable ticket title.
aliasType: string. Mandatory: yes. Ticket alias / slug.
publicType: integer. Mandatory: yes. Visibility flag: 1 for public, 0 for private.
priorityType: integer. Mandatory: yes. Ticket priority value.
originType: string. Mandatory: yes. Indicates where the ticket came from, typically web or email.
assigned_toType: integer. Mandatory: yes. Joomla user id of the assigned manager. 0 means unassigned.
createdType: string or null. Mandatory: yes. Creation date and time in UTC, usually in YYYY-MM-DD HH:MM:SS format.
created_byType: integer. Mandatory: yes. Joomla user id of the user who created the ticket. 0 means unknown or system-created.
modifiedType: string or null. Mandatory: yes. Last modification date and time in UTC, usually in YYYY-MM-DD HH:MM:SS format.
modified_byType: integer. Mandatory: yes. Joomla user id of the user who last modified the ticket. 0 means unknown or system-modified.
enabledType: integer. Mandatory: yes. Publication flag: 1 enabled, 0 disabled.
post_new / post_update / post_deleteA post (ticket reply) was created, modified, or deleted.
{ "event": "post_update", "timestamp": "2026-06-22T12:47:10+00:00", "site": "https://www.example.com/", "data": { "id": 991, "ticket_id": 314, "content_html": "<p>Please try again now. I have reset the account manually.</p>", "origin": "web", "created": "2026-06-22 12:46:01", "created_by": 52, "modified": "2026-06-22 12:47:09", "modified_by": 52, "enabled": 1, "attachment_id": "144,145" }}The post data object contains these fields:
idType: integer. Mandatory: yes. Internal ATS post id.
ticket_idType: integer. Mandatory: yes. Parent ticket id.
content_htmlType: string. Mandatory: yes. Full HTML body of the post.
originType: string. Mandatory: yes. Indicates where the post came from, typically web or email.
createdType: string or null. Mandatory: yes. Creation date and time in UTC, usually in YYYY-MM-DD HH:MM:SS format.
created_byType: integer. Mandatory: yes. Joomla user id of the user who created the post. 0 means unknown or system-created.
modifiedType: string or null. Mandatory: yes. Last modification date and time in UTC, usually in YYYY-MM-DD HH:MM:SS format.
modified_byType: integer. Mandatory: yes. Joomla user id of the user who last modified the post. 0 means unknown or system-modified.
enabledType: integer. Mandatory: yes. Publication flag: 1 enabled, 0 disabled.
attachment_idType: string. Mandatory: yes. A comma-separated list of attachment ids linked to this post. An empty string or 0 means there are no linked attachments.
attachment_new / attachment_deleteAn attachment was created or deleted.
{ "event": "attachment_new", "timestamp": "2026-06-22T12:47:11+00:00", "site": "https://www.example.com/", "data": { "id": 145, "post_id": 991, "original_filename": "console-error.png", "mime_type": "image/png", "origin": "web", "created": "2026-06-22 12:47:10", "created_by": 52, "enabled": 1 }}The attachment data object contains these fields:
idType: integer. Mandatory: yes. Internal ATS attachment id.
post_idType: integer. Mandatory: yes. Parent post id.
original_filenameType: string. Mandatory: yes. The original filename reported by the uploader.
mime_typeType: string. Mandatory: yes. MIME type of the attachment, for example image/png or application/pdf.
originType: string. Mandatory: yes. Indicates where the attachment came from, typically web or email.
createdType: string or null. Mandatory: yes. Creation date and time in UTC, usually in YYYY-MM-DD HH:MM:SS format.
created_byType: integer. Mandatory: yes. Joomla user id of the user who created the attachment. 0 means unknown or system-created.
enabledType: integer. Mandatory: yes. Publication flag: 1 enabled, 0 disabled.
The file contents are never sent, and the internal stored filename is intentionally omitted. Retrieve attachment contents through the API application if needed. There is no attachment update event.
Delete events use the same field sets as create and update events. The data.id field is always populated whenever ATS knows the deleted record id. The remaining fields are still included in the payload, but they may be null if ATS no longer has the corresponding values available at dispatch time.
A single user action can legitimately fire several WebHooks. For example, creating a new ticket with an attachment fires ticket_new, post_new, ticket_update (the opening post updates the ticket), attachment_new, and post_update (the attachment is linked to the post). Each is a real state change, they may arrive in any order, and they are not de-duplicated. Your consumer must therefore be idempotent.