We did a full code audit for Akeeba Ticket System, catching and fixing a plethora of quality issues.
Until now, a public ticket was readable by anybody who had its URL — including visitors who were not logged in — even when it lived in a category whose View Access Level was granted to a single user group. That was a very strict interpretation of what “Public” means, but probably not what most site owners would have expected. The discrepancy between our interpretation and expectation could create a situation where the site owner is caught unaware by Public tickets being accessible by anyone, possibly indexed in search results, etc.
Starting with Akeeba Ticket System 5.6.0 we follow a stricter definition. A Public ticket is one which is visible to all users who can view the ticket category itself. If your ticket category has Public access, public tickets are like before: guests can view them. If your ticket category has Registered access, public tickets are now only visible to Registered users, but not to Guest users.
This will be visible on your site. If you have tickets in a category whose View Access Level is not held by everyone, the users who do not hold that level will stop seeing those tickets. That is the point of the fix, but it will look like tickets have vanished.
Two exceptions are deliberate and preserved: the person who filed a ticket can always read it, and so can anyone who was explicitly invited to it, whatever the category's access level says. This is both common sense (if I've filed a ticket I should be able to view it) and prevents the worst adverse effect of this change on practical use cases.
If tickets disappear where you did not expect it, check the View Access Level on the ticket's category and the levels held by the user groups which should be able to see it. Nothing has been deleted or altered — only who is allowed to read it.
A new Pro plugin, ATS – WebHooks, POSTs a JSON payload to a URL of your choice when a ticket or post is created, modified or deleted, and when an attachment is added or deleted. You can define several consumers, each with its own URL, its own selection of events, and its own custom HTTP headers — enough to authenticate against most automation services. This lets you plug ATS into Zapier, n8n, Make, a chat channel, or your own internal tooling without writing a Joomla plugin. The payload format is documented in the user's manual.
The Field – SQL with User Data custom field plugin has been removed. The plugin's entire purpose was to run an administrator-authored SQL query with the current user's data substituted into it, which cannot be made safe: any query text that reaches the database is under the control of whoever can edit the field, and the substituted user data cannot be reliably escaped for every SQL construct someone might write. We could not find a way to keep the feature and secure it, so we withdrew it.
If you were using this field type, its fields will stop rendering after the update. Joomla's own Fields – SQL plugin covers the cases which do not need per-user substitution. For anything which genuinely needs the current user's data, a small site-specific plugin of your own is the safe route.
The Microsoft 365 mail fetch integration always added prompt=consent to its OAuth
authorisation URL, forcing the consent screen on every authorisation. On tenants where an
administrator has already granted consent organisation-wide, that is at best redundant and at
worst a dead end for non-administrator accounts. There is now a Force re-consent plugin
option. It is enabled by default, i.e. the behaviour is unchanged unless you turn it off.
Akeeba Ticket System now ships machine translations for Greek, French, German, Spanish, Italian and Portuguese. These are machine-generated and reviewed only lightly; corrections are welcome on our GitHub repository.
The automatic reply scheduled task could not complete on any site where it had something to do. It failed on a database error before it examined a single ticket, and three further faults were waiting behind that one. All are fixed.
Separately, even when a reply was posted the customer was never told: the notification code lived somewhere the scheduled task could not reach it. An automatic reply now notifies the ticket owner, the support staff and any invited users, exactly as a reply typed by a human does.
Setting the mail fetch plugin's mailbox type to POP3 never retrieved a message — not occasionally, but on every run since the option was offered. The plugin asked the server for unread messages, which is a concept POP3 does not have, and the scheduled task quietly reported success anyway. If you have been running a POP3 mailbox and concluded it was simply never getting any mail, it is worth checking that mailbox now.
IMAP, Gmail and Microsoft mailboxes were not affected.
A ticket, post, manager note or attachment which the API refused to include in a listing could still be fetched directly by its numeric ID. Both now apply the same rules.
No code change, but the manual now describes the situation explicitly, to prevent any
misunderstandings which could've led to a potential security incident.
Uploaded attachments have to be stored under your site's root, because Joomla's convention
is that an extension's user-generated content – including uploads – live in a subdirectory of
the media directory under your site's root. We do ship a .htaccess
file, which works on most Apache and LiteSpeed servers, and a web.config, which
works on most IIS servers. Neither can possibly work on all servers – it's ultimately up to
your host or system administrator and the way they configured the web server – and neither has
any effect on NginX, which has no per-directory configuration mechanism for us to use.
The scrambled, extension-less filenames make an attachment impractical to find by guesswork. The fact there is no extension means that, barring serious web server misconfiguration, even if an attacker could guess the filename, they would not be able to execute the contents of the uploaded file as PHP code. However, this kind of scheme is not access control; it's obscurity. It doesn't close the door, it makes it really darned hard to find even if you know it's gotta be there.
The user guide now includes the server configuration needed to deny direct access to
media/com_ats/attachments on Apache, LiteSpeed, IIS and NginX, and a way to check
that it took effect. If you handle anything sensitive in attachments, please apply it.