This documentation page does not apply to our software versions for Joomla! 4.0 and later versions. If you are not using Joomla 3 please consult the documentation index to find and read the correct version of the documentation.
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
, menu item and then clicking on the button in the component's toolbar. These options define how Akeeba Ticket System behaves. This page has several sections.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:
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:
The user is part of your Support Staff and can reply to all tickets.
The user is part of your Support Staff and can reply to all tickets.
The user can create new public tickets
The user can delete tickets, posts and attachments
The user can edit the existing tickets and posts submitted by other users
The user can edit the posts he submitted himself (the limits set in the Frontend options do not apply to these users)
The user can publish/unpublish any ticket, post or attachment, no matter who submitted it
The user is allowed to create private tickets
The user is allowed to upload attachments
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.
These options modify the way the integrated Live Update works
Only applies to the Professional version. This is your Akeeba 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.
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.
These are options which determine how various aspects of ATS will work.
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:
This uses the third party HTML Purifier library. It's slower but provides the very best protection you can get.
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.
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.
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.
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).
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.
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.
When enabled it allows the front-end users (your clients) to define the priority of the ticket, i.e. Low, Medium, High
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.
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.
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:
As a subdirectory of your site's
media
folder.
As a subdirectory of your site's installation root.
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 | |
---|---|
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. |
These options define how the front-end of ATS will behave.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 | |
---|---|
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. |
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.
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.
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.
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.
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 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.
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).
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).
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).
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).
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.
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 | |
---|---|
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. |
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.