# Tickets Master Tutorial

{% hint style="info" %}
**This configuration takes place in the** <mark style="color:green;">**`/configuration/tickets.json`**</mark> **file!**
{% endhint %}

{% hint style="warning" %}
**You might need Discord Developer Mode on to get ID's and such!**
{% endhint %}

{% hint style="success" %}
**Key words:**

<mark style="color:yellow;">**`Boolean:`**</mark> A <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark> switch

<mark style="color:yellow;">**`String:`**</mark> An assortment of <mark style="color:green;">**`"text"`**</mark> or <mark style="color:green;">**`"numbers"`**</mark> like this

<mark style="color:yellow;">**`Numbers:`**</mark> Just numbers!

<mark style="color:yellow;">**`Array:`**</mark> Strings or Numbers<mark style="color:green;">**`["in", "a", "pattern", "like", "this"]`**</mark>
{% endhint %}

## <mark style="color:blue;">Welcome!</mark>

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.

### <mark style="color:green;">Feedback is welcome!</mark>

If you think something is missing, or needs a bit more work, then make sure to leave us a note at [our support server!](https://discord.iynxdev.com/)

***

## <mark style="color:blue;">Basic Configuration Tutorial</mark>

### <mark style="color:yellow;">"send\_transcript\_to\_ticket\_creator"</mark>

#### <mark style="color:orange;">Whether the ticket creator should receive a copy of the ticket transcript (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">true,</mark>

A simple <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the tickets' transcripts *don't* get sent to whoever created them.

On <mark style="color:green;">**`true`**</mark>, the tickets' transcripts *do* get sent to their creators.

***

### <mark style="color:yellow;">"save\_ticket\_transcript\_on\_disk"</mark>

#### <mark style="color:orange;">Whether ticket transcripts should be saved on disk - C:%root%/logs/transcripts/ - (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">true,</mark>

A simple <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's <mark style="color:red;">no leaving it blank</mark>!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the tickets *<mark style="color:purple;">**never store on disk**</mark>*, which can lead to them getting lost over time.

On <mark style="color:green;">**`true`**</mark>, the tickets *<mark style="color:purple;">**create a file on disk**</mark>*, storing the ticket safely for you.

***

### <mark style="color:yellow;">"update\_permissions\_on\_move"</mark>

#### <mark style="color:orange;">Whether permissions should be synced with the new ticket category once moved (/tmove) (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">true,</mark>

A simple <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's <mark style="color:red;">no leaving it blank</mark>!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the tickets *<mark style="color:purple;">**retain permissions**</mark>* they had prior to being moved.

On <mark style="color:green;">**`true`**</mark>, the tickets *<mark style="color:purple;">**get new**</mark>* permissions updated to whatever the new category is they're moved to.

***

### <mark style="color:yellow;">"ticket\_channel\_name"</mark>

#### <mark style="color:orange;">Ticket channel name, available placeholders: %random%, %creator%, %created\_total% (String)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">"ticket-%random%",</mark>

A <mark style="color:green;">**`String`**</mark> statement, this allows your tickets' channels to have a specific way they get named.

You ***theoretically*** could leave it blank, but we <mark style="color:red;">don't recommend it</mark>. It could break things.

<mark style="color:blue;">**Examples:**</mark>

<mark style="color:green;">**`"%creator%-%random%"`**</mark> creates a channel named <mark style="color:red;">Wumpus-24513</mark>\
\&#xNAN;*<mark style="color:purple;">**(their username and a random assortment of numbers)**</mark>*

<mark style="color:green;">**`"%creator%-%created_total%"`**</mark> creates a channel named <mark style="color:red;">Wumpus-2</mark>\
\&#xNAN;*<mark style="color:purple;">**(if that user has created two tickets)**</mark>*

***

### <mark style="color:yellow;">"ticket\_transcript\_message\_limit"</mark>

#### <mark style="color:orange;">Max messages the transcript will include (Number)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">200,</mark>

A <mark style="color:green;">**`Number`**</mark> 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 *<mark style="color:red;">**don't recommend it**</mark>*. It could break things.

<mark style="color:blue;">**Examples:**</mark>

<mark style="color:green;">**`ticket_transcript_message_limit:`**</mark>**`200,`**\
\&#xNAN;*<mark style="color:purple;">**(would impose a limit of 200 messages per transcript)**</mark>*

***

### <mark style="color:yellow;">"close\_ticket\_after\_creator\_left"</mark>

{% hint style="success" %}
Highly recommended to leave enabled!
{% endhint %}

#### <mark style="color:orange;">Whether tickets should be automatically closed when the ticket creator leaves the discord (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">true,</mark>

A <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the tickets *<mark style="color:purple;">**stay open**</mark>* even if the Ticket OP left.

On <mark style="color:green;">**`true`**</mark>, the tickets *<mark style="color:purple;">**automatically close**</mark>* when the Ticket OP leaves the server.

***

### <mark style="color:yellow;">"ping\_role\_at\_permission\_update"</mark>

#### <mark style="color:orange;">Whether whenever a ticket's permission level is being updated the effected role should be pinged (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">false,</mark>

A <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the tickets *<mark style="color:purple;">**does not ping any assigned roles**</mark>* when the ticket changes levels/categories.

On <mark style="color:green;">**`true`**</mark>, the tickets *<mark style="color:purple;">**automatically pings the assigned roles**</mark>* when the ticket changes levels/categories.

***

### <mark style="color:yellow;">"limit\_tickets\_per\_category"</mark>

#### <mark style="color:orange;">If set to true a user can create one ticket per category, if set to false the user can create one ticket at all - this excludes applications (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">false,</mark>

A <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the user *<mark style="color:purple;">**can only create one ticket altogether**</mark>* excluding staff applications.

On <mark style="color:green;">**`true`**</mark>, the user *<mark style="color:purple;">**can create one ticket per category**</mark>*, giving them a bit more flexibility.

***

### <mark style="color:yellow;">"enable\_web\_server"</mark>

#### <mark style="color:orange;">If set to true the ticket transcripts are uploaded to your private web server. This will replace the ticket transcript files and replace them with a link (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">true,</mark>

A <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, Athena *<mark style="color:purple;">**creates ticket files locally instead of links**</mark>*, which do over time, take up space.

On <mark style="color:green;">**`true`**</mark>, Athena *<mark style="color:purple;">**creates links instead of ticket files**</mark>*, allowing a dynamic ticket experience.

***

### <mark style="color:yellow;">"send\_transcript\_to\_claimed\_user"</mark>

#### <mark style="color:orange;">If set to true the staff member who claimed a ticket will receive a copy of the ticket transcript once the ticket is being closed (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">false,</mark>

A <mark style="color:green;">**`Boolean`**</mark> 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 <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, the ticket claimer *<mark style="color:purple;">**doesn't receive a ticket transcript**</mark>*, and instead get handled as normal.

On <mark style="color:green;">**`true`**</mark>, the ticket claimer *<mark style="color:purple;">**receives a ticket transcript automatically**</mark>*.

***

### <mark style="color:yellow;">"send\_plain\_ticket\_create\_message"</mark>

#### <mark style="color:orange;">If set to true the ticket create message will not be generated as embed but rather as a plain message (Boolean)</mark>

<mark style="color:purple;">**Default:**</mark> <mark style="color:red;">false,</mark>

A <mark style="color:green;">**`Boolean`**</mark> statement, this causes Athena to send a simple message, rather than an embed message.

It **has to be** either <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark>, so there's no leaving it blank!

<mark style="color:blue;">**Usage:**</mark>

On <mark style="color:green;">**`false`**</mark>, Athena *<mark style="color:purple;">**generates the ticket creation message as plain text**</mark>*, removing the embed aspect.

On <mark style="color:green;">**`true`**</mark>, Athena *<mark style="color:purple;">**generates the ticket creation message as an embed**</mark>*, making it look nicer.

***

## <mark style="color:blue;">Ticket Configuration Setup</mark>

### <mark style="color:yellow;">Create a Category</mark>

First of all, we wanna set a Ticket category name! This can be anything you want it to be, since it's a <mark style="color:green;">**`String`**</mark>.

<details>

<summary><strong>Category Name Config Example</strong></summary>

```json5
// Ticket category name (String)
category: "Example Category",
```

</details>

### <mark style="color:yellow;">Add a Description</mark>

Then we add a description so people know what the category is for.

<details>

<summary><strong>Ticket Category Description Config Example</strong></summary>

```json5
// Ticket category description (String)
description: "Press here to make a ticket!",
```

</details>

### <mark style="color:yellow;">Add an Emoji</mark>

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, [that's here!](https://support.discord.com/hc/en-us/community/posts/360038896012-Can-Get-Emoji-ID-When-You-re-On-Chrome)

<details>

<summary><strong>Emoji Config Example</strong></summary>

```json5
// Custom or default Emoji (String)
// * Default: https://emojidb.org/discord-copy-and-paste-emojis - 
// * Custom: https://support.discord.com/hc/en-us/community/posts/360038896012-Can-Get-Emoji-ID-When-You-re-On-Chrome
emoji: "❓",
```

</details>

### <mark style="color:yellow;">Send It To a Specific Category</mark>

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.

<details>

<summary><strong>Category ID Config Example</strong></summary>

```json5
// Discord category ID (String)
// All ticket channels will be generated under this category.
category_id: "CATEGORY ID HERE",
```

</details>

### <mark style="color:yellow;">Send a Placeholder Message</mark>

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 <mark style="color:green;">**`/n`**</mark> between sentences.

<details>

<summary><strong>Placeholder Message Config Example</strong></summary>

```json5
// First ticket message sent by the bot. 
// Available placeholders: %creator%, %ticket_channel% (String)
ticket_create_message: "Hey %creator%/nThanks for opening %ticket_channel%/nWe'll be with you in a bit!",
```

</details>

### <mark style="color:yellow;">Set the Permission Level</mark> [(What?)](#permissions-level-setup)

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.

<details>

<summary>Permission Level Config Example</summary>

```json5
// Permission level, for more information please check out the configuration
// option "permission_levels" below (Number)
permission_level: 0,
```

</details>

### <mark style="color:yellow;">Setting the Ticket Question Set ID</mark>

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 <mark style="color:green;">**`null`**</mark> to disable it! We'll go over what ticket question sets are in just a moment.

{% hint style="danger" %}
**IDs cannot have spaces! This will break the plugin!**

Please use \_ instead of spaces: eg. bug\_report instead of Bug Report
{% endhint %}

<details>

<summary>Ticket Question Set ID Config Example</summary>

```json5
// Ticket create questions, for more information please check out the
// configuration option "ticket_create_questions" below. This configuration
// option requires the ID found below. Set to null to disable (String/null)
ticket_create_questions: "first_question_set",
```

</details>

### <mark style="color:yellow;">Setting Role Mention IDs</mark>

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 <mark style="color:green;">**`Array`**</mark> 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, <mark style="color:green;">**`Arrays`**</mark> can be either written horizontally or vertically. whatever helps you keep it more organized is best. Something like below!

<details>

<summary><strong>Role Mention ID Config Example</strong></summary>

```json5
        // List of role IDs - These roles are mentioned (@) once a ticket of this category 
        // is being created (Array)
        mention_roles: [
            "ROLE ID HERE", // HELPERS
            "ROLE ID HERE", // STAFF
        ]
    },
```

</details>

### <mark style="color:yellow;">Checkpoint!</mark> :triangular\_flag\_on\_post:

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!**

<details>

<summary><mark style="color:green;"><strong><code>Checkpoint Config</code></strong></mark> <span data-gb-custom-inline data-tag="emoji" data-code="1f6a9">🚩</span></summary>

```json5
        ticket_categories: [
        {
            // Ticket category name (String)
            category: "General Support",
            // Ticket category description (String)
            description: "Select to create a General ticket.",
            // Custom or default Emoji (String)
            // * Default: https://emojidb.org/discord-copy-and-paste-emojis - 
            // * Custom: https://support.discord.com/hc/en-us/community/posts/360038896012-Can-Get-Emoji-ID-When-You-re-On-Chrome
            emoji: "❓",
            // Discord category ID (String)
            // All ticket channels will be generated under this category.
            category_id: "CATEGORY ID HERE",
            // First ticket message sent by the bot. 
            // Available placeholders: %creator%, %ticket_channel% (String)
            ticket_create_message: "Hey %creator%,\nThank you for creating %ticket_channel%, we will get back to you as soon as possible.\n\nWhilst you are waiting for a response please explain the reason why you created this ticket by following this format:\n\n``IGN:``\n``Realm:``\n``Reason:``\n​",
            // Permission level, for more information please check out the configuration
            // option "permission_levels" below (Number)
            permission_level: 0,
            // Ticket create questions, for more information please check out the
            // configuration option "ticket_create_questions" below. This configuration
            // option requires the ID found below. Set to null to disable (String/null)
            ticket_create_questions: "first_question_set",
            // List of role IDs - These roles are mentioned (@) once a ticket of this category 
            // is being created (Array)
            mention_roles: [
                "ROLE ID HERE",
            ]
        },
```

</details>

***

## <mark style="color:blue;">Permissions Level Setup</mark>

### <mark style="color:yellow;">What's this for?</mark>

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.

### <mark style="color:yellow;">How do I configure them?</mark>

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:

<details>

<summary><strong>Permission Levels Config Format</strong></summary>

```json5
    // Each ticket is assigned one permission level. Permission levels
    // are represented by certain roles. Whenever a ticket is being created
    // the role that represents the assigned permission level (for example: 1)
    // and all above (level 2, 3, 4, ...) will gain access to the ticket.
    //
    // The further down you get in the list below the higher is its permission level.
    //
    // Each ticket's permission level can be updated on Discord using specific
    // commands or the buttons applied to the ticket creation message.
    // The bot will either increase the permission level or decrease it.
    // Depending on that a specific role will either be removed from the ticket
    // or added (Array)
    permission_levels: [
        "ROLE ID HERE", // Level 0
        "ROLE ID HERE", // Level 1
        "ROLE ID HERE", // Level 2
        "ROLE ID HERE", // ...
    ],
```

</details>

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.

<mark style="color:red;">**After editing the file, it should look like this:**</mark>

<details>

<summary><strong>Permission Levels Config Example</strong></summary>

```json5
    // Each ticket is assigned one permission level. Permission levels
    // are represented by certain roles. Whenever a ticket is being created
    // the role that represents the assigned permission level (for example: 1)
    // and all above (level 2, 3, 4, ...) will gain access to the ticket.
    //
    // The further down you get in the list below the higher is its permission level.
    //
    // Each ticket's permission level can be updated on Discord using specific
    // commands or the buttons applied to the ticket creation message.
    // The bot will either increase the permission level or decrease it.
    // Depending on that a specific role will either be removed from the ticket
    // or added (Array)
    permission_levels: [
        "ROLE ID HERE", // Level 0 - HELPERS
        "ROLE ID HERE", // Level 1 - STAFF
        "ROLE ID HERE", // Level 2 - SENIOR STAFF
        "ROLE ID HERE", // Level 3 - OWNER
    ],
```

</details>

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.

***

## <mark style="color:blue;">Ticket Question Set Setup</mark>

{% hint style="info" %}
**This is an optional module!**

You can set it to <mark style="color:green;">**`false`**</mark> and just have the bot send the Placeholder message, or set it to <mark style="color:green;">**`true`**</mark> and have a pop-up modal to have the user answer questions beforehand to speed the process up!
{% endhint %}

### <mark style="color:yellow;">What's this for?</mark>

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.

### <mark style="color:yellow;">What are the limitations?</mark>

1. **They can only have 45 characters in them.** That's a Discord limitation, can't do anything for that.
2. You can only input a **max** of **5** questions *per* category.

### <mark style="color:yellow;">How do I configure them?</mark>

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):

<details>

<summary>Ticket Question Set Config Format</summary>

<pre class="language-json5"><code class="lang-json5">            question_list: {
                "first_question_set": [
                    {
                        question: "QUESTION 1",
                        max_letters: 20,
                        min_letters: 2,
                        required: true,
                    },


                    {
                        question: "QUESTION 2",
                        max_letters: 20,
                        min_letters: 3,
                        required: true,
                    },


                    {
                        question: "QUESTION 3",
                        max_letters: 200,
                        min_letters: 10,
                        required: true,
                    },                
<strong>                ]
</strong>            }
        },
</code></pre>

</details>

For every additional question you want to add, you need to add it after the <mark style="color:green;">**`}`**</mark>, and then to add other additional set of questions, you add them after the<mark style="color:green;">**`]`**</mark> bracket by separating them with <mark style="color:green;">**`}],`**</mark>

Something like this (might look a bit different, but the syntax is the same):

<details>

<summary>Ticket Question Set Config Example</summary>

```
        "question_list": {
            "first_questions_set": [
            {
                "question": "What would you like to ask about?",
                "max_letters": 20,
                "min_letters": 2,
                "required": true
            }, 
            {
                "question": "Does this affect your fun in the server?",
                "max_letters": 30,
                "min_letters": 3,
                "required": true
            }, 
            {
                "question": "How do you think we can help with this?",
                "max_letters": 200,
                "min_letters": 10,
                "required": true
            }],
            "second_questions_set": [{
                "question": "What is the bug you're encountering?",
                "max_letters": 20,
                "min_letters": 2,
                "required": true
            }, 
            {
                "question": "What were you doing when the bug happened?",
                "max_letters": 30,
                "min_letters": 3,
                "required": true
            }, 
            {
                "question": "Can you replicate the issue?",
                "max_letters": 200,
                "min_letters": 10,
                "required": true
            }, 
            {
                "question": "How important is the problem?",
                "max_letters": 200,
                "min_letters": 10,
                "required": true
            }],
```

</details>

And that's it! You can add more question sets for new categories you make!

***

## <mark style="color:blue;">Special Role Ticket Handling</mark>

{% hint style="info" %}
**This is an optional module!**

You can set it to <mark style="color:green;">**`false`**</mark> to have every member receive support equally, or <mark style="color:green;">**`true`**</mark> and have your selected role(s) prioritized over regular members when it comes to tickets.
{% endhint %}

### <mark style="color:yellow;">What's this for?</mark>

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.

### <mark style="color:yellow;">How do I configure it?</mark>

Since this is a much simpler module, we can speed through it.

We can configure the role ID(s) we want in an <mark style="color:green;">**`Array`**</mark>, which means you can actually support multiple roles for prioritization!

<details>

<summary>Special Role Config Example</summary>

```json5
// List of role IDs. If the ticket creator owns any of the following roles
// this module will trigger (Array)
    roles: [
        "ROLE ID HERE", //Booster
        "ROLE ID HERE", //MC Server Supporter
        "ROLE ID HERE", //Tebex Patron
    ],
```

</details>

As well as being able to configure extra roles to be pinged if someone that owns one of the roles above opens a ticket:

<details>

<summary>Special Role Pings Config Example</summary>

```json5
        // List of role IDs. All of these roles will be mentioned additionally
        // to the usual ticket category configuration (Array)
        mention_roles: [
            "ROLE ID HERE", // Owner
            "ROLE ID HERE", // Senior Staff
        ]
    },
```

</details>

And that's it!

***

## <mark style="color:blue;">Out of Service Hours</mark>

{% hint style="info" %}
**This is an optional module!**

You can set it to <mark style="color:green;">**`false`**</mark> to handle off-hours tickets yourself, or <mark style="color:green;">**`true`**</mark> so Athena can automatically announce to any new tickets being opened in the time frame you selected when they are opened in off-hours scheduling.

The timeframe is based on the machine your bot is on. Check the console and the time, and calculate the off-hours depending on that.
{% endhint %}

{% hint style="warning" %}
**Time is in 24hr!**

It will not take AM or PM into account.
{% endhint %}

### <mark style="color:yellow;">What's this?</mark>

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!

### <mark style="color:yellow;">How do I configure it?</mark>

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.

<details>

<summary>Out of Service Hours Config Example</summary>

```json5
        time: {
            start: "23:00",
            finished: "07:00",
        }
    },
```

</details>

***

## <mark style="color:blue;">Ticket Buttons</mark>

### <mark style="color:yellow;">What's this for?</mark>

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.

### <mark style="color:yellow;">How do I configure this?</mark>

Easy! It's all <mark style="color:green;">**`Boolean`**</mark> switches! Just <mark style="color:green;">**`true`**</mark> or <mark style="color:green;">**`false`**</mark> what you want or don't want, respectively.

<details>

<summary>Ticket Buttons Config Example</summary>

```json5
    ticket_buttons: {
        // Ticket close button (Boolean)
        close: true,
        // Ticket elevate button (Boolean)
        elevate: true,
        // Ticket lower button (Boolean)
        lower: true,
        // Ticket claim button (Boolean)
        claim: true,
        // Ticket unclaim button (Boolean)
        unclaim: true,
        },
    },
},
```

</details>

***

## <mark style="color:blue;">Congrats!</mark> :tada:

You're all done here! Now you can move onto other plugins and see how they work!

<figure><img src="https://2990434925-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FsCfnYTK1l5BZwNs2Vsgn%2Fuploads%2Fgit-blob-3bcb0e409ca5459f987648d2ff0c97157c73234a%2FGENERIC%20Congratulations.png?alt=media" alt=""><figcaption></figcaption></figure>
