Nobody will be allowed to create a new ticket in the frontend of the site. This does not affect their ability to reply to existing tickets which have not already been closed.

Nobody will be allowed to reply to existing tickets which have not already been closed in the frontend of your site. This does not affect their ability to submit new tickets.

The maximum allowed size of the ticket's body text, in Kilobytes. Tickets larger than this will be rejected.

The ticket body size is calculated without taking into account any attachments. This feature only applies to tickets and ticket replies submitted through the web interface; tickets submitted by email are not subject to this check. This feature does NOT apply to support staff; the support staff can submit tickets and replies of any length.

This feature is meant to prevent extremely large posts, e.g. a client posting an entire log file inline instead of posting as an attachment. Overly long posts not only clog the database with unnecessary data, it will also make it very slow for the browser to display the page. The default value for this option is 128Kb, determined by examining over a decade of tickets and hundreds of thousands of posts on our site, adding a bit of wiggle room for the larger posts where an attachment would not necessarily make sense. For most sites you can set this as low as 32Kb without causing problems for your clients. If you have a use case which requires large inline text you can increase it up to 10240Kb (10Mb). Please note that post sizes over 512Kb may cause severe performance issues when displaying tickets.

When a ticket is over the limit the client will receive an error with the language string COM_ATS_POST_ERR_BODY_TOO_BIG. You can use Joomla's Language Override feature to customise this error message.

Only applies to user who have not been granted the Edit Own Ticket or Edit Own Post permission.

Setting this to a non–zero value allows all users to edit their ticket information and/or their post for a period of time after originally submitting it. This allows them to rectify some obvious mistake e.g. make an accidentally Public ticket Private, fix a typo in the ticket title or post, include some information they forgot to include the first time around, retry uploading an attachment that failed uploading etc. This option controls how many minutes after they first submitted their ticket / post they will be able to edit it.

Setting it to 0 disables this feature. Only users granted the Edit Own Ticket permission will be able to edit their ticket information and only users granted the Edit Own Post permission will be able to edit their posts.

Makes the Time Spent field mandatory for Support Staff users. This means that support staff won't be able to submit a ticket reply unless they fill in a non-zero time spent answering the ticket.

If you enable this option it's worth reminding your support staff users that they can and should use the Start Timer button next to the Time Spent field to automatically count the time they are spending on a ticket.

Only applies to Akeeba Ticket System categories which allow the Create privilege to the Guest (not logged in user) group.

Choose which CAPTCHA plugin should be used in the New Ticket page when a Guest user is submitting a ticket. The “Use Global” option tells Akeeba Ticket System to use the CAPTCHA plugin selected in Joomla's Global Configuration. The “– None Selected –” option tells Akeeba Ticket System to not show a CAPTCHA at all.

Please remember that you need to publish the plugin selected AND make sure that its Access is set to Public or Guest. Any other access level will make it impossible for Joomla! to display a CAPTCHA to Guest users and it may make it impossible to file tickets as a Guest. This is how Joomla itself works, not a limitation of Akeeba Ticket System.

Only applies to Akeeba Ticket System categories which allow the Create privilege to the Guest (not logged in user) group.

Normally, Akeeba Ticket System will honor the Options of Joomla's Users component. If you have disabled user registration Guests will not be able to file new tickets. If you have allowed user registration but require account activation (either by the users themselves or by an administrator) the relevant activation emails will be sent out.

When this option is enabled Akeeba Ticket System will ignore Joomla's settings. Filing tickets as a Guest will always result in a new, activated user being created.

Akeeba Ticket System's frontend is using the CSS classes provided by Boostrap 5 to style its output. This was a conscious decision; Bootstrap 5 is Joomla's default CSS framework. Using Joomla's default framework means we do not need to load yet another CSS file for our extension. This makes your site load faster.

If your site's frontend template is NOT using Bootstrap 5 then Akeeba Ticket System will appear unstyled. To fix that, we have this option here. Enabling it tells Akeeba Ticket System to load the file media/com_ats/css/frontend.css (or its media override) in the frontend of your site.

If you enable this option you most likely want to customise the CSS or even do template overrides for the component itself to better suit your site.