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
Akeeba Ticket System's Options - 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:
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.
Akeeba Ticket System's Options - Updates
These options modify the way the integrated Live Update works
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.
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.
Akeeba Ticket System's Options - Common
These are options which determine how various aspects of ATS will work.
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.
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.
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:
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).
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
Akeeba Ticket System's Options - Frontend
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.
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 Bootstrap 2 (front- and backend) and Bootstrap 3 (frontend). If you are using a template which does not have compatibility with Bootstrap 2 or 3 markup everything will display wrong. Akeeba Strapper is a special Boostrap 2 distribution designed to work in tandem with incompatible templates, allowing our software to render correctly.
Akeeba Ticket System's Options - 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.
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).
Akeeba Ticket System's Options - CLI Automation
These options modify the way the CRON job scripts work.
Attachments older than this many days will be deleted by
ats-remove-attachments.php CRON script
Open / Pending tickets older than this many days (but
newer than the "Silent close period") will be set to Closed
status by the
CRON script, posting a notification that the ticket is closed
because it's inactive.
Open / Pending tickets older than this many days will be
set to Closed status by the
ats-autoclose-tickets.php CRON script,
without posting a notification.
When you are using the auto-reply feature in Akeeba Ticket System you need one or more 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. Then put their usernames in the Bot usernames setting inside the Options page of Akeeba Ticket System.
Akeeba Ticket System's Options - Reply By Email
These are the parameters which allow users to reply or create new tickets by sending emails to your site. Please remember to enable the respective plugin or the CRON job script.
When enabled allows users to reply to their tickets by email.
When enabled the Reply by email feature is only available for managers
When enabled allows users to create new tickets by emails. Obviously, the user needs to send the email from the email address he used to register on your site.
This is dangerous! A user with an auto-reply may cause an endless amount of tickets being created all the time. We strongly recommend NOT using this option.
When enabled Akeeba Ticket System will track the unique identifier of each email message it has processed to prevent double posting of tickets e.g. when an error occurs after a new ticket is created but before it's marked as read / deleted. This is recommended to be enabled on production sites.
When enabled Akeeba Ticket System will try to retrieve the plain text version of the email and use it as the post content. If the user's mail client only sends an HTML version of the email this could cause empty tickets to be posted.
The category where the new tickets created by the "Create ticket by email" feature will be placed.
If you are using GMail set this to Yes. The rest of the options (except Username and Password) are ignored.
THE FIRST TIME YOU TRY TO CONNECT AKEEBA TICKET SYSTEM WITH YOUR GMAIL ACCOUNT YOU WILL HAVE TO PERFORM A LOT OF MANUAL STEPS. THIS IS A GMAIL RESTRICTION, NOT A PROBLEM WITH OUR SOFTWARE.
GMail will automatically and by default block IMAP access to your GMail and Google Apps email from any remote server unless you MANUALLY tell it to allow it by following a complicated and ill-documented procedure. GMail will also block ATS again every time your server's IP address changes, or your password changes or whenever they feel like it. This is in complete violation of how the IMAP standard works but Google can get away with it because it's the 800 pound gorilla of the Internet.
In order to connect to GMail you will have to:
We'd like to clarify in the most unambiguous tone that this complicated procedure is NOT our fault, NOT our doing and NOT something we can "fix". This procedure is enforced by Google itself. We understand your frustration with this, but it's honestly not our fault. Unlike Google, we don't like torturing our clients!
Your incoming mail server type (IMAP or POP3)
The hostname or IP address of your mail server
The port of your mail server
If your server uses SSL set this to Yes
If your server uses TLS set both this and Use SSL to Yes
If you have enabled Use SSL and Use TLS select this option to have ATS verify the SSL certificates presented by your mail server. If the certificates are self-signed this WILL fail. We recommend using this option only when your mail server is using a commercial SSL certificate.
The username you use to connect to your incoming mail server. Usually this is either your email address or the part of your email address before the @ sign.
If you are using GMail or Google Apps email this is your entire email address, e.g. firstname.lastname@example.org.
The password you use to connect to your incoming mail server.
If you are using GMail or Google Apps email please make sure that you have read and understood the information in the red box under "I am using GMail".
If you have an IMAP mail server select the folder where the messages are stored. This is usually INBOX (all capital letters)
Should the retrieved email messages be deleted from the server after the post/ticket has been created? If this is set to No then the emails are only marked as read. If you set this option to No we strongly advise that you set Track email UID to Yes.
The minimum time between email checks.
Setting a value too low will result in double posts: one thread will still be processing emails when the next one starts checking for new emails. The emails seen by both threads will result in double posts. In order to avoid this situation we recommend setting this to at least 5 minutes and setting the Track email UID option to Yes.
If you are using a CRON job with ats-mail-fetch.php set this to at most one minute less than the frequency of the CRON job itself. As implied by the notes above, we do NOT recommend running the CRON job more often than once per 5 minutes to avoid double posts.