⚡Admin360-Reloaded⚡Manage Real-Time Help Requests! ✅ HEX ✅ Ratings ✅ Statistics

⚡Admin360-Reloaded⚡Manage Real-Time Help Requests! ✅ HEX ✅ Ratings ✅ Statistics -----

Redefines Player-Staff Interaction; Fosters Disciplined & Quality Service!

Special thanks to Dartanboy and Technofied from DemocracyCraft for contributing to this project!
Wanna play on a server that values quality services powered by Admin360? Give DemocracyCraft a try!

Hello
World!
[IMG]

Have you ever been in a situation where many players need help, but there are only one or two admins online? It can be difficult to keep track of who needs help and in what order they asked for it. What if hardworking players who get promoted to admin start slacking off and not helping anymore? This plugin aims to solve both of these problems by introducing motivating incentives for your team and re-consolidating player-staff interaction.

First released by Vidhu in 2013, Admin360 is a lightweight yet a very essential community relations tool for Minecraft communities of any size. The new version revives this inactive plugin with new features, bug fixes and QoL changes to its 2013 base, resulting in better performance, forward compatibility and customizability.

✔ Works Out-of-the-Box ✔ Self-Explanatory Config.yml ✔ HEX Colour Support
✔ 99% Configurable ✔ Trigger Console Commands ✔ MySQL & SQLite

Support Ticket System ► Fosters Quality Service
Real-time Queuing, Status Queries, Organised Notifications and Informative Statistics

The support ticket module enables your players to seek help from staff by creating a support ticket when they are online. New tickets are automatically put in the queue with respect to the "First come, first serve" principle to ensure fairness. This also allows your staff to focus more on helping instead of having to think about who should be helped first or who should be the next. Peripheral functions such as the ability to cancel or delete tickets, alongside the option to view status and statistics, are included to empower Admin360 as a fully functional and efficient help-request management system. With Admin360, delivering quality service in-game becomes possible.

[IMG]

Honour Point System ► Incentivises Staff Engagement
Review Collection, Professional Statistics and Competitive Leaderboard

The review system enables users to express their satisfaction with the service they received by awarding staff an 'honour point'. Staff members have the ability to view both their own and their colleagues' honour points. This not only adds some motives for your staff to compete for better ratings, but it also provides server owners with valuable insights into their team's performance. With Admin360, staff engagement is encouraged and quality service is incentivised.

[IMG]

Left Window: PPT_T (Player) | Right Window: xWindwalker (Admin)
[IMG]

STEP 1: Creating Tickets (Player-In-Action)

Suppose a player, named Amy, opens a ticket using /ticket create [details]. Her request is then added to the Pending Queue with respect to the "First come, first serve" principle.

At this stage, Amy can:
- Cancel her ticket using /ticket cancel.
- Check her ticket status using /ticket status.
STEP2: Picking Tickets (Staff-In-Action)

Suppose a staff, named David, proceeds to attend to the next help request in the Pending Queue using /ticket next.

Assume Amy's ticket is at the head of the queue. Her request is then moved from the Pending Queue to the Attending List.

Apart from /ticket next, David can:
- Manually pick a ticket from the Pending Queue using /ticket select <name> based on the info from /ticket list.
STEP3: Processing Tickets (Staff-In-Action)

David is then teleported to Amy's location by Admin360.

Note that Admin360 does not provide a chat channel function. Staff will have to make use of available tools on the server to help the requesters out, e.g., using /msg in-game.

At this stage, David can:
- Teleport to Amy using /ticket tp.
- Retrieve information on Amy's ticket using /ticket info.
STEP4: Closing Tickets (Staff-In-Action)

After all the conversations, David closes (done-marked) the case using /ticket close. Amy's request is then removed from the Attending List and added to the Completing List.

By following this simple workflow, your staff are able to process tickets one by one and exercise their discretion case-by-case.

Apart from /ticket close, David can:
- Use /ticket transfer <name> to transfer the ticket to another staff if he is not able to handle it.
- Use /ticket drop if Amy's request is unreasonable.
STEP5: Giving Feedback (Player-In-Action)

To ensure service quality, Amy is asked to give a review regarding her service experience.

Suppose Amy upvotes David's service using /ticket yes. Her request is then removed from the Completing List and added to the database.

David receives an honour point with a Green Creeper Firework launched right at his location to congratulate him.

Apart from /ticket yes, Amy can:
- Use /ticket no to give David a bad rating if he isn't helpful at all.

Admin360 uses 4 major stages (i.e., status) and data structures (i.e., queue and list) to administer requests:

Pending: The Pending Queue holds all Pending Requests that await processing (i.e., not attended to by staff).

Attending: The Attending List holds all Attending Requests that are currently in progress (i.e., attended to by staff).

Completing: The Completing List holds all Closed Requests that await user review (i.e., feedback not received).

Completed: Completed requests are not managed in Memory. Instead, they exist in the database so all historical entries there can be referred to this stage.
The first 3 stages are managed completely in Memory and in a real-time manner, while completed requests are saved to the database for statistical and logging purposes.
Incomplete requests will be voided on server restart.
Incomplete requests will be voided on player leave. When a player leaves the server, he or she will be removed entirely from the request system regardless of his or her ticket's in-memory status.
What Admin360 does is manage the transition between these stages.

When a ticket is created, the request is added to the Pending Queue.

When a staff attends to the request, it is moved from the Pending Queue to the Attending List, hence the status transition from Pending to Attending.

When the ticket closes, the request is removed from the Attending List and added to the Completing List, hence the status transition from Attending to Completing.

Once a review is received, the request is removed from the Completing List and saved to the database. At this stage, the request is considered Completed.
When a player joins the server, if he or she has the permission "admin360.staff.basic", he or she will be added to the Staff List to receive staff-wide notifications.
It's so hard for me to explain everything here. Just give it a try, you will know how it works eventually!

Is this just "another" ticket plugin?

Not quite really. Although we call the thingy that a player opens a "ticket", it's actually more accurate if we call that thingy a "real-time help request". In fact, Admin360 is more like an extended version of /helpop because it only handles active requests from players who are online. So, technically speaking, it's a real-time request management system designed for a busy server that requires administering a whole lot of in-game requests. Admin360 also includes a feedback and statistics system so that you can always keep track of how your staff team performs, as well as to keep your staff motivated at work. Overall, it's a pretty simple yet fully functional service experience add-on for your server!

As of 9.1.0+:

General Commands

/ticket, /ticket help - (no permission) - Display a list of commands.
/admin360 help - (no permission) - Display a list of commands.
/admin360 - (no permission) - Display Admin360 information.
/request, /helpop - (no permission) - Aliases of /ticket.

Player Commands (admin360.player.*)

[]: Optional; <>: Compulsory
/ticket create [details] - (admin360.player.basic) - Create a new request.
/ticket cancel - (admin360.player.basic) - Cancel your request.
/ticket status - (admin360.player.status) - Query your request status.
/ticket stats - (admin360.player.stats) - View request statistics.
/ticket yes - (admin360.player.basic) - Feedback: Upvote a service.
/ticket no - (admin360.player.basic) - Feedback: Downvote a service.

Staff Commands (admin360.staff.*)

[]: Optional; <>: Compulsory

STEP 1: Picking a Request
/ticket list - (admin360.staff.basic) - Display a list of requests in the Pending Queue.
/ticket select <name> - (admin360.staff.basic) - Hand-pick a request from the Pending Queue.
/ticker next - (admin360.staff.basic) - Attend to the next request in the Pending Queue.
[2 options here: You either pick a request or attend to the next one.]

STEP 2: Processing a Request
/ticket tp - (admin360.staff.teleport) - Teleport yourself to the requester.
/ticket info - (admin360.staff.info) - Retrieve details of the request you attended to.
[Use other plugins for the communication part. e.g., /msg, /reply, etc.]

STEP 3: Making a Decision
/ticket transfer <name> - (admin360.staff.transfer) - Transfer the ticket to another staff member.
/ticket drop - (admin360.staff.drop) - Drop the ticket, especially useful for barring any unreasonable requests.
/ticket close - (admin360.staff.basic) - Close and done-mark the request.
[3 options here: You either transfer the ticket, drop it or close it.]

Request Removal
/ticket remove <name> - (admin360.staff.remove) - Remove silently the target from all stages regardless of status.
/ticket purge [stage] - (admin360.staff.purge) - Remove all requests of a particular stage.
[Possible stages: pending (default), attending, completing, all]

Honour Point System
/ticket hpstats [name] - (admin360.staff.hpstats) - Display honour points statistics.
/ticket hptop [line] - (admin360.staff.hptop) - Display honour points leaderboard.
/ticket history [line] - (admin360.staff.history) - Print honour points history, which can be viewed as ticket history.
/ticket hpreset <name> - (admin360.staff.hpreset) - Reset all all history entries of the target.

Config Reloading
/admin360 reload - (admin360.staff.reload) - Reload the config file.

IMPORTANT

These permissions are not given to any user groups by default except for OPs. You will have to manually add the nodes to suitable permission group(s) on your server.

Admin360 registers those having the permission "admin360.staff.basic" to Staff List on server join. If someone is granted the above permission while being online, that user should re-enter the server.

To combat boosting, staff with permission "admin360.staff.basic" are blocked from using "/ticket create" and "/ticket cancel" as a hard-coded policy.

Java 8 or above
Permission plugin, preferably LuckPerms or PermissionsEx
Spigot 1.8 or above, or equivalent forks

My config.yml keeps regenerating!

Opps! It seems that you have messed up with YAML formatting! Try to use an advanced text editor like Sublime Text or Notepad++ that comes with an error detection feature to edit your .yml files. Additionally, you may have a look at your console to see if there are any hints about the line number where the formatting error is located.

Does this plugin support MySQL and BungeeCord?

Yes and No. This plugin does support MySQL but it doesn't support BungeeCord. In other words, this plugin cannot be run directly on BungeeCord. If you own a network of servers and want the stats to be synchronised, you may install an instance of this plugin on each of your sub-servers while connecting all the instances to the same MySQL database.

How to edit the database file?

Everything is stored in the database, either with SQLite or MySQL. For SQLite, if you want to reset the database, simply delete the .db file and restart the server. If you want to do some manipulations, like you want to execute some SQL commands or queries, then you may give DB Browser for SQLite a try.

Does this plugin support UUID?

No, this plugin stores records based on case-sensitive names of players. If someone changes their name and wants their stats back, you will have to do the transfer manually using tools like DB Browser for SQLite. (Tips: Use the UPDATE SQL command).

However, we do look forward to implementing UUID support in future updates.

How to set up a custom command alias?

Let's say you don't want "/ticket" to be the primary command. You want "/request" instead. How to do that? Well, it's something quite simple to do.
Step 1: Find a file called "commands.yml" in your server repository. Open it with a text editor.
Step 2: Edit it according to the example below and save it.
$1 here means parsing all latter arguments from the old command to the new command so that under all conditions /request xxx is the same as /ticket xxx.

Code (Text):

command-block-overrides: []
aliases:
request:
- ticket $1-

Step 3: Restart your server.

How to use HEX colour codes in config.yml?

HEX colour support for 1.16+ servers has been added in 9.1.0.

Code (Text):

"#e69296This is a #c8a2c8test #e69296message."