Akeeba Ticket System allows, under certain conditions, Guest users to file tickets. Guest users is Joomla! lingo for site visitors who are not logged in, i.e. they do not have a user account yet. Please make sure you understand the "How does this feature work?" section below before trying to use this feature. It tells you how this feature works and which settings, in ATS and Joomla! itself, will conflict with it and make it not work as you think it should.
If you do not want this feature, you don't need to do anything. Guest tickets will only be allowed if you set up one or more ATS categories to allow Guest users to create tickets.
Unregistered (Guest) users can create tickets as long as the ATS category has the Create privilege for the Guest user group. Akeeba Ticket System creates the user account even if you have disabled user registration in the Options of Joomla's Users component. Before enabling this feature, please read Security trade-offs of guest tickets below.
The users will need to provide an email address, a name and a desired username when filing a ticket from the web. You can optionally tell Akeeba Ticket System, through its Component options, to show a CAPTCHA for Guest users. This is a good idea since it will cut down on spam ticket submissions. Please note that you must have one or more plugins in the "captcha" group activated in Joomla's Plugins page and select the CAPTCHA plugin to use. If either of these conditions is not met a CAPTCHA will not be shown to Guest users trying to file a new ticket. Also note that, obviously, the CAPTCHA will not apply to tickets created by sending an email!
When filing a ticket by email we obviously already have their email address. If they have provided their full name as part of the From address of their email we will use that. Otherwise we will also use the email address as the user's full name. Akeeba Ticket System will create a Joomla! username derived from the user's full name or, if that's not possible, their email address. Users can change their email address and full name in Joomla's user profile edit page whenever they want, as long as you've provided such a page in your site's frontend. Users can optionally be allowed to change their username themselves if you enable the respective feature in Joomla's Users component's Options page. By default, this feature is disabled. Do note that this is a feature of Joomla! itself, not a feature of Akeeba Ticket System.
As implied above, a new user account is created for the guest user and assigned to the ticket. That user account has a random password. The username and the password are both emailed to the user by Joomla! itself. If you have configured Joomla! to not send the password to the user then the user will very obviously not receive their password which makes it impossible for them to log in. In this case they will either have to use the Forgot Password feature of Joomla! itself or contact you and ask for a password to be issued. For this reason we recommend that you configure Joomla! to send the password to new users over email.
A special note about what happens when the user submits a ticket but required fields are missing or the CAPTCHA check fails. Akeeba Ticket System needs to create the user before checking for required fields and CAPTCHA (CAPTCHA is technically a required Joomla form field). This is a limitation of how Joomla works. This means that in this case a user is created and immediately deleted. If your site is configured to send an email to the user on new user registration (default Joomla behaviour) your guest user will receive a confusing email telling them a user account was created but no such user account exists on your site until the finish submitting their ticket. This is NOT a bug, it's the only way this can be implemented. We strongly recommend NOT using Guest tickets. Instead, let the users register a user account and then let them file tickets. You could even use something like Akeeba SocialLogin to provide frictionless registration with the users logging in (and automatically creating a user account) using their social media accounts such as Facebook, Twitter, GitHub, Google account, Microsoft account or Apple ID.
The user account created for the guest ticket may need to be activated by the user, per the Options in Joomla's backend. If, however, you have enabled Force user creation when filing Guest tickets the user registration settings of Joomla! will be ignored and the user account will be activated.
The user will need to log into your site with the created user account to reply to the ticket or file more tickets. If they try to file a ticket as a Guest with an email address already in use by a user account on the site they will be asked to log in to file a new ticket.
Because it's woefully insecure.
Email addresses are supposed to be handled as public information. You do give it to people you know or even people you don't know, e.g. printing it on your business card. Anyone who knows or guesses your email address could access your guest tickets and reply to them as if they were you. This is ridiculously insecure.
That's the reason why commercial helpdesk SaaS like ZenDesk require people contacting you to create a user account to view the entire ticket thread and/or send their replies by email. Akeeba Ticket System also does the same, the latter if you enable the ticket replies by email feature. It's the only way to have a modicum of assurance that the people who view or reply to tickets are those who are in control of a specific email address.
Guest tickets exist for two specific use cases:
Sites which want to accept public tickets from random, unvetted visitors through the web.
Sites which want to receive new tickets by email from anyone on the Internet (see Receiving email).
In both cases convenience deliberately trumps security. If your site does not fall in either use case, do not allow the Guest user group to create tickets.
When a category allows the Guest user group to create tickets, anyone can:
File a ticket using any email address, including someone else's. Akeeba Ticket System creates a user account for that address, even if user registration is disabled in Joomla. Joomla emails the new account's username and password to that address. Akeeba Ticket System emails the new ticket notification to that address, including the title and text the submitter typed. Both emails come from your site's email address.
Find out whether an email address belongs to a user account on your site. Filing a ticket with an address already in use results in an error message saying so.
File as many tickets, and create as many user accounts, as they like. A CAPTCHA only applies to the web form, and only if you have set one up. It never applies to tickets filed by email.
The following controls are sometimes suggested to address the above. They cannot be implemented without breaking the use cases this feature exists for.
Both use cases are about accepting tickets from people who have not been vetted in any way. Requiring them to prove they own their email address before their ticket is accepted is the exact opposite of that. If you need verified email addresses, let users register (and activate) a user account before filing tickets instead of using guest tickets.
The person who filed the ticket needs a working user account right away so they can read and reply to your replies. An account which cannot be used until it's activated gets in the way of the very thing this feature is for.
Akeeba Ticket System makes Joomla email the password of the new user account, regardless of the Send Password option in Joomla's Users component. Otherwise a visitor would file a ticket, an account would be created for them, they would receive your reply, but they would never be able to log into that account to reply back. They never chose a password, and many of them would never think to use Forgot Password on an account they don't know they have.
Rate limiting needs somewhere to keep track of requests. The only persistence layer Joomla guarantees is a MySQL (or MariaDB) database, which is a poor fit: a flood of requests would turn into a flood of database writes, making the rate limiter itself a denial of service vector. Rate limiting is best done in front of Joomla, at the web server, reverse proxy, CDN or web application firewall level.
Hiding the reason a ticket could not be filed (for example, that the email address is already in use and the visitor needs to log in instead) would only prevent email address enumeration. It would also leave the visitor stuck, and make troubleshooting impossible for the visitor, for you, and for us.
Only give the Guest user group the Create privilege on the categories which really need it.
Set up a CAPTCHA for Guest tickets in the component's Options.
Rate limit submissions to your site's ticket pages at the web server, reverse proxy, CDN or web application firewall level.
When receiving tickets by email, have your mail server filter spam and route mail failing SPF, DKIM or DMARC checks to a Spam or Junk folder, which Akeeba Ticket System doesn't read.
If none of the above is acceptable for your site, don't use guest tickets. Let users register a user account before filing tickets, as explained earlier in this section.