Table of Contents
In this chapter we will discuss how Akeeba Ticket System integrates with the more advanced Joomla core features and how you can use them to accomplish advanced features without much anguish. In other words, this chapter documents the non–obvious, awesome things you can do with Akeeba Ticket System and core Joomla 4 features.
It may sound counter–intuitive to list these features before the main component documentation. There is a good reason. The main component is fairly straightforward to use, even without documentation. Ticket categories management is handled by Joomla itself, giving it a familiar experience. Ticket management and even features like canned replies and automatic replies are mostly self–documenting; at worst, a little prodding by a curious user is enough to make them work. The features we discuss here require combining a few core Joomla features and ATS features to implement something which is not immediately obvious to the casual observer.
Permissions in Joomla define what a user group can and cannot do. Joomla has excellent documentation on how Permissions work.
Here are some quick takeaways:
Permissions control what users do, not what they see. If you are interested in who can see what this is what Access Levels are for.
Permissions cascade in two directions: 1. user groups, from Public towards the specific user group; and 2. from the Component and into the Categories tree.
Permissions have one of three states: Inherited, Allow and Deny. Inherited is a “transparent” setting; it falls back to what is inherited from a previous cascade. If nothing is found it's treated as a Deny. Allow means that this permission is explicitly allowed. Deny means that this permission is explicitly denied.
Deny trumps Allow and Inherited. If anywhere within the two permissions cascades there's an explicit Deny then the permission is Denied even if there is a more specific Allow. Think of permissions as voting with veto system. If you are not explicitly given the votes to do something you cannot do it (Inherited without explicit Allow). If anyone uses their veto power (explicit Deny) you are not allowed to do it.
Akeeba Ticket System uses Permissions in the component and each of its categories to control what the user can and cannot do. While most of them are standard Joomla permissions some are specific to Akeeba Ticket System or have a particular meaning. We are going to go through all of them.
Gives access to the component's Options page and the Permissions tab. This is equivalent to giving someone full and unfettered access to the component since they can change the permissions which apply to them!
Is the user a Support Staff / Manager? These users have additional implied privileges. They can reply to tickets submitted by any user. They can close and reopen tickets. They can view private tickets submitted by any user. They can view and edit the ticket metadata (title, state, ...) and custom fields. They can assign and be assigned to tickets. They can submit and view Manager's Notes on each ticket.
Only give this permission to your support personnel who's authorised to answer and manage tickets.
Allows the creation of new tickets.
Allows deleting any ticket, post and attachment regardless of who submitted it.
Allows editing any ticket, post and manager's note regardless of who submitted it.
Allows a user to edit the ticket metadata and custom fields of ticket submitted by them, as well as any and every post submitted by them.
Allows a user to edit the ticket metadata and custom fields of ticket submitted by them but NOT their own posts.
Allows a user to edit every post submitted by them, but NOT the ticket metadata and custom fields.
Allows the user to change the ticket state (Open, Closed, Pending and any custom state). This is NOT required for clients to close their tickets. This permissions would, in fact, allow them to re-open their ticket.
Moreover, this allows the user to publish / unpublish tickets, posts and attachments.
Allows the user to create a Private ticket. Private tickets are only visible to the user who submitted them and users with the Support Staff permission. The user also needs the Create privilege.
If the Create privilege is given but not the Create Private one, then the user can only submit Public tickets which are visible by everybody.
Allows the user to upload one or more attachments with their ticket and ticket replies. It requires the Create privilege.