Tickets Master Tutorial
A heavy breakdown on the Tickets Plugin (lots of scrolling here, check the sidebar!)
Last updated
A heavy breakdown on the Tickets Plugin (lots of scrolling here, check the sidebar!)
Last updated
You might need Discord Developer Mode on to get ID's and such!
Key words:
Boolean: A true or false switch
String: An assortment of "text" or "numbers" like this
Numbers: Just numbers!
Array: Strings or Numbers["in", "a", "pattern", "like", "this"]
Here we'll go over the Ticket Plugin setup in its entirety, with brief (or not so brief!) explanations and descriptions on things.
I made sure to separate everything the best possible so that the sidebar has a quick reference to what you're looking for.
If you think something is missing, or needs a bit more work, then make sure to leave us a note at
Default: true,
A simple Boolean statement, this allows you to choose whether the person that opened the ticket gets a ticket transcript, some people like having it on, others don't, it's entirely up to choice.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the tickets' transcripts don't get sent to whoever created them.
On true, the tickets' transcripts do get sent to their creators.
Default: true,
A simple Boolean statement, this allows you to choose whether ticket transcripts are saved locally on the device you're running the bot on. Another optional thing to have enabled, but it may help you save on storage space if you receive a lot of tickets in your server with lots of pictures attached!
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the tickets never store on disk, which can lead to them getting lost over time.
On true, the tickets create a file on disk, storing the ticket safely for you.
Default: true,
A simple Boolean statement, this allows the tickets when being moved from one category to another, to have new updated permissions for the category it's being moved to. Let's say you have a General Support ticket open, but the user wants to change it into a Bug Report ticket, this will allow your ticket to go from regular staff being able to view it, to the bot developers being able to view it instead, for example.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the tickets retain permissions they had prior to being moved.
On true, the tickets get new permissions updated to whatever the new category is they're moved to.
Default: "ticket-%random%",
A String statement, this allows your tickets' channels to have a specific way they get named.
You theoretically could leave it blank, but we don't recommend it. It could break things.
Examples:
"%creator%-%random%" creates a channel named Wumpus-24513
(their username and a random assortment of numbers)
"%creator%-%created_total%" creates a channel named Wumpus-2
(if that user has created two tickets)
Default: 200,
A Number statement, this allows you to choose how many messages you want your transcript to be made for. Highly recommended you set this to something reasonable, like 200-300 messages, probably a bit more if you have the resources and storage space to spare, or if you really wanna keep all the messages possible. Keep in mind on a server with a lot of tickets, if you close a lot of them at once, you're prone to hit a rate limit imposed by Discord and may cause a preventable error otherwise.
You theoretically could leave it blank, but we don't recommend it. It could break things.
Examples:
ticket_transcript_message_limit:200,
(would impose a limit of 200 messages per transcript)
Highly recommended to leave enabled!
Default: true,
A Boolean statement, this allows you to have Athena automatically close tickets if the user leaves the Discord. It helps you by cleaning up tickets that the Ticket OP would not be available to respond to anymore!
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the tickets stay open even if the Ticket OP left.
On true, the tickets automatically close when the Ticket OP leaves the server.
Default: false,
A Boolean statement, this causes Athena to automatically ping the appropriate roles when changing permission levels. For example, if you have helpers/mods working on a ticket, and the ticket gets transferred to a different category, eg. Store or Bug Reports, the ticket system will ping the roles set up for the Store or Bug Reports category to alert the different staff accordingly.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the tickets does not ping any assigned roles when the ticket changes levels/categories.
On true, the tickets automatically pings the assigned roles when the ticket changes levels/categories.
Default: false,
A Boolean statement, this allows you control how much tickets any one person can make per category. This can help control ticket spam to some degree.
It has to be to be either true or false, so there's no leaving it blank!
Usage:
On false, the user can only create one ticket altogether excluding staff applications.
On true, the user can create one ticket per category, giving them a bit more flexibility.
Default: true,
A Boolean statement, this causes Athena to upload the ticket transcripts to a locally held web server, as well cause the ticket transcripts to not be saved as files, but instead as links.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, Athena creates ticket files locally instead of links, which do over time, take up space.
On true, Athena creates links instead of ticket files, allowing a dynamic ticket experience.
Default: false,
A Boolean statement, this allows the user that claims the ticket to receive a copy of the ticket transcript. Let's say you have a staff hierarchy in place that has staff members claiming tickets for themselves, this allows the participating staff member to get a copy of the ticket for themselves for future reference automatically.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, the ticket claimer doesn't receive a ticket transcript, and instead get handled as normal.
On true, the ticket claimer receives a ticket transcript automatically.
Default: false,
A Boolean statement, this causes Athena to send a simple message, rather than an embed message.
It has to be either true or false, so there's no leaving it blank!
Usage:
On false, Athena generates the ticket creation message as plain text, removing the embed aspect.
On true, Athena generates the ticket creation message as an embed, making it look nicer.
First of all, we wanna set a Ticket category name! This can be anything you want it to be, since it's a String.
Then we add a description so people know what the category is for.
So we have a category set up, but it's not going anywhere without a category ID. So we set that here! To get a category ID, you right click on the category you want the tickets to go to.
Alright, that's done, now we got new tickets to be generated where we want them to, now what? We gotta make the bot respond to the ticket being opened in some way! Here you can edit the message to your hearts' content. You can even make the bot say their name and the tickets' channel name with the placeholders! If you wanna split the lines up, you can use /n between sentences.
Alright! Hopefully you formatted your first message correctly! Now we move onto permission levels. We haven't touched on this yet in this so far, so we can leave them at 0 for now, but here's the TL;DR to permission levels! Permission levels in essence allow you to allow or deny access to certain roles by assigning them to 'levels'. The lower the level number, the less permissions you have.
Done with permission levels? If not we can worry about that in a bit, but for now, we have to assign questions to our ticket category. You're able to make question sets for the ticket modals, yes, modals! In this case, you can again, assign whatever ID you're gonna make your question set with, or even set it to null to disable it! We'll go over what ticket question sets are in just a moment.
IDs cannot have spaces! This will break the plugin!
Please use _ instead of spaces: eg. bug_report instead of Bug Report
Alright, almost done with this Ticket Category, at least the setup of it!
This step involves setting up role mentions for the ticket opening system. Basically, any IDs you set up in this Array get mentioned. Want only one bug support role mentioned? Go for it. Want your whole staff team pinged at one time? Sure thing. It's really up to you as to how you want to do it.
Note: In this case, Arrays can be either written horizontally or vertically. whatever helps you keep it more organized is best. Something like below!
You set up your first ticket category, and any further ticket categories can be set up in exactly the same way using these steps! Once you get used to how the system works, your file can be even made smaller without the comments attached to each category! But overall, your config should look something like the below example. Once you get used to how it's formatted, you'll be able to make the new categories without all the comments in between. We've still got some work to do though!
Remember what we were talking earlier about Permission Levels? Well to put it in more depth, permission levels allow or disallow people from interacting with tickets depending on the permission level they have set up for their Role. It's a nice way of having, for example, Helpers not be able to see/interact with Moderation Tickets, or have regular Staff members not be able to interact with bug report tickets and so on. It's a really neat system of controlling who does and sees what.
So the Permissions Levels are hierachical, meaning they go by tiers. The lower the number assigned to a role, the less permissions they have to interact with tickets. The higher the numbers, the more permissions they have.
Let's take a look at the example config file snippet:
So in this case, we see multiple role ID's, and multiple levels by them (which you can add more of by the way, simply by adding to the Array). Level 0 is the lowest, Level 2 is the highest. So for example, if we wanted to set up Helpers, Staff, Senior Staff, and Owner, all we have to do is change those role ID's accordingly, and assign them to the proper levels.
After editing the file, it should look like this:
So make sure to edit your ticket category according to what you need it to do and who you want it to be seen/interacted by! Want only Helpers and above to access the ticket category? Assign the ticket category to Level 0, want only the Owner to deal with the ticket? Set it to 3. And so on.
Got the Permission Levels set up? Awesome! Now we move onto the Ticket Question Sets.
Ticket Question Sets are what they sound like, they're sets of questions specifically made for a ticket category. Let's say you want a Bug Report ticket category, you can make 5 questions for it that will pop up in a modal for the users to answer.
They can only have 45 characters in them. That's a Discord limitation, can't do anything for that.
You can only input a max of 5 questions per category.
Ticket Question Sets aren't hard to make! They just take a bit of time. We have to assign an ID to the set, the questions we want to ask, the minimum and maximum response length, and if they're required or not.
This is the format (annotation enabled, hover over and click the }, for example):
For every additional question you want to add, you need to add it after the }, and then to add other additional set of questions, you add them after the] bracket by separating them with }],
Something like this (might look a bit different, but the syntax is the same):
And that's it! You can add more question sets for new categories you make!
Let's say you have people that boost your server, and you wanted to show them appreciation for it. You have lots of users too. So, you come up with the idea to be able to have some way to help your boosting members in tickets a lot faster than most other people. You can do that with Athena! Or even if you didn't want to do it boosters, you can do it with other roles too, it's configurable.
Since this is a much simpler module, we can speed through it.
We can configure the role ID(s) we want in an Array, which means you can actually support multiple roles for prioritization!
As well as being able to configure extra roles to be pinged if someone that owns one of the roles above opens a ticket:
And that's it!
Time is in 24hr!
It will not take AM or PM into account.
Let's say you're in the EST time zone. And most of your staff is too. Shame really, having all those unanswered tickets during the nighttime hours. Well, no more waking up to tell people you're not able to help them right now! Athena can automatically send a message about Out of Service hours!
It's very simple. Another breeze to go through.
All you have to do is calculate the times your bot is in, and your correct time zone, and approximate when it is you think tickets will take longer to answer.
This simply controls the buttons that show up underneath the tickets when opened. If you don't want specific tickets to be visible, you can disable them individually.
Easy! It's all Boolean switches! Just true or false what you want or don't want, respectively.
You're all done here! Now you can move onto other plugins and see how they work!
Afterwards, we can either copy paste an emoji directly into the config file, or we can use custom emojis by using \<whatever emoji you want to use>, or if you want a guide,
