Support

Documentation

Options

[Note]Note

Some of the features described may only apply to the for-a-fee Akeeba Ticket System Professional edition.

The Options page is accessible through the back-end Components, Akeeba Ticket System menu item and then clicking on the Options button in the component's toolbar. These options define how Akeeba Ticket System behaves. This page has several sections.

Are you missing some options?

Starting with Akeeba Ticket System 3.2.0 the options formerly in the CLI Automation and Reply by Email sections have been moved into the plugins in the ats folder following the substantial overhaul of the Akeeba Ticket System automation. Please refer to the respective plugins for these options, namely:

Permissions

In this section you can determine the default permissions of each Joomla! User Group for all Akeeba Ticket System categories. If you prefer to define these settings per category remember to NEVER use a Deny rule here. A Deny rule here will override Allow in children user groups and categories. If you want to deny access just leave the default value, Inherited. Inherited (denoted by a faded "no entry" symbol next to it) is also known as a "soft deny" and will deny access unless you provide an explicit Allow in a child User Group or a category.

On top of the regular Joomla! permissions meanings, the permissions also have a special meaning to Akeeba Ticket System:

Configure

The user is part of your Support Staff and can reply to all tickets.

Access Administration Interface

The user is part of your Support Staff and can reply to all tickets.

Create

The user can create new public tickets

Delete

The user can delete tickets, posts and attachments

Edit

The user can edit the existing tickets and posts submitted by other users

Edit Own

The user can edit the posts he submitted himself (the limits set in the Frontend options do not apply to these users)

Edit State

The user can publish/unpublish any ticket, post or attachment, no matter who submitted it

Create Private

The user is allowed to create private tickets

Create Attachment

The user is allowed to upload attachments

Support Staff

This privilege is only available when you're configuring the permissions of categories. It gives the same privileges as "Access Administration Interface" but it is only applied to a specific category. If you want to have support staff which has administrative privileges across all categories please give the user group the "Access Administration Interface" privilege.

Updates

These options modify the way the integrated Live Update works

Download ID

Only applies to the Professional version. This is your AkeebaBackup.com Download ID. This can be found on our site, in the My Subscriptions page. You need to enter it to receive updates. Without it you will see that new versions are available but you will not be able to download them.

Enable anonymous PHP, MySQL and Joomla! version reporting

When enabled (default) you allow us to collect anonymous data about the PHP, MySQL and Joomla! version used on your site. We DO NOT record your site's IP address, domain name or any other personally identifiable information. Information is sent at most once a week and only when you visit Akeeba Ticket System's Control Panel page in the backend of your site. The only data sent is a randomly generated, (hopefuly) unique ID issued per site which CAN NOT be deanonymized (this means that it CAN NOT be traced back to a specific site, subscription or person), the PHP version you are using, the MySQL version you are using and the Joomla! version you are using. This information is used by us to make decisions about future development of our software, i.e. which old versions to drop.

Common

These are options which determine how various aspects of ATS will work.

Cross-browser Emoji compatibilty

Different browsers and operating systems have varying support for Emoji. In most cases they are displayed as full color pictures, in some cases they are displayed as monochrome outlines and in some cases they are not displayed at all. This lends to an inconsistent user experience, especially when the person writing a post and the person reading it are using different Operating Systems and browsers. For example, the US flag Emoji will indeed appear as a US flag to someone using Safari on macOS but to someone using Chrome on Windows 10 it will appear as the two letters U and S enclosed in squares.

Akeeba Ticket System can load the third party Twemoji library, created by Twitter, to replace Emoji everywhere in the ticket system with images thus providing a consistent user experience. The Twemoji library is loaded from MaxCDN -- the recommended source which is used by other sites as well -- meaning that it will load very fast if it's not already in your client's browser cache.

This option controls when to load the Twemoji library. None (default) means that it will never be loaded, therefore the browser is responsible for rendering Emoji correctly. The two options Frontend and Backend will only load the Twemoji library either in the site's public frontend or administrative backend respectively. The Both option will load the Twmoji library in both the site's public frontend and administrative backend.

Editor

Select the kind of editor you want to use for the post area. There are two options:

  • BBcode (form code). This is a lightweight plain text editor which allows optional formatting using BBcode, the same thing you use in various Internet forums. For example, [b]hello[/b] will print hello in bold letters.

  • WYSIWYG (Joomla!'s visual editor). This is the most advanced option. ATS will use the WYSIWYG (Joomla! visual editor) specified in the user's profile. That's the same editor you're using to edit Joomla! articles in the back-end. Such editors are TinyMCE (included with Joomla!), JCE, JoomlaCK and so on. This makes editing tickets much easier but it doesn't work very well on most tablets and many mobile devices. Which is why we have the next option below.

Forced BBcode editor UAs

As we said, the visual editor is very convenient but barely usable on most tablets and mobile devices. If you want to experience what frustration really means try posting a ticket reply using TinyMCE on an iPad or Nexus tablet. So, we came up with a workaround. Even if you have selected the WYSIWYG editor option above you can force certain devices to always use the lightweight BBcode editor. The filtering is done based on the User Agent string sent to your server by these devices' browser. Use a list of User Agent string parts separated by commas. The default string is:

; Android,iPad;,iPhone;,; Windows Phone OS,Windows Phone,; Windows CE,BlackBerry;,; Blazer,; BOLT/,/SymbianOS,(Symbian),Fennec/,GoBrowser/,Iris/,Maemo Browser,MIB/,Minimo/,NetFront/,Opera Mobi/,Opera Mini/,SEMC-Browser/,Skyfire/,TeaShark/,Teleca Q,uZardWeb/

As you can see it includes the User Agent signature of virtually every mobile device to hit the market at the time of this writing. We strongly suggest to leave it as it is unless you really want to frustrate your users.

Filtering method

When you are using the WYSIWYG editor your users get to submit arbitrary HTML. If left unfiltered there's a very high chance that someone will exploit this to launch an XSS (Cross Site Scripting) attack in order to hack you. ATS deals with it by filtering the incoming HTML. There are three filtering options:

HTML Purifier (best protection)

This uses the third party HTML Purifier library. It's slower but provides the very best protection you can get.

Joomla!

This uses Joomla!'s own HTML sanitiser. It's good, it's fast, it's not meant for this kind of user data and may fail miserably. We don't really recommend this option.

I want my site to be hacked (no protection)

This option is reserved for people who want their site to get hacked and developers who believe they've found a better filtering method than HTML Purifier and don't mind being hacked to disprove their point. No joking here. This option turns off all filtering. It's like jumping off a plane without a parachute. DON'T DO IT! It's not a question of whether you're going to get hacked. It's a simple question of when you'll get hacked.

Alternate HTML Purifier inclusion

Enable if you are using a PHP code cache or you are not sure what a PHP code cache is. As a rule of thumb: always set to Yes unless you know very well what you are doing. White pages lurk ahead if you set it to No when you shouldn't.

HTML Purifier allowed tags

For advanced users only. You get to specify which tags and attributes will be kept by the HTML Purifier filter. The default value is:

p,b,a[href],i,u,strong,em,small,big,span[style],font[size],font[color],ul,ol,li,br,img[src],img[width],img[height],code,pre,blockquote

Do not change unless you know what you are doing. If you remove everything from the list the default value will be used (otherwise all posts would end up blank).

Allow unsafe uploads

Joomla 3.5 and later automatically blocks certain uploads which might be unsafe for public consumptions, e.g. executable code. This might not be desirable if your ticket system is used to provide software support and uses the Private Attachments setting described below. In this case you might want to allow unsafe uploads so you can inspect them.

USE WITH EXTREME CAUTION. If you enable this option the security checks are indeed turned off and malicious code can be uploaded to your site.

As a precaution, ATS always renamed uploaded files to a random name without an extension, therefore ensuring that your site is not going to accidentally serve or execute any malicious code uploaded as an attachment.

If you are not sure keep this option DISABLED.

URL transliteration

A comma separated list of transliteration pairs, used to convert ticket titles to URLs. This is only used when Unicode Aliases is set to Off in your site's Global Configuration page. The transliteration pairs are given in the form: international character, followed by a pipe symbol, followed by the ASCII transliteration (unaccented Latin character(s) a-z). For example: π|p is used to convert Greek letter pi to "p" and ß|ss is used to convert the German eszett (sharp S) to its double s transliteration. The default value covers adequately most of European languages, including those based on Greek and Cyrillic character sets.

Enable ticket priorities

When enabled it allows the front-end users (your clients) to define the priority of the ticket, i.e. Low, Medium, High

Do not email non-assigned managers

When this option is enabled and a ticket is assigned to some member of the support staff the other members of the support staff are not being sent an email notification for the replies to the ticket.

Custom ticket statuses

You can create up to nine extra ticket statuses on top of the default three (Open, Pending and Closed). In this text area you have to enter one custom status per line in the format number, followed by equals sign, followed by the custom status description. For example 1=In Progress creates a new custom status with the title "In Progress". Custom statuses are shown in their numeric order. If you put a numeric key without a title or a title without a numeric key it will be ignored.

Attachments folder

Enter a folder where ATS will save ticket attachments.

You should not need to change the default path in most use cases. This option is meant for advanced customization by expert users. If you do not understand what this option does please do not change it. Your site will be fine with the default value.

The folder you enter here is sought on your server in the following order:

  1. As a subdirectory of your site's media folder.

  2. As a subdirectory of your site's installation root.

  3. As an absolute path on your server.

If the folder cannot be found in any of these ways ATS will use the default directory media/com_ats/attachments under your site's root.

[Important]Important

If you change this folder after attachments have been created, existing attachments will NOT be transferred to the new folder. You will have to do that manually. If you do not do that, the attachments will be unavailable for download.

Frontend

These options define how the front-end of ATS will behave.

Post edit timeout

All users are allowed to edit their posts. We have observed that very few users abuse this feature and edit the same post dozens of times instead of posting a reply. This, of course, screws up the entire concept of a ticket system. After all the post editing feature is supposed to be used for small corrections (like a mistyped word, a badly phrased part of the request and so on), not posting replies. In order to prevent users from abusing post editing you can use the Post edit timeout. This determines the maximum amount of time (in minutes) after a post's submission that the user is allowed to edit his/her post. The default value of 15 minutes seems to be the "sweet spot" between usability and preventing abuse.

Enter 0 to allow only people with the Edit Own privilege to edit their posts. These users are not affected by this limit.

Private attachments

When enabled attachments will only be visible to and can only be downloaded by to the user who created the ticket and the support staff, even in public tickets. When disabled, attachments in public tickets will be visible to and can be downloaded by everyone on the Internet.

No new tickets

When this option is enabled no user is allowed to create a new ticket. Users are still allowed to reply to existing tickets unless No New Replies is also enabled.

No new replies

When this option is enabled no user is allowed to reply to his existing tickets. Users are still allowed to file new tickets unless No New Tickets is also enabled.

Show credits information

When enabled Credits information will be shown in the front-end. Credits are the ATS "currency". Depending on your settings users will be charged credits to create or reply to their tickets.

Time spent field mandatory

When enabled the Time Spent field will be mandatory. 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.

Enable user feedback

When enabled the users will be able to rate the quality of the support they received on the ticket from 1-5 when they choose to close the ticket. The aggregate results will be shown in the leaderboard in the back-end Control Panel page of the component.

Enable AJAX replies

When enabled, replies to component in the front-end will be submitted using AJAX which means that the page won't have to reload (much less bandwidth consumption and much faster system response time). If your user's browser doesn't support this feature ATS will automatically show the regular submission form. If you have trouble submitting tickets that way please set this option to No and ATS will use the regular submission form which reloads the page upon the submission of a reply.

Instant replies day limit

The InstantReply feature will display related results from old public tickets when a user is trying to submit a new ticket. The tickets which will be showed are all public tickets which either have a status of Closed irrespective of how old they are OR have any other status but are older than X days. This option defines the X in the previous statement.

Show site template in InstantReply results

This options defines how the InstantReply reults are displayed to the user in the pop-up modal dialog when they click on the View button on each InstantReply result. When this option is set to Yes the site's template, including menus and modules, is displayed inside the modal box. When this is set to No the site's template is not displayed.

[Note]Note

The template display is turned off by passing the tmpl=component parameter to the URL. Your template needs to support this. Most templates do, but they might be using a different CSs stylesheet. As a result the display of the results when this option is turned off might not be the same as when viewing the relevant ATS ticket / DocImport article on your site.

Show CAPTCHA when filing Guest tickets

Only applies to Akeeba Ticket System categories which allow the Create privilege to the Guest (not logged in user) group. If this option is enabled (default) and a Guest user tries to file a new ticket they will have to solve a CAPTCHA for their ticket to be accepted. This is a good way to deter spam in ticket submissions by Guest users.

This feature will only work if you have enabled one or more plugins in the "captcha" group in Joomla's Plugins page and you have selected a default CAPTCHA method in Joomla's Global Configuration. The CAPTCHA shown to Guest users will be the one defined in Joomla's Global Configuration. Please note that the CAPTCHA plugin MUST have its Access 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.

Force user creation when filing Guest tickets

Only applies to Akeeba Ticket System categories which allow the Create privilege to the Guest (not logged in user) group. When this option is disabled (default), Akeeba Ticket System will abide by 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, however, 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.

Load Akeeba FEF

Akeeba Ticket System uses HTML markup compatible with the Akeeba Frontend Framework (Akeeba FEF) CSS framework. If you do not load FEF your ticket system will appear unstyled and some of its interface elements, such as dropdowns and tabs, will not work. This setting controls when to load Akeeba FEF's CSS and JavaScript files.

We strongly recommend keeping this option to Both.

The only time you might want to change it is if you are using Joomla! template overrides to output HTML compatible with the CSS framework used by your template. Please note that in this case you need to make sure that you also override the JavaScript files, otherwise your ticket system will not operate correctly.

Load CSS reset with Akeeba FEF

Only applies when Akeeba FEF is loaded per the previous setting.

Our CSS framework includes a feature called CSS reset, removing any third party styling from interface elements (such as input boxes) before applying its own CSS rules. It is recommended to enable it for consistency.

If you are writing custom CSS and find that the CSS reset gets in your way you can disable it by changing this options.

Dark Mode in backend and Dark Mode in frontend

Only use when also loading Akeeba FEF per the Load Akeeba FEF option notes above.

Akeeba Ticket System normally comes with a "light mode" stylesheet that uses dark text on light background. Most sites use a light theme so that makes sense.

However, if your site uses a "dark mode" stylesheet (light text on a dark background) this can have a jarring effect on your site's visitors. To this end, we created a Dark Mode stylesheet which can be optionally loaded.

These two settings determine if and when Akeeba Ticket System's Dark Mode stylesheet will be loaded in the administrative backend and public frontend respectively.

The Auto setting loads the Dark Mode stylesheet based on the browser's preferences. Namely, when the browser recommends the use of dark mode we load the Dark Mode stylesheet. Otherwise the Light Mode stylesheet is used. If you have a site template which automatically switched between Light and Dark stylesheets based on browser settings this is the setting you should use.

The Never setting means that ATS will always load the Light Mode stylesheet. This is what most sites need.

The Always setting means that ATS will always load the Dark Mode stylesheet. This should only be used if your site's template is using a Dark Mode (light text on dark background) stylesheet.

Credits

Credits are the ATS "currency". Depending on your settings users will be charged credits to create or reply to their tickets. These options determine how credits management will work in special cases.

Refund on unpublish ticket

If enabled, the credits charged for a ticket will be refunded if a member of the support staff unpublishes (disables) the ticket. Otherwise you will have to manually refund the user's credits (if you want).

Refund on delete ticket

If enabled, the credits charged for a ticket will be refunded if a member of the support staff deletes the ticket. Otherwise you will have to manually refund the user's credits (if you want).

Refund on unpublish post

If enabled, the credits charged for a post will be refunded if a member of the support staff unpublishes (disables) the post. Otherwise you will have to manually refund the user's credits (if you want).

Refund on delete post

If enabled, the credits charged for a post will be refunded if a member of the support staff deletes the post. Otherwise you will have to manually refund the user's credits (if you want).

Automation

These options modify the way the CRON URL works.

We strongly recommend using the CLI-based CRON script ats-cron.php instead of the CRON URL whenever possible. If you are only using the CLI-based CRON script you do not need to change any of the options here.

Secret Key

Enter a secret key that consists of letters a-z (without accents or diacritics) and numbers 0-9. Make sure it's at least 24 characters long. This key will need to be present in the CRON URL for it to work.

If unsure, you can use the Random.org password generator to create a truly random secret key.

[Warning]Warning

Do not use special characters, such as those delivered by pressing SHIFT and the numbers keys at the top of a US layout keyboard (e.g. !, @, # and so on). These characters don't work well in URLs and may cause your CRON URL to not work.

CRON URL time limit

The execution of CRON commands using the CRON URL will be limited to approximately no more than this many seconds. The default value, 10, is good enough for most sites. If you get server errors when accessing the CRON URL set this lower, e.g. 5. ANythign below 3 is practically unusable.

Do note that the mailfetch command may take more than this many seconds. After retrieving all unread email it will process at least one email before checking the time limit. This might be longer than the time limit defined here and it's deliberate. Fetching email may take a few or several seconds. If the time limit was checked before processing at least one email and the time limit had already been reached while fetching email messages you'd end up never processing any email at all. This would make the new ticket by email and reply by email feature essentially non-functional.

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.