The first commit on the
v4 branch was in March 2022. More than 14 months, 600 commits and 40 closed issues later, I'm finally releasing Discord Tickets version 4.0.0.
The documentation is incomplete, and there may be some bugs introduced more recently that weren't caught by the (extremely) rushed final test period, but the pain of seeing people installing and using version 3.1 has finally pushed me to get this done. Even if there are some rough patches, v4.0 is drastically better than the old rubbish... so, 2 years after the last release, here it is.
You can skip the essay if you want:
Why did it take so long?
Prepare yourself for a long list of excuses.
This update is huge. It's difficult to compare directly because the new codebase is split into 3 repositories, but to give you an idea, v3 contained about 5,100 LOC (lines of code, excluding translations). V4 is made up of:
- eartharoid/dbf.js: 1,600 LOC
- discord-tickets/bot: 8,600 LOC
- discord-tickets/portal: 5,000 LOC (and that's just the settings half)
Combined, that's over 15,000 lines, and that's not counting all of the lines that were rewritten. This makes the v4 codebase, including the 2 core packages, almost 3 times larger than v3.
The project size isn't the only reason it took this long though.
- Between college and indecisive design, the first few months went very slowly.
- After a few months of good progress, I started getting bored/burnt out.
- I have also been working on Mue, and to a lesser extent, Christmas Countdown and Left4Craft.
- Lack of motivation, mostly caused by the realisation of how long I had been thinking about the end, how far I was and how many targets had gone past.
- Lazyness and constant procrastination. I started waking up later which meant I was coding and going to bed later, resulting in a cycle of going to bed at 3am and not doing much the next day.
I had been thinking about v4 since late 2021, it should have been released in mid-late 2022 and could have been released in early 2023. Unfortunately, after a good sprint, I gave up when I was actually very close to finishing it. Progress in the last few months, although included major features and fixes, was extremely slow. In the end, it only took a week to complete, but it took so long to force myself to look at the last few things that had been waiting for almost half a year. Sorry. 😔
- March-May 2022: Mostly designing the database schema and API, making the dbf framework, starting to build the core, and trying to not get too involved due to my upcoming A-Level exams.
- June: Exams (yay...)
- Late July - August: Rewriting dbf
- July - September: Making the settings panel
- October: Lots of features
- a very long break...
- January - February 2023: Lots of features and fixes
- Early March: Major portal improvements and fixes
- another long break...
- Late May: The final sprint to the finish line
So there's a lot more code than before. Why? Because there are a lot more features, including a massive one. Many of these features are opt-in, so don't worry about lots of automation changing your workflow.
- First, the big one - the new settings panel web app. This took the majority of development time but was well worth it as it makes the setup experience vastly superior. It completely replaces the woeful command-based settings system of v3 -
/survey, and the two text commands,
tickets/surveyshave been removed.
- Now using Prisma for database ORM and migrations. SQLite now supports transcripts, and PostgreSQL is officially supported. This means I can add features that require new settings and you can still update just as easily.
- The previously completely useless "opening questions" now use modals, as does the ticket topic. I also spent many hours adding select-menu question types to the settings panel, only to find out later that they are not yet supported in modals. 😔
- Surveys have been replaced by simple modal-powered Feedback. When enabled, the user is asked for a rating out of 5 and an optional comment.
- Users can now be notified when there are no staff members online, or when they are not expected to be (and tell them when they should be back).
- Inactivity Warnings remind your users and staff to return to the ticket after the conversation has died.
- Stale tickets can be closed automatically, so your staff can spend less time cleaning up after annoying users.
- The long-awaited return of the
- Sends a DM to users when their ticket is closed with some useful information.
- Users can DM the bot to create a ticket.
- Users can right-click on messages to reference them in a new ticket. Useful for transitioning a conversation from public to private channels, or reporting another member.
- Users can right-click on messages in their tickets to pin important messages. These messages will be easy to find in transcripts.
- Staff can right-click on users to send them a ticket prompt.
- You can reference a past ticket when using the
/newcommand so it's easier to refer to its messages.
- Ticket and Discord categories are separated! Create as many categories as you want, without filling up your channel list.
- Staff can
/movetickets to another category.
- Tickets can be transferred to other members (with
- Tags can be used in any channel and don't take options.
- Tags can have RegEx patterns to automatically reply to messages.
- You can now hide the claim button and use
- The close button and command now send a close request. No more vanishing tickets.
- Staff can use the new
/force-closecommand to skip the close request (and Feedback).
/prioritycommand prefixes the channel name with a green, orange, or red circle emoji to help your staff identify which tickets to check first.
/helpcommand menu is clickable.
- The log channel shows tickets being opened and closed, claimed and released, messages being edited and deleted, and settings being changed.
- Enable slow mode in tickets.
- Response time and resolution time statistics with placeholders in opening messages and the bot's activity.
- You can send panels to an existing channel.
- Emoji and descriptions for categories.
- Probably some less significant changes.
Any bugs that were specifically in the old codebase are gone, but there are also improvements to solve some general problems as well.
- Improved reliability, both at ensuring interactions are responded to promptly, and not failing when many tickets are created quickly.
- The 1488th ticket doesn't break the bot in Discovery-enabled servers.
- Panel select menus are refreshed by the bot, so they always reset without the user needing to reload their app.
- Tickets close automatically and immediately when the member leaves the guild or the channel is deleted. No more manually fixing the database when your incompetent staff start deleting things!
- Other things that I can't think of at the moment.
How to update your bot
Before you continue, please make sure you have starred ✨ the GitHub repository.
To keep your settings and the rest of your data (such as the ticket counter, and all of your archived messages - which you'll now be able to access), you should migrate your data to the new database before reinstalling the bot.
To migrate, you need a system (which can be a remote server or your PC) with git, Node.js and NPM. You also need a second database. If you are currently using MySQL and your host does not allow you to make another database, you can move the current data to a database on your PC and reset (delete & recreate) the remote database.
Now that you have created your new database (or not, if you're using SQLite), run
git clone https://github.com/discord-tickets/migrate-v3-to-v4.git
or download and extract the ZIP file, then
cd into the directory.
Copy or rename the Prisma schema for your database to
npm install, followed by:
npm install sqliteif you are using SQLite, or
npm install mysql2if you are using MySQL.
If you are using MySQL, set the
V4_DB environment variable, either by creating a file called
.env or in your shell.
If you are using SQLite, copy the database file (
user/database.sqlite) from your v3 bot (you should probably stop it first) if it is not on the same machine already.
When everything has been installed, run
npx prisma db push to prepare the new database.
You can now start the migration process. It could take between a few minutes to a few hours depending on how much data you have.
node . --sqlite ../path/to/v3/database.sqlite
This will output a file called
v4.db in the current directory. Rename this to
database.db and move it to the
user directory when you have downloaded the code for v4.
node. --v3 mysql://... --v4 mysql://... -k <v3 encryption key>
When it has finished, follow the installation guides and documentation to install v4.
If you are the 1 person using PostgreSQL in v3, or you want a slightly more detailed guide, refer to the Migrator documentation:
The archives, feedback, and staff performance viewer parts of the portal will be coming in the next feature update. As most of the work has already been done, it should only take a couple of weeks to make, but I don't know if that'll start next week or in a couple months.
Help to complete the documentation would be greatly appreciated.